John Chambers wrote:
>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..
No, there's only one header. The first K: field in the tune is the
one which terminates the header, and all other K: fields are within
a voice, and operate only on that voice. If you need to set the key
separately for each voice you can do so as above, but you should have
a master K: field which comes first, and sets the real key of the piece.
This is then the default for all voices. So if your example above
was in the key of D (as played) you could write:
X:
T:
K:D %Marks the end of header and the default key.
V:1
K:C
(music)
V:2 %this voice is in the default key, so needs no K: of its own.
(music)
V:3
K:A
(music)
>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.
That's a very fundamental change, and would mean re-writing all the
existing software.
>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.
BarFly allows clefs in V: lines in the header; it treats these lines
in a completely different way from V: lines in the tune, using them to
set initial values for all sorts of things. Clef changes in the tune
have to go in K: fields.
Phil Taylor
To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
