Re: [abcusers] Continuation Lines
On Thu, 11 Mar 2004, John Walsh wrote: As I remember, the real problems with the continuation---apart from the incompatibility of 1.6 and 2.0---come when there was a mixed bag: several staves, lyrics, etc. The bottom line of that discussion was, that continuations are of not much use in complex scores: in scores with multiple voices, it is not feasible to spell out the complete line formatting in the ABC file; instead the software should take care of it. To explicitly force the software to introduce a line break at some places, ABC 2.0 adopted the !-character. In general, the ABC 1.6 continuation mechanism was found to be overly complex, so ABC 2.0 replaced it with a more straightforward and simple mechanism. Groeten, Irwin Oppenheim [EMAIL PROTECTED] ~~~* ABC Standard: http://abc.sourceforge.net/standard/ Chazzanut Online: http://www.chazzanut.com/ Synagogue Choir: http://www.ask-choir.org/ Business: http://www.amsterdamhotelspecials.com/ To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] Continuation Lines
On 10 Mar 2004, at 23:39, Steven Bennett wrote: Hi! I'm in the process of writing Yet Another ABC Parser as part of a larger project I've been working on for a while. (There are umpteen jillion reasons why I'm not using an existing parser - the biggest being this one is written in Objective C, but that's besides the point...) Ideally I'd like this to be able to handle files which conform to ABC 1.6, ABC 1.7.6, and the ABC 2.0 draft spec (dated Aug 14, 2003), but there are numerous little quirks and differences. The quirk I'm wrestling with today is Continuation Lines, which seems to be the biggest single area (and the biggest can of worms on the list archive) where the 1.6 1.76 specs seriously conflict with the 2.0 draft spec. Files written one way will parse ONLY if you use the 1.6/1.7.6 method, and files written another way will parse ONLY with the 2.0 method. And I don't see any mechanism (short of a good AI) to figure out which way during the parse. So I'm going to implement both and allow the user to decide which to use via a runtime switch. So... The 2.0 continuation line specification is almost trivial to implement. The only area which could use a bit of clarification there is it's effect during History fields. For example: ... H: This is some history This continues the history So does this And this too %%and this isn't an xcommand % But is this a comment? If you display % the history field, is it included? % I believe the answer should be No... And what about this? X \ Would this appear on the same line as the X \ If the history was displayed to the user? (IMHO, Yes) And here's the real challenge: \ % oh boy O: Is this the Origin or part of the History? I think it's part of the history myself And that *this* line is the last line of the history. O: This is the real origin... ... Does this interpretation of the ABC 2.0 variant make sense? Comments aren't actually part of the history field, and continuations *do* apply? I'd agree with that, although since most of it is an abuse of the H: field it doesn't really matter! (Meaning that it's pretty obvious how the H: field is intended to be used, and programs can't really be blamed if they get a bit confused with strange constructions like the above.) 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. The spec is indeed very vague. I have always interpreted it in the way specified in abc 2.0, and I see that spec as essentially a clarification of the previous ambiguity. However you may come across some abcs which interpret the spec differently. Taking that as a given, then \ would only be meaningful on tune body or lyric lines, and ignored (possibly generating warnings) on other fields. It would not allow putting field-like text inside a History field as described above. You would also require the w: at the start of the continued lyric line, unlike 2.0 which would require it NOT be there. Does anyone see anything I'm missing here? The question becomes how to deal with comments. I saw plenty of discussion of whether the \ is ignored if it follows a comment, or whether it's invalid if it isn't the very last character on the line. I guess it depends on whether you look for the \ first or the comment first. Is there any consensus out there as to which is the proper approach when you are parsing files using pre-2.0 continuations? (Or should I make *that* a user switch as well...) My own program has always permitted continuations in non-tune fields, and ignored the \ if it's not the last character in the line. Phil Taylor To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
RE: [abcusers] Continuation Lines
Hi Steven, I've wrestled with the same issues. Here is how I handle it in iabc: if the '\' is the last character in the line, I read them as seperate lines in the parser but put the music from the second abc line on the same music line. If it is present in the w: line, it is used to 'escape' the special meaning characters (e.g. '-'). I don't allow the user to break up measures with the '\', it is really used to keep 2 lines of abc on the same line. H: I skip everything until the next header. This would include everything, even abc music I guess. I don't display history, I just ignore it. I preprocess all comments and thus don't do anything (yet) with '%%'. Finally, some barfly conventions simply won't parse with the 'standard' rules so I allow the user (via the GUI in my case) to flag the user of 'alternate' rules. For instance, the V: at the start of lines that contain music, without the '[]' container. WIth this logic I'm able to parse all of the 'folksy' tunes that I've come across, including all from Mr. Norbert's collection that I have tried. I can also do all or most of the 'Embro Embro' collection, with the Barfly options turned on. -Original Message- From: Steven Bennett [mailto:[EMAIL PROTECTED] Sent: Wednesday, March 10, 2004 3:39 PM To: [EMAIL PROTECTED] Subject: [abcusers] Continuation Lines Hi! I'm in the process of writing Yet Another ABC Parser as part of a larger project I've been working on for a while. (There are umpteen jillion reasons why I'm not using an existing parser - the biggest being this one is written in Objective C, but that's besides the point...) Ideally I'd like this to be able to handle files which conform to ABC 1.6, ABC 1.7.6, and the ABC 2.0 draft spec (dated Aug 14, 2003), but there are numerous little quirks and differences. The quirk I'm wrestling with today is Continuation Lines, which seems to be the biggest single area (and the biggest can of worms on the list archive) where the 1.6 1.76 specs seriously conflict with the 2.0 draft spec. Files written one way will parse ONLY if you use the 1.6/1.7.6 method, and files written another way will parse ONLY with the 2.0 method. And I don't see any mechanism (short of a good AI) to figure out which way during the parse. So I'm going to implement both and allow the user to decide which to use via a runtime switch. So... The 2.0 continuation line specification is almost trivial to implement. The only area which could use a bit of clarification there is it's effect during History fields. For example: ... H: This is some history This continues the history So does this And this too %%and this isn't an xcommand % But is this a comment? If you display % the history field, is it included? % I believe the answer should be No... And what about this? X \ Would this appear on the same line as the X \ If the history was displayed to the user? (IMHO, Yes) And here's the real challenge: \ % oh boy O: Is this the Origin or part of the History? I think it's part of the history myself And that *this* line is the last line of the history. O: This is the real origin... ... Does this interpretation of the ABC 2.0 variant make sense? Comments aren't actually part of the history field, and continuations *do* apply? 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. Taking that as a given, then \ would only be meaningful on tune body or lyric lines, and ignored (possibly generating warnings) on other fields. It would not allow putting field-like text inside a History field as described above. You would also require the w: at the start of the continued lyric line, unlike 2.0 which would require it NOT be there. Does anyone see anything I'm missing here? The question becomes how to deal with comments. I saw plenty of discussion of whether the \ is ignored if it follows a comment, or whether it's invalid if it isn't the very last character on the line. I guess it depends on whether you look for the \ first or the comment first. Is there any consensus out there as to which is the proper approach when you are parsing files using pre-2.0 continuations? (Or should I make *that* a user switch as well...) --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] Continuation Lines
As I remember, the real problems with the continuation---apart from the incompatibility of 1.6 and 2.0---come when there was a mixed bag: several staves, lyrics, etc. In that case, there are natural musical groupings, and there was a discussion on how, or whether, to have smart continuations which would work on a whole group, or within a group. A few ideas were suggested. Barry Say made a fairly far-reaching proposal for doing this, but I don't think the discussion continued much beyond that point. Cheers, John Walsh Steve Bennett writes: Hi! I'm in the process of writing Yet Another ABC Parser as part of a larger project I've been working on for a while. (There are umpteen jillion reasons why I'm not using an existing parser - the biggest being this one is written in Objective C, but that's besides the point...) Ideally I'd like this to be able to handle files which conform to ABC 1.6, ABC 1.7.6, and the ABC 2.0 draft spec (dated Aug 14, 2003), but there are numerous little quirks and differences. The quirk I'm wrestling with today is Continuation Lines, which seems to be the biggest single area (and the biggest can of worms on the list archive) where the 1.6 1.76 specs seriously conflict with the 2.0 draft spec. Files written one way will parse ONLY if you use the 1.6/1.7.6 method, and files written another way will parse ONLY with the 2.0 method. And I don't see any mechanism (short of a good AI) to figure out which way during the parse. So I'm going to implement both and allow the user to decide which to use via a runtime switch. So... The 2.0 continuation line specification is almost trivial to implement. The only area which could use a bit of clarification there is it's effect during History fields. For example: ... H: This is some history This continues the history So does this And this too %%and this isn't an xcommand % But is this a comment? If you display % the history field, is it included? % I believe the answer should be No... And what about this? X \ Would this appear on the same line as the X \ If the history was displayed to the user? (IMHO, Yes) And here's the real challenge: \ % oh boy O: Is this the Origin or part of the History? I think it's part of the history myself And that *this* line is the last line of the history. O: This is the real origin... ... Does this interpretation of the ABC 2.0 variant make sense? Comments aren't actually part of the history field, and continuations *do* apply? 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. Taking that as a given, then \ would only be meaningful on tune body or lyric lines, and ignored (possibly generating warnings) on other fields. It would not allow putting field-like text inside a History field as described above. You would also require the w: at the start of the continued lyric line, unlike 2.0 which would require it NOT be there. Does anyone see anything I'm missing here? The question becomes how to deal with comments. I saw plenty of discussion of whether the \ is ignored if it follows a comment, or whether it's invalid if it isn't the very last character on the line. I guess it depends on whether you look for the \ first or the comment first. Is there any consensus out there as to which is the proper approach when you are parsing files using pre-2.0 continuations? (Or should I make *that* a user switch as well...) --Steve Bennett To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
[abcusers] Continuation Lines
Hi! I'm in the process of writing Yet Another ABC Parser as part of a larger project I've been working on for a while. (There are umpteen jillion reasons why I'm not using an existing parser - the biggest being this one is written in Objective C, but that's besides the point...) Ideally I'd like this to be able to handle files which conform to ABC 1.6, ABC 1.7.6, and the ABC 2.0 draft spec (dated Aug 14, 2003), but there are numerous little quirks and differences. The quirk I'm wrestling with today is Continuation Lines, which seems to be the biggest single area (and the biggest can of worms on the list archive) where the 1.6 1.76 specs seriously conflict with the 2.0 draft spec. Files written one way will parse ONLY if you use the 1.6/1.7.6 method, and files written another way will parse ONLY with the 2.0 method. And I don't see any mechanism (short of a good AI) to figure out which way during the parse. So I'm going to implement both and allow the user to decide which to use via a runtime switch. So... The 2.0 continuation line specification is almost trivial to implement. The only area which could use a bit of clarification there is it's effect during History fields. For example: ... H: This is some history This continues the history So does this And this too %%and this isn't an xcommand % But is this a comment? If you display % the history field, is it included? % I believe the answer should be No... And what about this? X \ Would this appear on the same line as the X \ If the history was displayed to the user? (IMHO, Yes) And here's the real challenge: \ % oh boy O: Is this the Origin or part of the History? I think it's part of the history myself And that *this* line is the last line of the history. O: This is the real origin... ... Does this interpretation of the ABC 2.0 variant make sense? Comments aren't actually part of the history field, and continuations *do* apply? 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. Taking that as a given, then \ would only be meaningful on tune body or lyric lines, and ignored (possibly generating warnings) on other fields. It would not allow putting field-like text inside a History field as described above. You would also require the w: at the start of the continued lyric line, unlike 2.0 which would require it NOT be there. Does anyone see anything I'm missing here? The question becomes how to deal with comments. I saw plenty of discussion of whether the \ is ignored if it follows a comment, or whether it's invalid if it isn't the very last character on the line. I guess it depends on whether you look for the \ first or the comment first. Is there any consensus out there as to which is the proper approach when you are parsing files using pre-2.0 continuations? (Or should I make *that* a user switch as well...) --Steve Bennett To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
