>Excuse the change of subject line, but I didn't think Modes, democracy and
>benevolent(?) dictatorship was quite what was being talked about anymore.
>
>Laurie Griffiths says -
>
>> These details have the potential for allowing music
>> created by hand and "checked" by one package to be
>> unacceptable to another. Believe me, I found *lots* of them
>> out there on the web.
>
>Hey, I think Laurie and I agree on something!
>
>There seems to be a feeling in this discussion that abc has to be either 100%
>correct to ensure compatibility or a total free-for-all so as not to stifle
>innovation. Couldn't we try to encourage a culture to make it better even if
>it will never be perfect. Surely it will benefit developers if they don't
>have to put a lot of effort into coping with every possible glitch, typo or
>obscure one-off innovation that somebody thought was a good idea five years
>ago.
There are two separate issues here. All the examples which Laurie quoted
are mistakes: they are wrong versions of constructions which can be
written correctly in abc v1.6. There is no doubt that programs should
warn users when they create abc like this, or even refuse to deal with
the abc until it is fixed. When it comes to dealing with this kind of
incompatibility I'm all for the 100% correct approach.
On the other hand, if you want to transcribe Bach you need some extensions
to abc because it wasn't designed to do that. You need V:, you need
clefs and you need macros. Inline fields are also very helpful.
All of these things need experimentation to get them to work, and it
would be a mistake to try and formulate an agreed standard in advance.
Eventually, what works best will go into a new standard and some other stuff
will be discarded. In the mean time you have to do some editing.
Phil Taylor
To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
