Simon Wascher <[EMAIL PROTECTED]> writes: > Lets say you are right, its completely impossible that someone needs > that.
I'm not claiming that it is impossible for anybody to need this. But if this is a sensible proposal then surely there must be an example of an application that requires it? Obviously if there isn't an actual requirement for this notation (other than `Simon says so') there is no need to clutter up the standard with it. > So why bother about its syntax if you cannot imagine someone may need it? I do bother about the proposed syntax because I want the ABC standard to stay as simple and straightforward as possible (while still being as expressive as is reasonable). If this means we have to think more and harder instead of catering for every whim at a moment's notice then `tough'. The counter-proposal stands: Q:1/4=120 % [1] explicit tempo specification Q:1/4=120 note="Pretty quickly" % [2] explicit tempo with advisory note Q:Allegro % [3] symbolic tempo specification, metronome % speed (or range) defined elsewhere Q:Allegro note="Pretty quickly" % [4] symbolic tempo with advisory note Q:Allegro 1/4=120 % [5] definition of symbolic tempo Q:Allegro 1/4=120-128 % [6] definition of range and it is up to individual notation programs how they will display these bits of information, while player programs should default to the metronome speeds that are specified either explicitly in the tune or, in the case of symbolic tempo specifications, elsewhere, while giving users the chance to override the speed if they want. Suggestions for tempo display by notation programs: [1] .|=120 [2] Pretty quickly - .|=120 [3] Allegro Allegro - .|=120 % if desired, and if `Allegro' is defined accordingly [4] Allegro (Pretty quickly) Allegro (Pretty quickly) - .|=120 [5] and [6] will not be displayed. Notation programs could also offer to display just metronome speeds or just advisory notes, or to suppress metronome speeds or advisory notes altogether. The `note="..."' construction may seem wordy but in fact it is consistent with similar notation elsewhere in (de-facto) ABC such as the `V:' and `K:' fields. This is a lot better than inventing ad-hoc syntax for every single field, such as the `Q:n/n=n - Andante' proposal seen earlier on. In fact at some point in the future it could allow us to say something like ... some music ... Q:1/4=120 mode="accelerando" ... more music ... Q:1/4=140 ... even more music ... to express a dynamic change of speed between two points in time. This falls naturally out of the `key=value' syntax, while in your proposal one would have to invent even more ad-hoc syntax on top of what is already there to allow this. > It is neccesary to encounter the edges of a choosen syntax to be able if > it is stringent, search deeply for the worst cases it produces. This is > how a syntax is developed. Every syntax has its dark corners and all we > can do is turn the pockets around till we find the least important > corner in our proposal to contain the blackest hole of our syntax. So > here it is: Q:n/n=n N/N=N andante, dark and sinister but without any > meaning in real life. I disagree. To apply some wisdom that I think goes back to Antoine de St. Exupéry, a common fallacy in language design is to consider a language complete when there is nothing left to add. (This leads us to abominations like C++.) In fact, a design is usually much better when there is nothing left to take away (and it still does what it is supposed to do). We don't need special syntax for every single ABC header field when there is a general pattern that we can apply, like the `key=value' convention outlined above. Anselm -- Anselm Lingnau .......................................... [EMAIL PROTECTED] When the gods wish to punish us they answer our prayers. -- Oscar Wilde, *An Ideal Husband* To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html