Re: [abcusers] Re: ABC 1.x continuations (was ABC 2.0 draft)
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) Actually, I think that by phrasing it the way I did above, there is no assumption made at all about the next line, so it's parsed exactly as you would parse any other field/tune data line. I'm basically avoiding the term continuation in 1.* parsing because that confuses the issue -- I see it as not so much a continuation as a break/no-break flag on the line. The assumption I *am* making is that the decision to break the staff or lyric line is made when the end of line is parsed. Without a \ character, the staff or lyric line is normally broken. With a \ just before the end of line, the staff or lyric line is not broken. Thus, for a w: field with a \ at the end, you *would* have the w: on the next lyric line, which doesn't have to happen immediately. Of course, this begs another 1.* specific question - should I ignore \ at the end of non tune data or lyric lines, or flag them as parse errors or warnings? For simplicity, I'm leaning towards simply ignoring them. --Steve Bennett To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] Re: ABC 1.x continuations (was ABC 2.0 draft)
I like this way of doing it. I think that it is clearer than what I was proposing a couple days ago. This would mean that the backslash at the end of a line does not have the semantics currently written in the 2.0 spec, but it is more backward compatible with 1.x, it is defined well enough to parse without ambiguity, and it does everything that seems to be needed. If we had the ability to specify an all voices line, that would complete it :-). Then we could write my previous example as (with a little more detail): X:1 T:test M:C L:1/8 K:D [V:S] ccAbccA2| fdab\ w:a-a-a-a a-a-a-a | a-a-a-a \ [V:A] ccAbccA2| fdab\ w:i-i-i-i i-i-i-i | i-i-i-i \ [V:*] [K:G] [M:3/4] [V:S] xd | c3 c3 | w:a-a | a a | [V:A] xd | c3 c3 | w:i-i | i i | And it is perfectly clear what it is supposed to do. There is no ambiguity about what the backslashes relate to. Although, you should modify your statement so that it can occur on tune, lyric, and symbol lines (add the symbol to the list). tom Steven Bennett said: 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) Actually, I think that by phrasing it the way I did above, there is no assumption made at all about the next line, so it's parsed exactly as you would parse any other field/tune data line. I'm basically avoiding the term continuation in 1.* parsing because that confuses the issue -- I see it as not so much a continuation as a break/no-break flag on the line. The assumption I *am* making is that the decision to break the staff or lyric line is made when the end of line is parsed. Without a \ character, the staff or lyric line is normally broken. With a \ just before the end of line, the staff or lyric line is not broken. Thus, for a w: field with a \ at the end, you *would* have the w: on the next lyric line, which doesn't have to happen immediately. Of course, this begs another 1.* specific question - should I ignore \ at the end of non tune data or lyric lines, or flag them as parse errors or warnings? For simplicity, I'm leaning towards simply ignoring them. --Steve Bennett To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html -- tom satter - or just plain old tom (303) 543-7623 (home) To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] Re: ABC 1.x continuations (was ABC 2.0 draft)
Except I'm only proposing this as an aid in defining how to parse 1.* style completions (when the user has selected that as a parsing flag...), not as a change to the 2.0 spec. I actually prefer the 2.0 continuation mechanism, although I'm not strongly attached to it and could see how the 1.* style, defined the way I suggested, could actually make more sense. (Especially, as I think about it, in light of the %%continueall XCommand, which certainly should NOT behave as if one had placed a 2.0 style continuation on each line, but *should* behave, IMHO, as if there was a 1.* style continuation there...) As for the all voices line, I'm not sure I like that idea all that much -- it creates a new parsing state which opens up a number of cans of worms - specifically what is legal when you are in an all voices section and what is not. Possibly a better approach would be using something like [V:*=S] to assign the current voice specific settings of voice S to all other voices. That field would *not* have the side effect of changing voices. (You might also allow [V:A=S] or the like.) So your line below: [V:*] [K:G] [M:3/4] ...might instead read: [V:S] [K:G] [M:3/4] [V:*=S] ...and you would end up being in voice S. I don't know if I like that much either (you still need to define *exactly* which voice specific settings get copied and which do not), but from a parsing point of view, I much prefer it over what you were suggesting. --Steve Bennett I like this way of doing it. I think that it is clearer than what I was proposing a couple days ago. This would mean that the backslash at the end of a line does not have the semantics currently written in the 2.0 spec, but it is more backward compatible with 1.x, it is defined well enough to parse without ambiguity, and it does everything that seems to be needed. If we had the ability to specify an all voices line, that would complete it :-). Then we could write my previous example as (with a little more detail): X:1 T:test M:C L:1/8 K:D [V:S] ccAbccA2| fdab\ w:a-a-a-a a-a-a-a | a-a-a-a \ [V:A] ccAbccA2| fdab\ w:i-i-i-i i-i-i-i | i-i-i-i \ [V:*] [K:G] [M:3/4] [V:S] xd | c3 c3 | w:a-a | a a | [V:A] xd | c3 c3 | w:i-i | i i | And it is perfectly clear what it is supposed to do. There is no ambiguity about what the backslashes relate to. Although, you should modify your statement so that it can occur on tune, lyric, and symbol lines (add the symbol to the list). tom Steven Bennett said: 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) Actually, I think that by phrasing it the way I did above, there is no assumption made at all about the next line, so it's parsed exactly as you would parse any other field/tune data line. I'm basically avoiding the term continuation in 1.* parsing because that confuses the issue -- I see it as not so much a continuation as a break/no-break flag on the line. The assumption I *am* making is that the decision to break the staff or lyric line is made when the end of line is parsed. Without a \ character, the staff or lyric line is normally broken. With a \ just before the end of line, the staff or lyric line is not broken. Thus, for a w: field with a \ at the end, you *would* have the w: on the next lyric line, which doesn't have to happen immediately. Of course, this begs another 1.* specific question - should I ignore \ at the end of non tune data or lyric lines, or flag them as parse errors or warnings? For simplicity, I'm leaning towards simply ignoring them. --Steve Bennett To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] Re: ABC 1.x continuations (was ABC 2.0 draft)
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
