Re: [abcusers] [ABCp] Parts
Wil Macaulay wrote: Yes, I do have a suggestion: if you really want to implement a 'generic parser', start by choosing a standard to implement. If you want to suggest changes to the standard, do so as an independent process. Otherwise you'll end up with a parser that only parses non-standard abc... I've chosen the following approach: - first of all be compliant with 2.0 draft standard, - then include 1.6 standard as long as it does not harm the 2.0 compliancy - than include non standard (but commonly used and/or useful) syntax. For example, the 2.0 standard includes the -8 keyword to transpose an octave down, I've added the -15 and -22 keyword (that are avalaible in other notation packages) and also extended it to other clefs so that treble-8 is recognized (as the 2.0 standard requires) but so does baritone+15! There is one important thing to note here. ABCp is, at the present stage, a scanner, not a parser. This means that, in this case, ABCp reports to the host program that the user specified a clef with TWO octave transposition. It is entirely to the host program to decide if this is acceptable or not! ABCp is an enabler for programmers that want to write software that accept ABC files as input. Using ABCp they can concentrate on the functions of their software instead of losing time to accomodate this or that ABC extension. This concept is very crucial. Let me bore you a little bit with an example:. This is a 2.0 compliant Key: K:Bb mix ^^c_d mezzosoprano transpose=+5 stafflines=3 while this is the same key K:Bb Mix Db C##\ mezzo t5 s3 that makes use of some extensions. As far as the host program is concerned, the two keys above get reported exactly in the same way: [EMAIL PROTECTED] Sf [EMAIL PROTECTED] 053 @ (The string above is a serialized version of the binary representation of the parsed key field.) The host program will use a function like abcKeyTonic() to get Bb and abcKeySemitoneTranspose() to get 5 regardless the way those information are actually represented in the abc file. A function abcError() will report if something went wrong (for example if K:Lmin was encountered). If the host program wants to deal with the string itself, it may well do so using the abcString() function that returns the Key string as it appears in the file. I hope I've been clear enough. Please feel free to comment! BTW. I still have to figure out a clean interface! The functions above (abcKeySemitoneTranspose for example) are so ugly that I'm a little be ashamed to publicly release them! R:D To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] [ABCp] Parts
Yes, I do have a suggestion: if you really want to implement a 'generic parser', start by choosing a standard to implement. If you want to suggest changes to the standard, do so as an independent process. Otherwise you'll end up with a parser that only parses non-standard abc... having said that, I'd be happier with a parts directive that looks similar to existing ones, like K: - something like P:A label=Verse That is more consistent with K:C clef=bass (sorry for the testiness - I'm impressed with the progress you're making) wil Remo D. wrote: Neil Jennings wrote: I still think my suggestion is more general, as it allows the internal part name (one letter) to be totally independent of the displayed text (Part description). Remo's proposal would only allow one word (part name) to start with each letter. Therefore if there was a part Coda, there could not be any other part whose name started with C. (Using letters within a word would get confusing) Well, that's not what I meant. You can have Coda Chorus and Chaos, then you would define in the header P: (Chaos Chorus)2 Coda3 and in the body: P:Chorus P:Chaos P:Coda With my proposal you only miss the ability of having a piece named CHAOS (each part name MUST begin with a upper case letter and may continue ONLY with lowercase letters and numbers) but there's no limit in the number of parts that begin with a given letter. It seems to me that if you can give meaningful names to your parts, you gain in clarity : P: (Chaos, Chorus)2 Coda3 gives the feeling of two universal forces (the order being represented by a chorus) that compete each other until the unifying End. Writing P:(AB)2C3 does not gives the same feelings to me! But I digress :) . Anyway, I'll implement also your proposal in my parser. If in the body a P: partname; label field is found, the label will be considered for printing too. Any other suggestion? Bye, R.D 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] [ABCp] Parts
Neil Jennings wrote: I still think my suggestion is more general, as it allows the internal part name (one letter) to be totally independent of the displayed text (Part description). Remo's proposal would only allow one word (part name) to start with each letter. Therefore if there was a part Coda, there could not be any other part whose name started with C. (Using letters within a word would get confusing) Well, that's not what I meant. You can have Coda Chorus and Chaos, then you would define in the header P: (Chaos Chorus)2 Coda3 and in the body: P:Chorus P:Chaos P:Coda With my proposal you only miss the ability of having a piece named CHAOS (each part name MUST begin with a upper case letter and may continue ONLY with lowercase letters and numbers) but there's no limit in the number of parts that begin with a given letter. It seems to me that if you can give meaningful names to your parts, you gain in clarity : P: (Chaos, Chorus)2 Coda3 gives the feeling of two universal forces (the order being represented by a chorus) that compete each other until the unifying End. Writing P:(AB)2C3 does not gives the same feelings to me! But I digress :) . Anyway, I'll implement also your proposal in my parser. If in the body a P: partname; label field is found, the label will be considered for printing too. Any other suggestion? Bye, R.D To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] [ABCp] Parts
My program would reject (ignore) any part specification longer than one letter. Your proposal could lead to ambiguous part specifications, if one name matched part of another name. I can see the need for the part specification to have two 'parts', one the single letter identifier to be used in formulas, and the other the text which appears on the score. Perhaps we could propose a new syntax, e.g P:A ;Intro P:B ;Riff P:C ;Coda (where ; is used here to indicate a new separator character, not necessarily a semi-colon) The single letter is used in the formula, and the text following the separator is displayed on the score Hopefully, leaving a space would make it acceptable to existing programs? Neil Remo D. wrote: Neil Jennings wrote: Because the P: text appears above the staff, people have mis-used it to add comments which have nothing to do with parts. In the tune header, it can have a formula such as (AB)2(AC)3 In the body, it must be just a single letter HARMONY can play tunes according to the formula, including nested repeats. Neil Does this mean that my proposal is ok for you? If you have (like the standard says): % Header P:(AB)2C ... % Body P:A P:B It would work. But also it would work if you write: %Header P:(Intro Riff)2 Coda ... % Body P:Intro P:Riff ... As a general rule, my parser tries to accomodate as many synonyms as it can. A simple example is with decorations: !f! is equal to +f+ which is equal to +forte+. R.D 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] [ABCp] Parts
Neil Jennings wrote (about Remo proposal): My program would reject (ignore) any part specification longer than one letter. Your proposal could lead to ambiguous part specifications, if one name matched part of another name. Remo proposal (below) avoids ambiguity by distinguishing between upper/lower case letters: ` Each part name MUST begin with a upper case letter and may continue ONLY with lowercase letters and numbers ` ` P:AB- play part A then B ` P:OvertureCoda - play part Overture then part Coda ` P:OVERTURE CODA - play part O then V, then E, ... ` P:intro - ERROR ` ` Spaces and dots may separate part names. I can see the need for the part specification to have two 'parts', one the single letter identifier to be used in formulas, and the other the text which appears on the score. Perhaps we could propose a new syntax, e.g P:A ;Intro P:B ;Riff P:C ;Coda (where ; is used here to indicate a new separator character, not necessarily a semi-colon) The single letter is used in the formula, and the text following the separator is displayed on the score Hopefully, leaving a space would make it acceptable to existing programs? In that way, for print the parts sequence above the staff at the tune begining, it is need read the tune body to find the text to be printed, because in the header just the identifiers (the formula) can be found. However, that proposal seems be closer to the standard. Best regards. Hudson To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] [ABCp] Parts
Em 25 Oct 2004, [EMAIL PROTECTED] escreveu: My program would reject (ignore) any part specification longer than one letter. Your proposal could lead to ambiguous part specifications, if one name matched part of another name. Remo's proposal avoids the ambiguity by distinguishing the letter case. Is that not sufficient? Remo said (Sat, 23 Oct 2004 03:25:13 -0700): Each part name MUST begin with a upper case letter and may continue ONLY with lowercase letters and numbers P:AB- play part A then B P:OvertureCoda - play part Overture then part Coda P:OVERTURE CODA - play part O then V, then E, ... P:intro - ERROR Also, for printing, Neil Jennings proposal - a letter for parts identification plus an optional string for parts names - should lead to a need of to obtain the parts names in the tune body (i.e. after read the header P:), for then write (print) the parts sequency at the begining of the piece. % header P:ABABC % ... % body % ... P:B ;Riff P:C ;Coda Regards. Hudson _ Quer mais velocidade? Só com o acesso Aditivado iG, a velocidade que você quer na hora que você precisa. Clique aqui: http://www.acessoaditivado.ig.com.br
Re: [abcusers] [ABCp] Parts
Because the P: text appears above the staff, people have mis-used it to add comments which have nothing to do with parts. In the tune header, it can have a formula such as (AB)2(AC)3 In the body, it must be just a single letter HARMONY can play tunes according to the formula, including nested repeats. Neil - Original Message - From: Remo D. [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: 23 October 2004 11:22 Subject: [abcusers] [ABCp] Parts Most of the examples I've examined (thanks again folks!) use a single uppercase letter for denoting each part. P:A in a tune means this is the part 'A' and P:ABACAB at the beginning means, if I understood it correctly, play part A, then B, then C This is what the standards suggest but in one of the Barfly examples, parts are denoted with a more complex syntax: P:Coda for example. I'd like to support it but what should be the exact syntax? My proposal is the following: Each part name MUST begin with a upper case letter and may continue ONLY with lowercase letters and numbers P:AB- play part A then B P:OvertureCoda - play part Overture then part Coda P:OVERTURE CODA - play part O then V, then E, ... P:intro - ERROR Spaces and dots may separate part names. How Barfly behaves? Any other suggestion? R:D 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] [ABCp] Parts
Neil Jennings wrote: Because the P: text appears above the staff, people have mis-used it to add comments which have nothing to do with parts. In the tune header, it can have a formula such as (AB)2(AC)3 In the body, it must be just a single letter HARMONY can play tunes according to the formula, including nested repeats. Neil Does this mean that my proposal is ok for you? If you have (like the standard says): % Header P:(AB)2C ... % Body P:A P:B It would work. But also it would work if you write: %Header P:(Intro Riff)2 Coda ... % Body P:Intro P:Riff ... As a general rule, my parser tries to accomodate as many synonyms as it can. A simple example is with decorations: !f! is equal to +f+ which is equal to +forte+. R.D To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
