have different notational needs. And most musicians will see little if any need for notation that isn't used in the music they play.
Also, how can you implement something you've never even heard of?
I'll predict that this sort of thing will be a problem with any attempt to produce a single "portable" parser. Unless that parser handles all of the extentions that various groups of musicians think
The parser doesn't need to. If the parser is capable of breaking the abc down into the chunks it knows about and calling an extension handler callback for non-recognized chunks, anyone willing to write an extension can handle/implement the extra chunks and pass back and abcExtension object (or whatever) which the parser can then deal with (presumably calling overridden virtual methods or the equivalent) to do any work with that extension. If no extension handles the chunk, the parser can ignore it, or barf. The latter option sounds compatible with existing implementations :-)
This is why I haven't been talking in terms of "the parser should be capable of outputting a tune". I think the parser should be capable of outputting everything from a note upwards. Its up to the user of the parser to choose what output they get.
Stephen -- Stephen Kellett Object Media Limited http://www.objmedia.demon.co.uk RSI Information: http://www.objmedia.demon.co.uk/rsi.html To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html