Jack writes: | > There is a lot of abc that would give strange results from the | > shortest-note rule. Recently someone pointed out that some of my | > files have notation like [A3G] with no length for the second note. | > There's a reason for this. | | It doesn't matter what the reason is, there can't be so many files | like that that it's worth distorting the whole design of ABC to fit | them. | | The solution for problems like that is to write a conversion utility, | fix any legacy files with it and then move on.
You're right, of course. However, if I were to spend time time writing such a conversion program right now, it would almost certainly be wrong. The current discussion has all I need to convince me of that. It's obvious that I (and probably lots of other abc users and implementers) don't clearly understand what the rules are here. Or, more likely, what the (currently rather ambiguous rules) will be when people finally iron out an agreement. I can probably hack together a little perl program that will do the job, and it will probably only take me 10 or 20 minutes. But I don't really want to do this a dozen times; I'd rather do it once. It'll probably be a few years before the abc community decides what the output should look like and published a clear, unambiguous standard doc that I can code to. In particular, since among other things I've been working with a few player programs, I've generally typed chords with the assumption that the first note was whatever I thought was the "melody" note. This works (for some value of "works") with programs that I have now. But it's becoming obvious that others think the note order should mean something else. Since I don't quite follow all the arguments, I don't think I should be prematurely writing any code that will be based on what is probably a misunderstanding. So for now, I might as well not waste my time. I'll just wait until I understand what the converter's output really should be. In the meantime, I'll fix things up by hand when I stumble across them, and work on the principle that "If it works with the tools at hand, that's good enough for now". Back to you ... ;-) To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
