>| > After several online discussions, I (and probably a few others) have
>| > implemented the rather trivial extension of allowing any string of
>| > digits, commas, hyphens and periods to label an ending. This means
>| > that endings like [1,3 and [1-3 work with a very few abc tools.
> ...
>|
>| Does it behave correctly in this case?...
>| ...
>| K:D
>| ...(a)...
>| |: ...(b)... [1,3 [K:D Minor] ...(c)... :|
>| [2 ...(d)... || % no key change
>| ...(e)...
>|
>| The key signature is two sharps for the (a), (b) and (d) music and
>| one flat for the (c) and (e) sections. (I can easily imagine a piece
>| actually having this structure, and if there isn't one already out
>| there maybe I'll just write one...)
>
> Well, what I'd say is that it doesn't much matter, because this is
> rather bad notation. If you were to stick it on stands in front of a
> bunch of musicians, some would play (e) in D major and others would
> play (d) in D minor. You can insult the musicians all you want, but
> that wouldn't get them to do it right. (Of course, it's still a bit
> odd to see abc notation on a music stand. ;-)
>
> The right way is to put an "advisory" key change at the start of (e)
> to make it clear to everyone (human and software) what the intended
> key is. Otherwise, you are asking for a disaster when that point in
> the music is reached.
If the semantics is specified it *is* clear to the software.
You could simply say my example was illegal and *require* such an
advisory key signature, but your software would have to do exactly
the same semantic analysis to decide that the advisory was needed.
So that's no simplification at all for programmers.
> "Standard music notation" is a bit of an oxymoron, and subtleties
> like this are not understood in any consistent manner by musicians.
Doesn't matter if the musician is using the output of a correctly
implemented ABC-to-staff-notation generator. It'll put the right
key signature in for section (e) and the user doesn't need to know
how it got there.
> I'd also predict that, no matter what we might decide here, many of
> the folks who write abc software would probably not much notice, and
> would do whatever they damned well please. Or they'd not even
> consider the problem, and what the code does would be an accident.
> So, while it may be a Good Idea to say in the standard what happens
> in such cases, it wouldn't help all that much.
The point of my raising it was to get people to consider the problem.
I don't think there are any currently active developers as disconnected
from this list as you're suggesting.
> What abc2ps does is just take things in order. The [K:Dminor] causes
> a D minor signature to appear thereafter, until there's another K
> field.
This is correct if "thereafter" means the actual sequence of notes
played, wrong if it means the sequence of characters in the file.
In fact the description above wouldn't even work with the latter
interpretation for a 1.6-standard [1 ... [2 ... repeat, if the key
change was only on the first time.
> (I wonder if there are any players that would stay in D minor for
> the start of the repeat? Isn't that what the music says? ;-)
Laurie went over the precise analogue of this for the case of tempo
and beat constructs. The only difference is that key is something
display programs can't ignore.
Here is a real-life example (slightly reorganized from one in my modes
tutorial):
X:1
T:Sister Jean
S:Catriona Macdonald
M:6/8
L:1/8
Q:3/8=80
R:andante
K:DDor
D2E F2G|ABA G2F|E2C C2G|E3 D2C|D2E F2G|ABA A2G| A2d d2c|d3 D3:|
K:DMix
A2B c2d|efe e2c|A2B c2G|E3 [1 C3 |A2B c2d|efe e2d|[K:D]f2d d2c|d3 A3:|
[2 C2B|A2A F2D|A2A F2D| A2d d2c|d3 D3|]
BarFly gets the staff notation for that wrong but plays it correctly:
that is, the c's in the second-time repeat are printed sharp and played
natural. Does abc2ps print a two-sharp signature for the last line too?
Yes, it would be more conventional to just notate the above using
accidentals, but in the context it came from there was a specific
reason for using key/mode signatures instead.
> There's no excuse for this not being in abc after all these years.
Not having its interaction with the rest of the notation properly
specified so that it can be generally implemented seems a pretty
good excuse to me. I imagine many implementors vaguely anticipated
troubles along the lines of the those I've described, decided "here
be dragons", and put it off to such time as it might be unavoidable.
But the difficulties aren't insurmountable. Unrolling repeats and
header-controlled part order are source-to-source operations of the
sort that any decent ABC editing toolkit ought to have; they don't
require the implementors of player programs to understand PostScript
or those of formatters to understand MIDI. This stuff should be
common ground. If we're considering an open-source parser there's
no excuse for getting it wrong.
=================== <http://www.purr.demon.co.uk/jack/> ===================
To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
