> Chord notation is not free text. It is a chord. There may be no
> restriction to the syntax of a chord to be presented, but semantically,
> it's a chord.
And for some playback programs (Muse is one, I think) chord semantics is
both precisely defined and used by the interpreter; Laurie suggested
standardizing it a while back and nobody seemed to have much problem with
what he suggested (where there are idioms with different conventions,
this is another place where a definition mechanism could be used). A tool
that created ABC piano scores from guitar-style notation (are there any?)
would need the same semantics, i.e. this isn't just about playback.
> Likewise, tempo indicators are not free text. They are tempo
> indicators. There may be no restriction to the syntax of a tempo
> indication, but semantically, it's a tempo indicator.
Semantics is about giving expressions *values*. It's a feeble sense
of the word that ignores that. An indication that doesn't have a value
and can't be given one doesn't have a semantics the way I see it.
> "_Excitedly" and "_Placidly" are not tempo indicators. They may print
> out in tadpoles as tempo indicators, but they will not be read by human
> readers of the ABC notation, nor by playback programs, as tempo
> indicators.
They fit just fine into the remit of the "R:" field, though. It wouldn't
hurt a bit if we made finer distinctions than staff notation does over
this one. (Icky example from a 19th century edition I've got: finale of
Beethoven's string quartet op18 no6, "La Malinconia Adagio" all in the
same font used for tempi elsewhere - since when was "La Malinconia" a
tempo?)
:> So, *how* does it describe the speed? How does your suggestion
:> distinguish texts that define speeds from arbitrary gibberish?
: It doesn't, at least it doesn't any more than a program can
: distinguish between the actual title of the tune in the title field and
: arbitrary gibberish. I don't see a standard (as in ABC standard) way
: of being able to check this field without severely limiting the text
: that can be put in here
I suggested a way: "sdbdkjvhfdb" defines a tempo if there's a tempo
definition in the environment, i.e. a line like
Q:[3/4] sdbdkjvhfdb 1/4=96
:> Any syntax that works in an external file can work in an ABC tune
:> file.
: I don't think I understand what you're talking about here. Do you
: mean that any external file that any program decides to use should
: be capable of being put into an ABC file?
I mean that if the external file syntax is sanely designed we can add the
design to the syntax of ABC. As it stands, it seems that externality is
being used as an excuse for using any old rubbish as notation - on the
assumption that only one program will ever use it and hence that only one
programmer needs to care how twisted it is. There are enough historical
precedents now to say how dangerous an attitude that is in the long term.
:> What happens if you put a "q:" field into a tune and feed it to
:> abc2win? (If it breaks, there's no advantage over altering the
:> syntax for "Q:").
: And again, this illustrates the need for some sort of namespacing
: to allow us to add features to the standard without breaking
: backwards compatibility, and also to allow program specific
: extensions.
In future, yes, but for this specific case, if abc2win behaves as I'm
guessing it might, there is *no* way forward without letting people
create ABC files it can't handle. So we might as well redefine the
existing field's syntax and save "q:" for something else later on. Once
we get all commonly used programs doing the silent-acceptance thing, we
can follow the line you're advocating.
] how does abc distinguish between `arbitrary gibberish' and music in
] general?
The way it currently interprets the note "A". The only way it can assign
a duration to that is by looking up an "L:" field (or inferring one from
an "M:" field) and the only way it can assign a definite pitch to it is
by looking at the "K:" field. I'm suggesting tempo should be a matter
for another environment lookup, but a nonlocal one to an extent that the
standard already permits for "M:" and "L:".
It *might* be okay to relax things so that files didn't need to define
all the tempi they use; that would not be portable, but it would be
portable among display-only programs, and there aren't so many tempi in
any one source that adding the definitions would be a great hassle for
people using the same files for purposes like playback or the computation
of overall timings.
(I was talking about proposals for definitions of tempo by formalisms
confined to external files...)
]> Which has what syntax?
] <field name><colon><text>
] examples:
] q:gayment
] q:allegro con moto
That's not what I was I was asking for. That's *use*, I was talking
about *definition*. How would you define "allegro con moto" in an
external file? Why does doing so make the syntactic problem any easier?
+ in every printed score I own, the tempo text, expression text, and
+ guitar chords are distinguishable from one another by their typeface
+ alone.
But they aren't *identifiable* by their typeface alone - no two publishers
use the same set of conventions. In practice you know which is which by
looking at the text; once you've spotted the first "sehr langsam" you can
guess that any subsequent German phrases in the same typeface and placement
relative to the staff are going to be tempo marks.
In any case, is merely being able to implicitly specify a different
typeface for tempo indications a feature worth the bother of implementing?
Will it increase the number of people attracted to ABC by as much as 1%?
I can *use* the ability to redefine speeds given textual names; without
that capability I have no use whatever for extensions of the tempo
constructs. I don't give a damn about reassigning typefaces (fonts,
maybe: someday I'd like to be able to do Gaelic or Turkish text in titles
and "w:" lines and have it be both portable and readable as source by a
Turkish or Gaelic speaker, but I am aware how big an upheaval that would
take).
There is another issue with tempo I raised a long time ago which the
"q:" proposal doesn't help with - how do you express a change in metre
from C| to 6/4 with the former 1/2 taking the same time as the later
3/4, *without* putting any explicit tempo in the score at the point of
the change? This happens frequently in Renaissance music and in dances
like the Gay Gordons. It could be done indirectly by using the same
tempo name for both sections and saying what the relevant beat length was
(a capability other people have suggested for other and good reasons),
but in practice what almost all printed scores do is write
<dotted minim> = <minim>
which in ABC would be something like
Q:3/4:=1/2 % no textual stuff involved, hence not a task for "q:"
i.e. an essential extension of the "Q:" field that would *have* to break
any old program that encountered it. So what if it did? If I want to
transcribe stuff by Monteverdi or Jimmy Shand that uses this, why should
legacy parsers neither I nor any of my intended readers are ever going
to see get in my way?
It's hardly the end of the world if old programs can't handle a new ABC
feature. I'd estimate the fraction of ABC tunes I get off the web that
work at all reasonably without editing as around 50%, and only 20% hit
the printer without a bit of polishing up. Editing is something we just
have to live with; if the source is at all well written, however spooky
the platform the author was aiming at, it's obvious what to do and no big
deal. When it starts to get complicated, smart editing tools or automated
converters can have the same effect as upgrading an old program (even
Microsoft has figured that out, with its converters to use late-format
Word files with older versions of the program - they work).
=================== <http://www.purr.demon.co.uk/jack/> ===================
To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
