Re: [abcusers] voice properties
Arent Storm wrote: >Nonetheless > V:1 name="Soprano" subname="S" > V:2 name="Alto" subname="A" > V:3 name="Tenor" subname="T" clef=tenor > V:4 name="Bass" subname="B" clef=bass >would be more complete and to the point I agree. BarFly currently does not use voice labels at all, and only permits numerical V: fields. While I could do it either way, I prefer the above. Phil Taylor To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] voice properties
- Original Message - From: "John Chambers" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Saturday, July 26, 2003 6:40 PM Subject: Re: [abcusers] voice properties > Arent Storm writes: > | From: "I. Oppenheim" <[EMAIL PROTECTED]> > | > T1 in V:T1 is just an identifier that will make the ABC > | > source code more readable. > | > > | > As you know the name of the voice and other options > | > need to be spelled out only once, so having readable > | > identifiers throughout a big piece of ABC source code > | > is a big plus. > | *NO* its not a plus; it's a minus > | I'm not convinced at all. > | The three different voicing methods are more than enough. > | Stick with ciphering convention please! > > Another repeat topic! The abc2ps clones accept alphanumeric voice > identifiers, but I don't know if anything else does. > > One funny aspect to this is that abc2ps doesn't actually need them, > while probably other abc programs do. In particular, those that > implement the proposed standard will. > > The reason is that, once you get beyond a few voices, it's a really > good idea to be able to label them. You don't want to waste a big > chunk of the left edge of the page for full part names, so the usual > convention is that on all staff systems but the first, you use an > abbreviation. Of course you need to label them (in abc and on paper, not nessecarily the same) my objection is within the use of the V-field. > Now, abc2ps (and clones) has a way of doing this. You can define a > voice as: > > V: 5 name="Bb Clarinet II" sname="Cl.II" thus 5 is the (internal) label, "Bb clarinet" the main text to be displayed with voice number 5, and "Cl.II" the name within a (larger) score before any line. Perfectly allright. > The short name will be used after the first time. But I noticed that > the proposed standard doesn't have the sname term, and there doesn't > appear to be any other way to write this abbreviation. So how could > we do it? it's called subname or snm... (in the proposed standard) but sname is as good/bad as subname > Well, if you don't have sname, you could conceivably have an option > that displays the voice's identifier. So you would write: > > V: Cl_II name="Bb Clarinet II" > > Now, if the program showed the name the first time and the identifier > thereafter, you'd get the conventional scores for orchestra/band > music. And even better: You'd also see the abbreviations in the abc. > This would be a huge help in getting the abc right. And get another level of possible mistakes. you may not spot the difference between Cl_I and Cl_l immediately but any program will and misbehave. > So. If you object to alphanumeric voice identifiers, you should say > how you propose to tell the software to label the parts of a score > after the first system. The full name is NOT acceptable to anyone. agree >A numeric part number is even worse. don't agree > We could include the sname term in the standard. This would work, but > has the minor problem of giving parts meaningless names in the abc. > Or we can insist that alphanumeric voice identifiers be legal, and an > option be provided to display them after the first staff system. This > would be slightly better than the way that abc2ps does it. > > We could allow both, of course. The problem then would be that half > the abc tools would implement only one, and when you got a score from > someone, half the time you'd have to laboriously edit it to follow > the other convention. That's somewhat the situation now, since many > abc tools only implement numeric voice identifiers. as did I > Personally, despite being a long-time abc2ps user, I'd be happy to > discard the sname term and convert my (few) uses of voices to use the > voice's abbreviation as its identifier. But we'd want to make sure > that the conventional abbreviations can be used. "Cl_II" is ok, but > the usual notation would be "Cl.II". It would be nice if we could get > such abbreviations printed in the music. display use and internal use (for whatever reason) should not be mixed up. I would want to write KL2 instead of Cl.II > Also, a nice thing for vocalists would be to allow: > > V:S > V:A > V:T clef=tenor > V:B clef=bass > > You can't get much more intuitive and user-friendly than that. The > current proposed standard does in fact make this legal, and the > abc2ps clones all implement it now. I'd think that this example by > itself is sufficient grounds to want nonnumeric voice labels. V:1 V:2 V:3 clef=tenor V:4 clef=bass isn't that much of a difference (but has far fewer implementation headaches) Nonetheless V:1 name="Soprano" subname="S" V:2 name="Alto" subname="A" V:3 name="Tenor" subname="T" clef=tenor V:4 name="Bass" subname="B" clef=bass would be more complete and to the point Arent To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] voice properties
Arent Storm writes: | From: "I. Oppenheim" <[EMAIL PROTECTED]> | > T1 in V:T1 is just an identifier that will make the ABC | > source code more readable. | > | > As you know the name of the voice and other options | > need to be spelled out only once, so having readable | > identifiers throughout a big piece of ABC source code | > is a big plus. | *NO* its not a plus; it's a minus | I'm not convinced at all. | The three different voicing methods are more than enough. | Stick with ciphering convention please! Another repeat topic! The abc2ps clones accept alphanumeric voice identifiers, but I don't know if anything else does. One funny aspect to this is that abc2ps doesn't actually need them, while probably other abc programs do. In particular, those that implement the proposed standard will. The reason is that, once you get beyond a few voices, it's a really good idea to be able to label them. You don't want to waste a big chunk of the left edge of the page for full part names, so the usual convention is that on all staff systems but the first, you use an abbreviation. Now, abc2ps (and clones) has a way of doing this. You can define a voice as: V: 5 name="Bb Clarinet II" sname="Cl.II" The short name will be used after the first time. But I noticed that the proposed standard doesn't have the sname term, and there doesn't appear to be any other way to write this abbreviation. So how could we do it? Well, if you don't have sname, you could conceivably have an option that displays the voice's identifier. So you would write: V: Cl_II name="Bb Clarinet II" Now, if the program showed the name the first time and the identifier thereafter, you'd get the conventional scores for orchestra/band music. And even better: You'd also see the abbreviations in the abc. This would be a huge help in getting the abc right. So. If you object to alphanumeric voice identifiers, you should say how you propose to tell the software to label the parts of a score after the first system. The full name is NOT acceptable to anyone. A numeric part number is even worse. We could include the sname term in the standard. This would work, but has the minor problem of giving parts meaningless names in the abc. Or we can insist that alphanumeric voice identifiers be legal, and an option be provided to display them after the first staff system. This would be slightly better than the way that abc2ps does it. We could allow both, of course. The problem then would be that half the abc tools would implement only one, and when you got a score from someone, half the time you'd have to laboriously edit it to follow the other convention. That's somewhat the situation now, since many abc tools only implement numeric voice identifiers. Personally, despite being a long-time abc2ps user, I'd be happy to discard the sname term and convert my (few) uses of voices to use the voice's abbreviation as its identifier. But we'd want to make sure that the conventional abbreviations can be used. "Cl_II" is ok, but the usual notation would be "Cl.II". It would be nice if we could get such abbreviations printed in the music. Also, a nice thing for vocalists would be to allow: V:S V:A V:T clef=tenor V:B clef=bass You can't get much more intuitive and user-friendly than that. The current proposed standard does in fact make this legal, and the abc2ps clones all implement it now. I'd think that this example by itself is sufficient grounds to want nonnumeric voice labels. To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] voice properties
From: "I. Oppenheim" <[EMAIL PROTECTED]> To: "ABCusers" <[EMAIL PROTECTED]> Sent: Friday, July 25, 2003 9:12 PM Subject: Re: [abcusers] voice properties > On Fri, 25 Jul 2003, Arent Storm wrote: > > 1) where does T1 come from > T1 in V:T1 is just an identifier that will make the ABC > source code more readable. > > As you know the name of the voice and other options > need to be spelled out only once, so having readable > identifiers throughout a big piece of ABC source code > is a big plus. *NO* its not a plus; it's a minus I'm not convinced at all. The three different voicing methods are more than enough. Stick with ciphering convention please! > > 2) I expect all options of the form: option=value > > so up/down should be stem=[up|down] > Agreed. > > > draw=[merge|hide|cuesize|] to accomodate > > hidden voices, cuesize > These things should be done with %% directives. why set merge at V: lines and other related things in %% be as consequent as possible. > > 3) the abbreviations do not contribute much > Well, ABC users are lazy :-) and incomprehenseable > > 4) program v n is unclear to me; > > program=# channel=# bank=# would be much more readable and expandable) > Will come back on this later. > > >transpose=-2 (to note that clarinet is not playing the same as a flute) > > defaults to 0 > Will add. > > >stafflines=1 (accomodate gregorian chant and percussion) defaults to 5 > Will come back on this later. Most important thing is to keep the syntax clean & expandable without compromising existing software. Arent To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] voice properties
On Fri, 25 Jul 2003, Arent Storm wrote: > 1) where does T1 come from T1 in V:T1 is just an identifier that will make the ABC source code more readable. As you know the name of the voice and other options need to be spelled out only once, so having readable identifiers throughout a big piece of ABC source code is a big plus. > 2) I expect all options of the form: option=value > so up/down should be stem=[up|down] Agreed. > draw=[merge|hide|cuesize|] to accomodate > hidden voices, cuesize These things should be done with %% directives. > 3) the abbreviations do not contribute much Well, ABC users are lazy :-) > 4) program v n is unclear to me; > program=# channel=# bank=# would be much more readable and expandable) Will come back on this later. >transpose=-2 (to note that clarinet is not playing the same as a flute) > defaults to 0 Will add. >stafflines=1 (accomodate gregorian chant and percussion) defaults to 5 Will come back on this later. Groeten, Irwin Oppenheim [EMAIL PROTECTED] ~~~* Chazzanut Online: http://www.joods.nl/~chazzanut/ To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
