Laurie wrote: >OK, Anselm, let me try. >First of all it is NOT complicated to implement. It's pretty easy. >Secondly a language or a notation is not to be judged by whether or not you >can say silly things. (Anyone who judged a natural language by this >criterion would have to be barking in fact quite out of their tiny, so let's >not get our Allen's twisted). >I can't imagine why anyone would want to write >Q:1/4=120 1/4=80 >which would have the effect of playing at 120 while showing 80, so I am not >interested in whether it's legal or not. All non-trivial languages allow >you to write stupid things. This sentence is a syntactically correct but >syntactically incorrect sentence. This sentence is a colourless pink >banana. 2+2 = -3.7 and so on.
OK. >So that leaves discussion of what you can do. >People wanted >a. The ability to define a name for a tempo OK - can do: >Anywhere outside the scope of another tune and before the X: of the tune >where it is to be used, write: >Q:1/4=80 largo I have two problems with this. First (as I said before) it causes trouble for programs which treat an abc file as random-access if you allow the macro definitions in between tunes (as opposed to in the file header). Secondly Q: is already a legal field in the file header under the abc 1.6 definition, so you really need something to mark this out as a macro definition rather than a default setting for tempo to be used in all the following tunes. >b. The ability to use that tempo and have it displayed and played. Can do: >In the tune (body or header) write: >Q: largo OK. >c. The ability to say something meaningful to a computer about how it is to >be played at the same time as writing something meaningful to a human (and >preferably meaning the same thing) displayed. Can do (but the bit about >meaning the same thing is not enforced). >In the header or body of the tune write >Q:1/4=80 largo OK. >d. The ability to have a tempo set for the computer to play the music but >without anything displayed. Can do: >In the tune (body or header) write >Q:1/4=80 - I don't see the necessity to specify in the abc what the program should do with the data. Surely (as Anselm has pointed out) these are local options to be set in a preferences file or command-line switch? >e. The ability to accept old style ABC. >Can do, for instance >Q: 1/4=80 OK. >f. Do all this without upsetting old programs too much if they are fed the >new. >As all the new stuff occurs on the end of a legal old-style command, there >is reason to hope that old programs might not be too upset by versions c or >d (and of course not by e). They don't faze current versions of BarFly as long as the numerical specification comes first. >g. Do all this in such a way that it is easy to implement in existing or new >computer programs. OK. >Now, considering that all of this is optional so you never need to use any >of it unless you actually want to do these things, I submit it is *not* too >complicated but is about as simple as it could possibly be. If you have a >simpler scheme that does a..g, please say! I don't see any point in being able to write one tempo for display in the abc and another, different tempo for playback, but that the ability to do that is just a side effect of what is being proposed here. Phil Taylor To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
