The trouble with propositions of this kind is that they tend to come from users who have experience with a very limited number of programs and usually on only one platform. What is being proposed here is that we all use abcm2ps syntax (plus a few enhancements) and abandon all other approaches.
This is very nice for people who use abcm2ps (we all like what we know), but utterly unacceptable to those who are familiar with a different program. If you really want to put forward a serious proposal for features to be added to a new standard you must first study _all_ of the existing programs, and come up with something which minimises the changes which have to be made to all of the existing code and invalidates as few as possible of the published abcs. It's not easy work, but you could start by reading the multivoice document whose url I posted here yesterday: http://www.barfly.dial.pipex.com/multivoice.txt This actually covers more than just multivoice, it covers the major features of all the programs which currently support the V: field, and so deals with clefs, transposition, the use of the continuation character and its interaction with he w: field etc. Resolving the syntax differences between different programs is probably going to require that we allow multiple formats. For example, I have no intention of abandoning the intuitive way in which BarFly specifies the layout of staves, clefs and merging of voices in favour of the cryptic %%staves directive. Likewise Jean-François will be reluctant to invalidate all of his music by ruling out its use. The real solution is to have both programs recognise either format, and leave it up to the users to choose whichever they prefer. That won't happen unless both formats are legitimated by inclusion in a new standard. Phil Taylor To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
