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
