Re: [abcusers] ties and accidentals
On Wed 06 Feb 2002 at 12:20PM -0500, [EMAIL PROTECTED] wrote: On Wed, 6 Feb 2002, James Allwright wrote: It would also be nice to find a written standard to support the interpreation, since the only definition I can find says nothing about ties and so implies that the accidental is necessary. I just took a look at the draft standard, and it doesn't appear to say anything about accidentals remaining in effect until the end of the bar, either. Maybe I'm not looking in the right place. I'm talking about a standard for interpreting staff notation, not abc. As far as I am aware, no such standard exists, so the best you can do is look in textbooks on music and see what the authors of those have to say. James Allwright To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] ties and accidentals
--- Anselm Lingnau [EMAIL PROTECTED] wrote: I think we all agree that »^f-|f«, by virtue of »-« signifying a tie as opposed to a slur, is essentially an »^f2« shifted across the bar line. bTherefore in ABC there is no ambiguity as to what the notation *means* in musical terms (and thus what a MIDI player should do). Exactly my opinion. Whether this combination actually appears in a traditional printed score with no accidental on the second »f«, with a cautionary accidental in front of the note, with the accidental in parentheses, or (say) a small »#« above the staff at that point, is an issue of taste and/or convenience on the part of a notation program. A notation program might (or ought to) offer a way for users to be able to specify what sort of behaviour they prefer for such cases, but that preference has no bearing on the ABC notation whatsoever. Agree completely! Erik __ Do You Yahoo!? Everything you'll ever need on one web page from News and Sport to Email and Music Charts http://uk.my.yahoo.com To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
[abcusers] ties and accidentals
I can't understand why I've read so many emails on this topic. ABC quite clearly differentiates between slurs and ties (which is more than stave notation does), but some player somewhere interprets ^F-|F as (^F|=F). So? Mend the player. This is the abcusers group, not the software developers' group. I'm just waiting for someone to write a program to play ABC to my sound card, so I can rename it as playQabc.exe (I'm using ABC2Win). That would be a great improvement. The last system I had delivered arrived with the PC speaker unconnected, and I won't be surprised to see the next arrive without one at all. Flos To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] ties and accidentals
On Wed, 6 Feb 2002, Phil Headford wrote: I can't understand why I've read so many emails on this topic. ABC quite clearly differentiates between slurs and ties (which is more than stave notation does), but some player somewhere interprets ^F-|F as (^F|=F). So? The whole thing started with me asking for support because I found abc2midi behaving like this. I think I found that support, so now I ask officially: James Allwright, will you please reconsider changing the behavior of abc2midi so that it interprets ^F-|F as ^F-|^F and not ^F|=F, since it's widely agreed here on the list that that would be the prober way of understanding this??? Regards -- Atte To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
RE: [abcusers] ties and accidentals
In reply to the message from [EMAIL PROTECTED] So, we've got frequency and duration covered. Now all that's missing is a way to express amplitude and timbre, but since the ABC standard never really supported dynamics or instrument definitions, I don't see that we need to go that far. There you go. A stand-alone, precise notation system. Happy now? First of all, you don't have to taunt me. I think I'd get your point anyway. Second, I don't agree, and it seems to me as you completely misunderstood my opinion. No language can ever claim to be complete. My point was *not* that abc should be something more real or more complete than staff notation. My point was that we should have a language that is precise in it's *syntax*, that is, the way in which music is notated and the way in which the language should be interpreted. In other words: what is allowed and what is not. Ignoring for the present how much existing ABC might be broken by this, suppose it is decided that you have to write ^f-|^f. The notation software will omit the second sharp by default, in order to display the staff notation correctly. Now suppose you *want* the second sharp to be displayed, as a cautionary accidental. How could this be achieved? Again: my very point was that abc is NOT a pseudo-staff-notation (you may disagree with that, as some do of course, and that is OK for me - but just write that in that case!). If you have a piece of abc that is clear and unambigous, translate it into staff notation, and doubts appear about how it should be interpreted; the error is not in abc itself, it lies in the translation program, or worse, in staff notation itself (not in this case though)! In other words: don't blame the abc source for not looking in a specific way when converted into staff notation. Blame the program! And if you *do* expect the staff to look in a certain way: don't use abc - use a music typesetting program or whatever. Erik __ Do You Yahoo!? Everything you'll ever need on one web page from News and Sport to Email and Music Charts http://uk.my.yahoo.com To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] ties and accidentals
Muse uses sound card to play ABC. Has for ages. I'd be very surprised indeed if it's the only one. I have always presumed that all of those player programs use the sound card. Do you mean plays as wave sound rather than MIDI? Laurie - Original Message - From: Phil Headford [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, February 06, 2002 7:08 AM Subject: [abcusers] ties and accidentals snip I'm just waiting for someone to write a program to play ABC to my sound card snip To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] ties and accidentals
On Wed 06 Feb 2002 at 12:26PM +0100, Atte Andre Jensen wrote: James Allwright, will you please reconsider changing the behavior of abc2midi so that it interprets ^F-|F as ^F-|^F and not ^F|=F, since it's widely agreed here on the list that that would be the prober way of understanding this??? In view of this popularly of this interpretation, I'm willing to accept a patch to implement this behaviour. It would also be nice to find a written standard to support the interpreation, since the only definition I can find says nothing about ties and so implies that the accidental is necessary. Please observe that abc2midi is open source so that you can fix things yourself if need be. I am unlikely to get round to trying to change this myself for a while, though I have now documented it. James Allwright To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] ties and accidentals
On Wed, 6 Feb 2002, James Allwright wrote: It would also be nice to find a written standard to support the interpreation, since the only definition I can find says nothing about ties and so implies that the accidental is necessary. I just took a look at the draft standard, and it doesn't appear to say anything about accidentals remaining in effect until the end of the bar, either. Maybe I'm not looking in the right place. John To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
RE: [abcusers] ties and accidentals
On Wed, 6 Feb 2002, [iso-8859-1] Erik Ronström wrote: I think I'd get your point anyway. I don't think you do get my point. It seems self-evident to me that ABC is pseudo-staff notation. You have made it clear *that* you disagree, but not *why*. Where else do you think ABC got the concepts of whole notes, beaming, barlines, etc., if not from staff notation? It's hard for me to imagine how you define pseudo-staff notation, if ABC doesn't qualify. My point was that we should have a language that is precise in it's *syntax*, that is, the way in which music is notated and the way in which the language should be interpreted. In other words: what is allowed and what is not. I agree, and there is *nothing* imprecise about ^f-|f if you simply amend the standard to codify the rule -- a rule that most people seem to be following anyway. I still see no advantage to using ^f-|^f. In other words: don't blame the abc source for not looking in a specific way when converted into staff notation. Blame the program! And if you *do* expect the staff to look in a certain way: don't use abc - use a music typesetting program or whatever. I disagree. The ABC standard is full of indications that it has historically been intended primarily as a source for *generating* staff notation. See the section on beaming... Beaming is meaningless outside of staff notation. There are also many instances of language like character x is used to generate symbol y. There's even an ASCII *drawing* of a five-line staff, with ledger lines, in the standard itself! The basic philosophy seems to be draw what I tell you to draw. So, I would counter your suggestion by saying that if you want to write stand-alone notation, irrespective of how it would appear on the staff, maybe *you* are the one who shouldn't be using abc. (Whether or not abc *should* be stand-alone is another question entirely. My point is simply that is is not stand-alone *now*. Not by a long shot.) John To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
RE: [abcusers] ties and accidentals
At 12:52 PM 02-06-2002 -0500, [EMAIL PROTECTED] you wrote: On Wed, 6 Feb 2002, [iso-8859-1] Erik Ronström wrote: I think I'd get your point anyway. I don't think you do get my point. It seems self-evident to me that ABC is pseudo-staff notation. You have made it clear *that* you disagree, but not *why*. Where else do you think ABC got the concepts of whole notes, beaming, barlines, etc., if not from staff notation? It's hard for me to imagine how you define pseudo-staff notation, if ABC doesn't qualify. My understanding of staff notation indicates that a lot of the things you are talking about -- whole notes, beaming, bar lines, etc -- have musical significants outside of the notation. Bar lines and beaming indicate the rhythm of the music, which helps performers in performance (different parts of the rhythm may have different stress or emphasis when played). A human musician may very well play | abc def | differently than | ab cd ef |, even though it's the same notes, played for the same duration, etc. My point was that we should have a language that is precise in it's *syntax*, that is, the way in which music is notated and the way in which the language should be interpreted. In other words: what is allowed and what is not. I agree, and there is *nothing* imprecise about ^f-|f if you simply amend the standard to codify the rule -- a rule that most people seem to be following anyway. I still see no advantage to using ^f-|^f. So you would agree with the following text (subject to minor amendment, since I'm writing this off the cuff): Syntax: - ties A tie may be placed between two or more notes of the same pitch and indicates that the two notes should be played without a break, as if it was one note of duration equal to the sum of the durations of the two notes. As a convenience, accidentals on the first note are optional on successive notes. White space, bar lines, and repeat symbols may appear between the tied notes. Ties are useful for preserving the visible meter or rhythm of the music when notes extend over beat or measure boundaries. Examples: f-f % plays as if it were f2 f-|f % plays as if it were f2 across a measure boundary f4-|f4-|f4-|f4-|f4- f4-|f4-|f4-|f4-|f4 % plays as if it were f20 across two lines ^f4-|^f4 % plays as if it were ^f8 across a measure boundary ^f4-|f4 % plays as if it were ^f8 across a measure boundary C-|:CEGc-|cGEC-:|CE,G,C, % plays as C2EGc2GEC2EGc2GEC2E,G,C, c-^B-B-^^^A% plays as c4 I disagree. The ABC standard is full of indications that it has historically been intended primarily as a source for *generating* staff notation. I see nothing wrong with a standard for a notation suggesting how parts of that notation should be translated to or from another notation. See the section on beaming... Beaming is meaningless outside of staff notation. I disagree. Beaming is used in staff notation to indicate musical rhythm. In the face of M:, beaming may be redundant, but it is a useful redundancy to performers. The description of the beam-equivalent notation in ABC may refer to beaming, but the concept of rhythmic grouping of notes is not staff notation-specific. There are also many instances of language like character x is used to generate symbol y. There's even an ASCII *drawing* of a five-line staff, with ledger lines, in the standard itself! The basic philosophy seems to be draw what I tell you to draw. Perhaps the basic philosophy should be To get an effect like X in staff-notation, do Y in ABC. The only ASCII drawing of a five-line staff I remember is used to show how ABC notes correspond to staff-notation notes. A lot of people want to create ABC files based on music they have available to them in staff notation. It is reasonable for them to want to ask how to do something in ABC which is possible in staff notation -- such as extending a note slightly at the end of the music or a piece. Such a query may be expressed as How do I put a fermata over a note, or How do I put in guitar tablature, or How do I write figured bass rather than How do I get X effect. I think it is reasonable for the standard to be written to make it easier for people to find the information they are looking for. So, I would counter your suggestion by saying that if you want to write stand-alone notation, irrespective of how it would appear on the staff, maybe *you* are the one who shouldn't be using abc. This seems a little extreme. (Whether or not abc *should* be stand-alone is another question entirely. My point is simply that is is not stand-alone *now*. Not by a long shot.) ABC clearly shows staff notation in its heritage, and it is clearly designed to be easy to use by familiar with staff notation. But I do think it is to a large degree stand-alone, with a few non-standalone warts that may be able to be repaired. John To subscribe/unsubscribe,
Re: [abcusers] ties and accidentals
One of those other Johns wrote: | On Wed, 6 Feb 2002, James Allwright wrote: | | It would also be nice to find a written standard to support the | interpreation, since the only definition I can find says nothing about | ties and so implies that the accidental is necessary. | | I just took a look at the draft standard, and it doesn't appear to say | anything about accidentals remaining in effect until the end of the bar, | either. Maybe I'm not looking in the right place. No, for a straightforward reason. The 1.6 standard that it was based on was written by Chris Walshaw, who was mostly working on abc2mtex. This is a pure music formatter, and as such, it has no concern with the pitch of any note. His doc wasn't intended as a standard at all; it was simply a readable description of abc for abcmtex users. As such, there was no need to discuss things that don't appear on paper, such as pitches. Those were questions for the readers of the music. The only reason such things are a concern is that people have also written programs that play music by converting it to various audio formats. For such programs, questions of pitch are a very serious issue. The best way to handle them is to discuss the topic in the way it has always been discussed: How should a musician interpret such notation? The software should obviously do it the same way. And, of course, over the centuries there have been so many different musical styles with so many different rules, that the only really useful answers to such questions all start with Well, it depends ... To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
RE: [abcusers] ties and accidentals
On Wed, 6 Feb 2002, Buddha Buck wrote: So you would agree with the following text [snipped] Yes. See the section on beaming... Beaming is meaningless outside of staff notation. I disagree. Beaming is used in staff notation to indicate musical rhythm. In the face of M:, beaming may be redundant, but it is a useful redundancy to performers. The description of the beam-equivalent notation in ABC may refer to beaming, but the concept of rhythmic grouping of notes is not staff notation-specific. You are confusing the result with the way that it is communicated. That's like saying that the letter S is not alphabet-specific because the *sound* that it makes is not alphabet-specific. Rhythmic grouping of notes is not specific to any notation system, but communicating it with beams is. Furthermore, the ABC standard does not define beams in terms of how they group notes together rhythmically. It defines beams in terms of how the notes will be drawn on the staff. So really, it's less like defining something as the sound that the letter S makes and more like defining it as the letter S itself. So, I would counter your suggestion by saying that if you want to write stand-alone notation, irrespective of how it would appear on the staff, maybe *you* are the one who shouldn't be using abc. This seems a little extreme. Keep in mind that it was in response to: if you *do* expect the staff to look in a certain way: don't use abc - use a music typesetting program or whatever. If what I said was extreme, this was equally so. John To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
RE: [abcusers] ties and accidentals
Hi all, Again, I want to state that we have to separate staff notation (standard notation) and abc. John Walsh writes in his summary: ties and slurs can't always be distinguished in printed staff notation. The usual convention is that if there is an ambiguity between tie and slur, one always assumes it's a tie; in other words, in questions of tie/slur, the default is a tie. There is no ambiguity in abc---the example ^f- | f has a tie, not a slur---so that the second f has to be an f sharp. Which means that playback and midi programs should play ^f, but printing programs don't print the accidental (because they don't need to--the convention takes care of it.) I think this shows the problem quite clearly. The problem is NOT to decide whether the second f is equal to f or f#, the problem appears when we expect abc to be equal to staff notation. If the standard says that ^f- | f means ^f- | ^f (to which I fully agree), well, so be it. If someone says: but when I convert the abc to staff notation, I want the second f to appear as this or that, I say that should be a matter for the interpreter ( = the application), not the abc writer. One example: abc clearly distinguishes between ties and slurs. Thus, (f^ | f) means f# and f, while f^- | f means one note - f#. It is not hard to read, and there is no problem getting a abc player playing this correctly. A problem appears, however, when we want to translate the abc into staff notation: ties and slurs look identical (or at least very similar). This problem appears because there is an ambiguity in *staff notation*, and *not* in abc. My solution to this looks like this: when converting f^- | f to staff notation, let the application be aware of the problem by writing a sharp for both notes. Or at least, make this an option in the application. Why implement ambiguities in abc, making it as messy as staff notation already is? Or, taking a bit further: why should we make abc a pseudo-staff-notation with the same flaws, when we have the possibility to keep it as a stand alone, complete notation with all it's advantages: easy to read, clearly defined and usable both by humans and computers. I will continue this part of the discussion in a new mail with a new, more accurate, subject line. Erik __ Do You Yahoo!? Everything you'll ever need on one web page from News and Sport to Email and Music Charts http://uk.my.yahoo.com To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
RE: [abcusers] ties and accidentals
Thank you! -Original Message- From: John Walsh [SMTP:[EMAIL PROTECTED]] Sent: Saturday, February 02, 2002 22:15 To: [EMAIL PROTECTED] Subject: Re: [abcusers] ties and accidentals This thread keeps going on, but I have the feeling that there has been agreement for some time, and we've just forgotten it. But I've often been wrong on that score before... Here's what I think has been said: ties and slurs can't always be distinguished in printed staff notation. The usual convention is that if there is an ambiguity between tie and slur, one always assumes it's a tie; in other words, in questions of tie/slur, the default is a tie. There is no ambiguity in abc---the example ^f- | f has a tie, not a slur---so that the second f has to be an f sharp. Which means that playback and midi programs should play ^f, but printing programs don't print the accidental (because they don't need to--the convention takes care of it.) It would seem to follow---but I don't remember if there was agreement here---that if one wrote ^f- | ^f that the accidental on the second f is there for emphasis, and a printing program should print it; but it should be equivalent to ^f- | f for any midi or playback program, or for that matter, to a musician reading the tune. Another question was lightly touched on, but not resolved: if we add another f to the examples: ^f-| f f and ^f- | ^f f ...what should be done with the third f? I would think that in the first example, it's an f natural, in the second, it's an f sharp (since the printing program will have explicitly sharped the first f in the measure, so by extension, all later f's will be sharped.) But I'm guessing---we should just follow whatever the actual convention is in printed music for this. John Chambers brought up the question of having software accept abc's tie notation for a slur. It seems relatively harmless to me, as long as it doesn't prevent people from using the tie/slur distinction the way it's meant to be, but it points out the need for clear documentation--it's easy to imagine someone using a tie for a slur and then having no clue as to why some strange accidentals showed up later on in the measure. Cheers, John Walsh 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] ties and accidentals
On Sat, 2 Feb 2002, John Walsh wrote: Another question was lightly touched on, but not resolved: if we add another f to the examples: ^f-| f f and ^f- | ^f f ...what should be done with the third f? I would think that in the first example, it's an f natural, in the second, it's an f sharp (since the printing program will have explicitly sharped the first f in the measure, so by extension, all later f's will be sharped.) But I'm guessing---we should just follow whatever the actual convention is in printed music for this. The convention (according to my old notation text) is that the third f in ^f-| f f would be natural, however, it is advisable to write a courtesy accidental to remove all doubt [Heussenstamm, 1987]. If an f sharp is intended, the third f *must* have a sharp in front of it. In the second example, I see no reason why the second sharp wouldn't carry through the entire measure. John To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] ties and accidentals
One of those other Johns wrote: | On Fri, 1 Feb 2002, John Chambers wrote: | I have no control over what people put on their web sites, so I have a | strong incentive to use Be liberal in what you accept as a major | rule. | | I disagree, both with this rule and with the idea that you have no | influence over how people choose to write their ABC. By your own words, | the reason this problem exists is because of the widespread use of | software that has casually accepted the use of - as a slur without | complaint -- i.e., software that has been too liberal. So in effect, you | have chosen to become part of the problem, rather than the solution! Yes; I can understand this argument. But I'd classify it as a red herring. Why? Well, consider what it would take for the typical user to use my ABC Tune Finder to verify their own tunes. You can't just point it at your file; you need to get your file into its index. So you have to create at least one (and probably a dozen or so) ABC files with titles like T: Test Tune 1 and so on. You put them into a directory in your web site and send me the URL. Some time within the next few weeks, I'll run my search program, and then your files will be in my indexes. After waiting several weeks, you can go to the Tune Finder and type in Test Tune, and it'll find your tunes. You can now edit your file(s), ask for it to be downloaded in PS or MIDI or whatever format, and see whether it works. If it does, you won't see any possible warning messages, because you only get a pointer to the log file if the conversion fails. This is exceedingly clumsy, and I'd be frankly surprised if there's anyone on the Net who does it. I certainly don't, although I have easy access to all its innards. It's far better to simply fetch one or two of the many ABC tools and install them on your own machine. You get a lot more functionality, and much faster response. (Granted, someone knowledgeable about the Web can invoke my conversion programs directly. This was a conscious part of my design. Some people have done this, and I even have a page explaining how to do it. This could be used to validate and convert ABC files. But still, I suspect that nobody is routinely using it this way. You're much better off installing ABC software on your own machine. My CGI scripts are really only useful when invoked from a web page.) | At the very least, I think that using - as a slur should result in a | clear *warning* to the user that the ABC standard discourages this | practice, and it is not guaranteed to work with other ABC software. Then | I suppose you could be as liberal as you want in idiot-proofing your | software without much risk of further exacerbating the problem. Most musicians don't understand the distinction between a tie and a slur. You could argue that there isn't really a distinction. A slur means to play the notes without articulating any but the first. When you do this with two identical notes, they merge into one note, and that's what we call a tie. So a tie is just a special case of a slur, not a different musical thing. The usual staff notation that represents them (nearly) identically is based on this understanding. It's really the ABC representation that's misleading, implying that ties and slurs are different things. It would be better for ABC to officially go along with the usual musical convention, and just say that the tie notation is shorthand for a two-note slur, and for identical notes, causes them to merge into a single long note. This is how ties are implemented in a lot of software already, and it's a very useful way to do it. | I don't want to waste my time responding to users' complaints about my | web site bombing for ABC that works elsewhere. | | I can respect this, but at the same time, I don't feel that it justifies | dumbing down the standard to the lowest common denominator. It's nearly impossible for me to dumb down ABC. If you subscribe to some of the musical mailing lists that use ABC, you'll quickly see what I mean. The quality of much of the posted ABC is abysmally low, and dumb syntax errors are rife. People routinely use English text for information that belongs in the headers, because they can't be bothered to learn about any headers except T, M and K. And they get those wrong with amazing frequency. It would be difficult for me to write software that encourages anything worse. To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] ties and accidentals
John == John Chambers [EMAIL PROTECTED] writes: John It's really the ABC representation that's misleading, implying that John ties and slurs are different things. It would be better for ABC to John officially go along with the usual musical convention, and just say John that the tie notation is shorthand for a two-note slur, and for John identical notes, causes them to merge into a single long note. If this were true, the usual notation for an F# tied across a bar would have a sharp on the second F. And in the music I play, it doesn't. I agree that most musicians are hazy on the distinction, but I think most music printers are aware of it. And musicians are to the extent that they don't play the second F tied. -- Laura (mailto:[EMAIL PROTECTED] , http://www.laymusic.org/ ) (617) 661-8097 fax: (801) 365-6574 233 Broadway, Cambridge, MA 02139 To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] ties and accidentals
On Sat, 2 Feb 2002, John Chambers wrote: Most musicians don't understand the distinction between a tie and a slur. So you may speculate, but I doubt you have any quantifiable evidence to back that up. You could argue that there isn't really a distinction. Here is an example of the distinction. These two passages should be played differently: (C D E- | E F G) (C D E | E F G) If there were no distinction, we would never need to write ties within slurs. From a notational perspective, another example of the distinction is the fact that a passage of slurred notes requires only one slur. But when a series of notes are tied, each adjacent pair must be connected with their own tie: E2- | E2- | E2 ===correct (E2 | E2 | E2) ===incorrect Yet another example is the fact that slurring two different chords together requires only one slur. But when you tie a chord to a chord, each note of the chord requires a tie: [C2-E2-G2-] | [CEG] ===correct ([C2E2G2] | [CEG]) ===incorrect Now, if there's no distinction, why do ties and slurs obey different rules? A slur means to play the notes without articulating any but the first. Please tell me how to play a note on the piano, marimba, harp, snare drum, etc. without articulating it. Apparently, I've been playing far too many notes all these years :-) What a slur really means is that the passage should be played legato. This does not preclude any and all articulation (see the first example I gave). On the contrary, it is actually quite common to find articulation marks *within* slurs. It's really the ABC representation that's misleading, implying that ties and slurs are different things. It would be better for ABC to officially go along with the usual musical convention, and just say that the tie notation is shorthand for a two-note slur, and for identical notes, causes them to merge into a single long note. According to whom, exactly, is this the usual musical convention? This is how ties are implemented in a lot of software already, and it's a very useful way to do it. It's also wrong. Implementing ties and slurs this way makes it impossible for the computer to distinguish between the first two examples I gave. The computer would play them both identically. And how would it handle something like this, I wonder: L:1/8 M:C K:Db z2 (.A z .B z .d z | .e z .f z .e z .B) z | d2 z2 z4 | It's nearly impossible for me to dumb down ABC. If you subscribe to some of the musical mailing lists that use ABC, you'll quickly see what I mean. The quality of much of the posted ABC is abysmally low, and dumb syntax errors are rife. What I meant was that the standard should not be changed so that dumb syntax errors become correct. And I would consider notating an F sharp slurred to an F natural with ^F-|F to be just such an error. The day the standard endorses garbage like this is the day I stop using ABC. John To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] ties and accidentals
[EMAIL PROTECTED] wrote: On Sat, 2 Feb 2002, John Chambers wrote: Most musicians don't understand the distinction between a tie and a slur. So you may speculate, but I doubt you have any quantifiable evidence to back that up. So, to start quantifying it, I *do* know the difference. You could argue that there isn't really a distinction. ...snip... What a slur really means is that the passage should be played legato. This does not preclude any and all articulation (see the first example I gave). On the contrary, it is actually quite common to find articulation marks *within* slurs. It's really the ABC representation that's misleading, implying that ties and slurs are different things. It would be better for ABC to officially go along with the usual musical convention, and just say that the tie notation is shorthand for a two-note slur, and for identical notes, causes them to merge into a single long note. According to whom, exactly, is this the usual musical convention? This is how ties are implemented in a lot of software already, and it's a very useful way to do it. It's also wrong. Implementing ties and slurs this way makes it impossible for the computer to distinguish between the first two examples I gave. The computer would play them both identically. And how would it handle something like this, I wonder: L:1/8 M:C K:Db z2 (.A z .B z .d z | .e z .f z .e z .B) z | d2 z2 z4 | It's nearly impossible for me to dumb down ABC. If you subscribe to some of the musical mailing lists that use ABC, you'll quickly see what I mean. The quality of much of the posted ABC is abysmally low, and dumb syntax errors are rife. What I meant was that the standard should not be changed so that dumb syntax errors become correct. And I would consider notating an F sharp slurred to an F natural with ^F-|F to be just such an error. The day the standard endorses garbage like this is the day I stop using ABC. John I'll have to say I agree with John. His explanation of these things certainly agrees with what I have been taught and learned over the last 40+ years here in the States. I would have to say that, for me, this is the usual musical convention. So, as a user of ABC, and not a developer, I would say the answer to this is simple - ABC ain't broke - don't fix it! -- = = No matter how I feel, God is worthy of my praise. = = May the peace of the Father, and the love of the Son, and the power of the Holy Spirit encircle and enfold you, and keep you this day. Rick My opinions are my own, and, unfortunately, not those of the rest of society. To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] ties and accidentals
This thread keeps going on, but I have the feeling that there has been agreement for some time, and we've just forgotten it. But I've often been wrong on that score before... Here's what I think has been said: ties and slurs can't always be distinguished in printed staff notation. The usual convention is that if there is an ambiguity between tie and slur, one always assumes it's a tie; in other words, in questions of tie/slur, the default is a tie. There is no ambiguity in abc---the example ^f- | f has a tie, not a slur---so that the second f has to be an f sharp. Which means that playback and midi programs should play ^f, but printing programs don't print the accidental (because they don't need to--the convention takes care of it.) It would seem to follow---but I don't remember if there was agreement here---that if one wrote ^f- | ^f that the accidental on the second f is there for emphasis, and a printing program should print it; but it should be equivalent to ^f- | f for any midi or playback program, or for that matter, to a musician reading the tune. Another question was lightly touched on, but not resolved: if we add another f to the examples: ^f-| f f and ^f- | ^f f ...what should be done with the third f? I would think that in the first example, it's an f natural, in the second, it's an f sharp (since the printing program will have explicitly sharped the first f in the measure, so by extension, all later f's will be sharped.) But I'm guessing---we should just follow whatever the actual convention is in printed music for this. John Chambers brought up the question of having software accept abc's tie notation for a slur. It seems relatively harmless to me, as long as it doesn't prevent people from using the tie/slur distinction the way it's meant to be, but it points out the need for clear documentation--it's easy to imagine someone using a tie for a slur and then having no clue as to why some strange accidentals showed up later on in the measure. Cheers, John Walsh To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] ties and accidentals
Toni writes: | By the way. As you mention this. I think of a german dance form Zwiefacher. | There you have patterns like |3/2|3/2|2/2|2/2| in the A-part and another | pattern in the B-part (somtimes hard to dance). | Do we have a notation like M: A:2(3/2)2(2/2) B:3(2/2)1(3/2) | for this, or was it discussed. | (sorry it's some months ago since I read the standard in detaill ;-) ) Yeah; hereabouts there's a gang that gets together at local dance festivals and plays Zwiefacher sessions. It's a lot of fun. The printed music uses several different conventions. One is to just write in all the meter changes. You see music in which half or more of the measures have a big 3/4 or 2/4 or 4/4 at the start. This can be done in abc with |[M:3/4] and so on. This works, but a lot of the practitioners think this is clumsy and cluttered. So you also see music that starts of with both a 2/4 and a 3/4 time signature as a warning of what's to come, and measures have however many beats they have. You just count the 1/4 notes as they go by and hope for the best. Chris Walshaw didn't anticipate this when he designed the original abc notation, and there's no standard way to do it. The obvious thing is to have a M: 2/4 3/4 time signature, but tests show that few (if any) existing abc programs do the Right Thing with this. I pointed out some time back that abc2ps (and probably other programs) accepts M:23/44 and draws the right thing on the page. When I discovered this, I was quite naturally horrified. From the viewpoint of a programmer trying to write code that handles abc, this is incredibly grotesque. But it works (for some sick definition of the term), and so of course a few of us have added to the perversity of it all by using it. We have a evil grins on our faces as we do it and watch it work just like we want Some zwiefacher music uses no time signature at all. This is the simplest and most elegant solution, of course, and a lot of ABC programs now understand M:none. We just need to get this into the ABC standard. It was added for the benefit of people writing out slow airs and Early Music and such, and it works for Bavarian tunes, too. | Anyhow, I think ABC should be kept simple. | Yes | And any problem that it shares with staff notation is a | pseudo-problem that can be easily | ignored by most of its users. | Yes | High precision should be left to the more sophisticated notations | that others are developing. (And we | should be encouraging them to include ABC as an input/output format, | despite its loss of information.) | Again, ABC itself need not be precise but the standard should be precise | about ABC This could be interpreted as saying that we should try to be precise about ABC's syntax, but not necessarily about the musical interpretation. There is a lot of precedence for this in staff notation. After all, you do see things like ^F-|F in ordinary music, and few musicians have any problem with it. ABC's syntax is fairly clear here: The ^ is used as a sharp, - is used as a tie, and | is used as a bar line. The letters A-G and a-g represent notes. So ^F-|F is legal ABC. How you play it is an unrelated question, and while it's interesting, it's not as important. We could consider a related question: Should ABC specify equal (or well-tempered) intonation? If so, then it becomes illegal to use ABC to represent, say, highland bagpipe music or traditional Swedish or Norwegian fiddle music, all of which use scales with intermediate 7ths. I don't think we want to be this precise. These musical styles are represented quite well on paper without resorting to quarter-tone notation. Trying to specify such details of interpretation is just silly. And it's pointless, since musicians will violate such rules no matter what you say. There's a lot of highland pipe music in ABC, and decreeing intonation standards won't make those pipers go away. OTOH, we could encourage people to do a lot more with software that knows how to do interpretation. There are already a few ABC apps that understand R:hornpipe and can modify even-note notation into something more like how hornpipes are played. But there's a serious potential problem here. I could write a program that took ABC written with even notes and output ABC that has lots of uneven notes to represent various styles. The result would be difficult to read, but could be quite useful as a teaching aid. But I'd be opening myself to an obvious criticism. There are more than one kind of hornpipe. Is it a Donegal hornpipe? Dingle? Arran? Highland? Jutland? ... (For that matter, if I say Donegal, is it East or West Donegal? ;-) In the case of trad Scandinavian music, there are a lot of ways that one can play a polska, and they're all represented the same on paper. To decree one of these the only correct interpretation would be
Re: [abcusers] ties and accidentals
Another John wrote: | In abc, there is even less ambiguity, because ties and slurs have distinct | syntaxes. ^F-|=F is utter nonsense (according to the draft standard), and | should be written as (^F|=F) instead. And if ^F-|=F is nonsense, then it | is equally nonsensical for abc software to interpret ^F-|F that way. We do have a practical problem here. It seems that most ABC software casually accepts ties between unequal notes and and draws the obvious slur between them. I haven't used many of the players, but I'd guess that many of them do the same, and play the second note with no attack. As a result, there's a lot of ABC around that uses '-' as a way of saving one keystroke when you want to slur two notes. This may be a violation of the current standard, but since a lot of software accepts it (and most musicians can't tell the difference), it has been used a lot. This was something that I noticed some time back while doing some experimenting with my Tune Finder. Since I added the ability to return tunes in PS, GIF, MIDI and other formats, I've also seen some of the problems caused by variant ABC. This was actually what encouraged me origially to start my own abc2ps clone. Rather than contend with a slowly growing flood of complaints that my code did something crazy with a particular tune, I thought that I should start working on making it accept all the common ABC that's lying about on the Net. This makes it more useful as well as eliminating complaints. I have no control over what people put on their web sites, so I have a strong incentive to use Be liberal in what you accept as a major rule. This particular thing never caused problems, because abc2ps has always been casual about the tie/slur distinction, as are most musicians. But I have noted how common this misuse of ties actually is. If we decree that this is illegal and no longer allowed, a lot of people will be complaining about software that can't handle tunes that used to work just fine. I, for one, will react to such a clause in any future standard by casually ignoring it. I don't want to waste my time responding to users' complaints about my web site bombing for ABC that works elsewhere. To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] ties and accidentals
Toni said ...So in the F^-|F case we just have to decide if it means F^-|F= or F^-|F^ or if it is free interpretation. The first is horrible because it means that - can now be a slur. No!! The last is not workable. What on earth would a player program do? Guess? No!! So if it means anything at all it *has* to mean F^-|F^ but the other possibility is that it is bad syntax and soesn't mean anything other than would any software reading this please generate an error message that explains the problem. Laurie To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] ties and accidentals
I haven't bothered the list for a while largely because I got fed up with banging my head against a brick wall but John Chambers' contribution has stirred me from my slumber - All this is fun and interesting, but I think we have more important things to worry about than how someone might misinterpret ^F-|F. This is the sort of discussion that, in the past, has eventually led to things petering out, and nothing at all being done with the standard. Then developers (like me ;-) have eventually just implemented whatever ideas we think are useful, leading to extensions in one or two programs that no other programs can handle. Discussions like this just mean that ABC will continue to diverge while we discuss things that aren't very important. That pretty well sums up what I've been trying to say all this time. Perhaps if I'd chosen Jim Vint's use of ! instead of the inclusion of mode information in the K: command, as an example of the problems caused by independent innovation, I might be hero of the hour instead of villain of the piece. Who knows. You can argue about ^F-|F till the cows come home. Jack Campin's proposal for the Q: command seemed to reach some sort of satisfactory conclusion and then vanished. John Chambers has proposed all sorts of interesting ideas. Until you have some sort of mechanism for agreeing and implementing a standard, all such discussion is futile. It will need a willingness between developers to compromise and achieve a concessus. I wish. Bryan Creer To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] ties and accidentals
On Fri, 1 Feb 2002, John Chambers wrote: I have no control over what people put on their web sites, so I have a strong incentive to use Be liberal in what you accept as a major rule. I disagree, both with this rule and with the idea that you have no influence over how people choose to write their ABC. By your own words, the reason this problem exists is because of the widespread use of software that has casually accepted the use of - as a slur without complaint -- i.e., software that has been too liberal. So in effect, you have chosen to become part of the problem, rather than the solution! While it may be the case that you wrote your software intending for it to be a solution for non-standard ABC, it is quite possible now that some people write non-standard ABC precisely because *your* software enabled them to do so without ever learning the correct syntax. At the very least, I think that using - as a slur should result in a clear *warning* to the user that the ABC standard discourages this practice, and it is not guaranteed to work with other ABC software. Then I suppose you could be as liberal as you want in idiot-proofing your software without much risk of further exacerbating the problem. I don't want to waste my time responding to users' complaints about my web site bombing for ABC that works elsewhere. I can respect this, but at the same time, I don't feel that it justifies dumbing down the standard to the lowest common denominator. Interpreting ^F-|F as two F sharps makes the most sense. It is consistent with the standard's definition of a tie; it follows ABC's trend of borrowing from the traditional rules for notating accidentals; and it ensures that it will be possible, when necessary, to force the second sharp to be displayed. Interpreting the second F as a natural gives no appreciable benefit that I can see (besides which, it is poor notation anyway, since a natural sign should be used even in the absence of a slur or tie, as a courtesy to the performer). John To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] ties and accidentals
I think we are facing serveral different problems here. IMHO we have to distinguish between abc and staff notation. ABC is not a pseudo-staff-notation, nor a pseudo-MIDI-format: it is a standalone music notation. The problem with ties and accidentals is easily solved; it's just to make a decision in either direction. Let's say we hereby decide that | CDE^F- | F is equal to | CDE^F- | ^F This has nothing to do with how we translate this into staff notation. Since there are obviously so many different standards in staff notation, the way ABC should be translated to staff notation should be solved by options in the translation program. My point is that every ^ char doesn't have to get a corresponding # sign, in the same way as keys in ABC are replaced with clefs and accidentals. If you use ABC just as a way to save staff notation, and expect translations of ABC into staff notation to look in a specific way - why do you use ABC at all? The important thing is that there is no doubt about how an ABC tune shall be read or interpreted. How an ABC tune is translated to staff notation, however, will always be subject to difficulties, as there are so many variants of staff notation. Erik __ Do You Yahoo!? Everything you'll ever need on one web page from News and Sport to Email and Music Charts http://uk.my.yahoo.com To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: Re: [abcusers] ties and accidentals
At 08:30 AM 01-31-2002 -0500, [EMAIL PROTECTED] you wrote: Hi, I have been following this discussion with interest. Maybe that shows my level of boredom, but. ;-) If you use ABC just as a way to save staff notation, and expect translations of ABC into staff notation to look in a specific way - why do you use ABC at all? Well, let's see - why do I use ABC to save staf notation? It's simple - From the format of your message, I expected your reply to describe why you expect translations of ABC into staff notation to look in a specific way. But you don't. You give lots of reasons to use ABC that have nothing to do with now the staff notation looks. Only one of them deals with staff notation: 7. I can get perfectly acceptable, useable staff notation using ABC for the tunes (and songs) that I have collected or written out, not to mention that, with abc2ps, there are number more things one can do than simple music notation. And this does not require that the ABC to staff translation have any particular appearance -- or at least, I don't think so, anyway. To me, what is important about an ABC-to-staff translation is that it accurately represents the music so notated. If I take a piece of sheet music and transcribe it into ABC, then run an abc2staff translator, I do not expect the two sheets of music to look identical, especially if the original sheet music used something currently nonstandard, like figured bass. But I do expect that a competent musician should play the two sheets of music identically. The important thing is that there is no doubt about how an ABC tune shall be read or interpreted. I don't know about that. It seems there have been a number of comments in this discussion that show the opposite. Just as with standard music notation, if one is reading the ABC, if you don't specify the sharpness, naturalness or flatness of the second F in your example, is that F in the second bar supposed to be an F-natural or F-sharp? The standard should be unambiguous about such things. That it is not is a place where the standard is failing, and needs be corrected. On this issue, I vote for explictness - not that programs should all do it this way, but if I have to assume what is meant because either I or the transcriber am/is not familiar with standard music notation standards (or at least the same standard of music notation), I would rather the transcriber be explicit than not. The key isn't is the reader familiar with staff music notation standards the key is is the reader familiar with ABC standards. If ABC says, in one form or another, that given ^F-|FabF|, the intermensural F is sharped and played for twice as long as the second, natural, F, then so be it. If it says it is illegal, and to get that effect, one needs to write ^F-|^Fab=F then so be it. Or anything else in between. Right now, the argument is that the standard does NOT so say, and what ^F-|FabF| means is not clear in ABC. So, for what it's worth, that's my two cents' worth ;-) Isn't it odd that people value their opinions at two cents, yet the going rate for thoughts is just a penny? To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: Re: Re: [abcusers] ties and accidentals
At 10:37 AM 01-31-2002 -0500, [EMAIL PROTECTED] you wrote: snip = Excuuse me! I'm sorry, I didn't mean to come off sounding like an ass, but I can see how I might have. To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: Re: [abcusers] ties and accidentals
On Thu, 31 Jan 2002 [EMAIL PROTECTED] wrote: Just as with standard music notation, if one is reading the ABC, if you don't specify the sharpness, naturalness or flatness of the second F in your example, is that F in the second bar supposed to be an F-natural or F-sharp? In standard notation, there is no ambiguity. The second F is assumed to be sharp, as a rule. I can't imagine anyone but a complete novice playing it otherwise. I am aware of only two situations where it is recommended in standard notation to draw the second sharp. The first is when the tie continues from the end of one line to the beginning of the next. The other is when the second F sharp occurs simultaneously with an F natural in another octave. In both cases, the additional sharp is merely for clarification. Its absence would not indicate a natural (though it would be poor notation). As has been mentioned before, if you want to slur an F sharp to an F natural, whether you cross a barline or not, the natural should be made explicit. In abc, there is even less ambiguity, because ties and slurs have distinct syntaxes. ^F-|=F is utter nonsense (according to the draft standard), and should be written as (^F|=F) instead. And if ^F-|=F is nonsense, then it is equally nonsensical for abc software to interpret ^F-|F that way. If we are going to start requiring that abc notation make the second sharp in this example explicit, then we should require that *every* accidental be made explicit, for the sake of consistency. But this seems silly to me. abc was clearly designed to mimic standard notation to a large extent, so it already follows many of the same rules (such as accidentals lasting to the next barline). To follow some rules and ignore others will only lead to confusion. Another problem is that if we required this example always to be written as ^F-|^F, typesetting software would by default have to omit the second sharp in order to conform to conventional notation. But you run into a problem if you want to force the second sharp to be displayed. ^F-|^F won't do it. John To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] ties and accidentals
Laura writes: | John == John Chambers [EMAIL PROTECTED] writes: | | John ABC's niche that led to its success is that it's a | John relatively simple, basic, plain-text notation that is | John compact and mailable. It doesn't require a sophisticated | John UI; it can be typed (and read) by mere humans. | | I fail to see that ABC would be less compact or mailable if we were to | define the meaning in terms of pitch of ^f-|f. Heh, heh. Should I feed the troll? ;-) That really wasn't what spurred by the ^f-|f top9ic; it was in response to the suggestion that we absolutely need abc to be precisely defined in all cases or else it's useless. It's easy to see why people might like precision and unambiguity, but that isn't likely with something as simple and compact as abc. And the claim that we even need these things is disproved by the huge success of standard (;-) staff notation. (Also, from my background as a math student I might also observe that Kurt Goedel proved that we can't even reach total precision without ambiguity. But that's another topic altogether.) To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] ties and accidentals
John, you need to loosen your Goedel... By the way, Skink handles the alternate bar stuff you posted, but I have no idea what it should look like. What would you have expected? wil John Chambers wrote: Laura writes: | John == John Chambers [EMAIL PROTECTED] writes: | | John ABC's niche that led to its success is that it's a | John relatively simple, basic, plain-text notation that is | John compact and mailable. It doesn't require a sophisticated | John UI; it can be typed (and read) by mere humans. | | I fail to see that ABC would be less compact or mailable if we were to | define the meaning in terms of pitch of ^f-|f. Heh, heh. Should I feed the troll? ;-) That really wasn't what spurred by the ^f-|f top9ic; it was in response to the suggestion that we absolutely need abc to be precisely defined in all cases or else it's useless. It's easy to see why people might like precision and unambiguity, but that isn't likely with something as simple and compact as abc. And the claim that we even need these things is disproved by the huge success of standard (;-) staff notation. (Also, from my background as a math student I might also observe that Kurt Goedel proved that we can't even reach total precision without ambiguity. But that's another topic altogether.) 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] ties and accidentals
| You can try to get ABC convenient, readable, close to some staff | notation or what ever you wan't. But first of all you must keep (or | get) it to contain unique (well formed or well defined if you want) | information. Well, now; I'm not sure I'd agree with that. Granted, I'd like to see such a computerized notation, and I suspect that both the lilypond and MusicML people are making good progress toward such a goal. But I don't think that we should push ABC in this direction. ABC's niche that led to its success is that it's a relatively simple, basic, plain-text notation that is compact and mailable. It doesn't require a sophisticated UI; it can be typed (and read) by mere humans. None of this would be true of any notation that is well formed and well defined. Predicate calculus is simpler than ABC and as well formed and well defined as anybody could want. It's sloppy, ill-defined notations that need fancy user interfaces. As far as I can see (from examples Laura has sent me) lilypond is nowhere near in the same league of precision as ABC - it's a random grab-bag of typesetting hacks. === http://www.purr.demon.co.uk/jack/ === To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
