Well, there hasn't been much response on the list, though I did get a couple of private messages on the topic. It seems to me that the main question to be decided is between:
John Chambers wrote: >m: T !trill! >m: ~ !roll! >m: H !fermata! Phil Taylor wrote: | U: R = arpeggio As I recall, there might have been one or two other letters suggested in addition to 'm' and 'U'. Anyone recall? This isn't a real big deal, of course. The actuall syntax is more of a deal, but even that isn't all that important. I have no fear of the idea that my implementation would make both the '=' and the '!' optional. I doubt if many other programmers would consider this a major hassle. What I'm considering is just a trivial definition facility that amounts to no more than text substitution, plus code in the parser that recognizes and accepts a list of !...! symbols. I figure I could implement this in a morning. One of my primary motives is that my tune finder is trying to return tunes from around 240 web sites now, and there is little consistency in what some of the letters above G mean. This doesn't matter if people fetch the abc, but lots of users ask for GIF or PDF, and in many cases they get something very different from what was intended. Then I get the bug reports. I have to tell them that they're seeing one of the areas of abc that is not yet standardized, and there isn't much I can do to help them. One approach is to announce that the formatter behind the tune finder, jcabc2ps, understands this simple definition header line. So if you want your abc's ornaments to look right on other people's screens, there is one approach that will work (though it's not ideal). If you add the ornament definitions to your tunes, and others fetch the tunes via the tune finder's converter, then the ornaments will stand a good chance of coming out correct. This could slowly put pressure on other implementers to add the ability to output tunes with such ornament definitions in the header lines. This would be trivial to code in any language, of course. It would be just a fixed routine to write out some fixed text. Then, if this becomes popular, we might even see other apps that accept the definitions. There's also the possibility that the tune finder's code could attempt to guess the ornament definitions at a site and generate the definitions itself. But this is an AI project that might not be done in a morning (or ever). So should the header field be 'm' or 'U' or something else? I have a weak preference for 'm', because I think of this as a (parameterless) macro. I don't know what 'U' might stand for. But the letter doesn't really need to stand for anything, any more than 'Q' or 'Z' do. Also, how many abc apps already have something like this sort of ornament definition facility? Although I'm not yet considering a full macro extension, it might be nice to at least not do something that is in conflict with a gimmick that is already in use elsewhere. To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html