Steve Mansfield sez:
| Guido Gonzato <[EMAIL PROTECTED]> wrote :
| >> That's all: there is no need to have more information in this field.
| >> Now, let's focus on the printing (%%staves -> s: ?) and playing
| >> (%%MIDI -> m: ?) information fields...
| >
| >I guess somebody might argue that these fields shouldn't be part of abc,
| >since they deal with specific music features like typesetting and playing.
|
| Absolutely. The definition as proposed summarises the (IMHO) consensus
| over the usage of the V: field to delineate voices in multi-part music. Let us
| please not drown that model of clarity in a heap of application-specific
| instructions!
Perhaps, but I think we could use a few specific examples. My main
reason is that I find myself getting confused when I try to figure
out the "correct" way to use V: and K: lines. The current standard
says that K: ends the headers. So if a V: line is followed by a K:
line, that K: is the end of the headers, and the music should follow.
But this doesn't really make sense, because if I have a band of
transposing instruments, I need to state the key for every
instrument, not just once for the whole tune. So I'd have what looks
like a bunch of headers:
X:
T:
V:1
K:C
(music)
V:2
K:D
(music)
V:3
K:A
(music)
Is this correct? It is syntactically a bit wierd, because the K:C
line is officially the end of the headers. There are thus no
definitions of V:2 and V;3 in the headers; they just appear suddenly
in the "music" section without any warning..
Maybe we should just quietly do away with the "header" vs "music"
distinction. There are "header lines" and "music lines", which can be
in any order that makes sense. The only restrictions might be that
the X: line must be first, and things must be defined before they are
needed. So, for example, if you don't have the M: or L: lines before
the first bit of music, you will get the defaults. T: and P: lines
will be shown wherever they appear. And so on.
In Michael Methfessel's last version of abc2ps, his notes mention the
problems caused by implementing V: lines, and the ensuing fuzziness
of how V: interacts with K: lines. There are some minor bugs in
handling the header/music boundary, such as dropping some P: lines.
He also implemented clefs in both the K: and V: lines. This makes
sense when you try producing examples that you can explain to
novices. With no V: lines, the K: line is the obvious place to put
clef changes. But with multiple voices, a clef is clearly something
that only applies to one voice, and doing it with a K: line is rather
counter-intuitive.
Anyhow, maybe we need a set of simple test cases that show just how
users should code multi-voice music. It might help if people involved
with different kinds of music could write the test cases, to show the
sorts of things that implementers should be prepared to handle.
To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
