On 12 Mar 2004, at 23:24, Steven Bennett wrote:
I. Oppenheim wrote:
As for the 1.6 and 1.7.6 specifications, regardless of what program X, Y, or
Z does, the written spec is awfully vague. I have several possible
approaches to different elements of this, but the basic concept appears to
be that "\" at the end of a line isn't so much a continuation, but a "don't
break the staff here if you would normally".
No. In 1.* it basically meant: continue on the next line of the same type. (Whereas in 2.0 it means: continue on the next physical line, regardless of the context)
I don't think I can accept that definition, even though looking at the
archives, I've seen that definition before. It implies far too many things
which are problematic and not at all true for the programs I have here. Of
course, I've only been testing with Barfly 1.52 and abcm2ps 3.7.18 right
now. Doubtless other programs behave differently.
Problem 1: It implies that you could break a line arbitrarily. For the ABC
2.0 style continuations, that is indeed the case, but we're talking about a
1.* specific parser here, where you can have other lines in-between. So if
you allow breaking a line arbitrarily, you could end up with something like
this:
X:1 T:some made up tune M:4/4 K:Dminor abcd|efga|[K:\ M:3/4 G]def|gab|
...which would need to cache part of the first line (the "[K:" part) until
the next tune data line arrived and it had the remaining info it needed to
finish parsing stuff. Even without the meter change in the middle, both
Barfly and abcm2ps give parse errors on that.
It's a pretty outrageous example. I don't think that parsers should have to deal with continuations in the middle of inline fields, let alone an example with another (non-inline) field inserted in the middle.
And it doesn't need a field -- try something like:
abcd|efga|c'\ ''def||
...and you still get errors with both programs, even with nothing inbetween
the lines.
Doesn't the standard say somewhere that the symbols which form a note cannot be split across line continuations? Even if it doesn't, it ought to.
Likewise a lyric line would need to cache partial syllables. Take:
X:2 T:another made up tune M:4/4 K:Dminor abcd|efga|bcde|| w:a1 b2 c3 d4 e5 f6 g\ w:7 a8 b9 c10 d11 e12
Now here, Barfly apparently only uses the abc 2.0 style continuations (for
lyric lines - odd that it doesn't do the same for tune data lines...),
It's supposed to. With the best will in the world I can't always cope with seriously strange interpretations of abc syntax like the above, even if they are technically legal.
so it
always ends up with "gw:7" as a syllable, but ends up with the syllables in
the right place. abcm2ps renders this with the g and the 7 as separate
syllables, so all the following syllables are off by one note.
All of which leads me to conclude that under 1.*, you cannot continue a tune
line or a lyric line at any arbitrary character point -- you need to
continue it at a point where a staff or lyric line break would be valid.
In practice, yes.
Problem 2: It doesn't have any inherent limitation on what "line of the same
type" could be. Which means you could continue just about any sort of line.
Such as:
X:3 T:yet another made up tune M:4/4 K:Dminor abcd|efga|[K:G]\ M:3\ bcde|\ M:/4 def|gab|
...complains about the split Meter line in both Barfly and abcm2ps. (With
or without the intervening bcde line...) So it appears to me that it can't
work with just any arbitrary field -- IMHO, the only fields it even makes
sense to use it on (under 1.*) are tune body lines and lyric lines.
And even then it causes all sorts of problems.
So... If it can only occur on tune and lyric lines, and it can only occur
where a staff break or lyric line break would be valid, then that is why I
suggested a definition along the lines of:
"A backslash ("\") at the end of a line means do not break the staff or lyric line at this point if that's what would happen because of the following line ending."
It becomes pretty straightforward (actually fairly easy) to parse if you
define it that way, and seems fairly consistent with the 1.* usage.
Anyone see any gaping holes in that logic?
You have still left open the question of whether programs should look for a simple continuation on the next line, or look for a field identifier if appropriate. (e.g. a w: field)
Phil Taylor
To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
