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] Music of Dalkeith
A bunch of new ABCs at this site, but I've ZIPped them up to keep search engines out (for reasons which should be obvious when you look at the first page): One small point, Jack. The warning about Quicktime 5 has been overtaken by the facts, as Apple have now fixed that bug. QT 5.0.5 (released last week) works properly. Versions 5.0 - 5.0.3 were bad, and I don't know about 5.0.4 as I never saw it. Phil Taylor To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] abc - the new HTML?
Atte writes: | On Tue, 5 Feb 2002, Erik Ronstr=F6m wrote: | | One of my fears about abc is that is will go the same way as HTML. | snip | The keywords are backward compability. The browser developers don't | need to follow any standard, and of course they don't: that would make | 90% of all pages on the Net illegal. So they continue using their old, | inconsistent ways of doing things. And since they work and the browsers | allow it, people will continue using them when building homepages. | | Totally off topic, but the problem with html is that one browser dominates | to the extend that nobody cares what the standard says, they just write | code for that browser. Good comparison. Of course, there are about a zillion other web programs out there, with various specialized uses. They often act differently out of necessity. Few of them pay a whole lot of attention to standards designed for a flashy graphical browser, for very good reasons. Consider, for example, a web browser for use by the blind. How could it possibly correctly implement any formatting standards? | I think there is a large risk that abc develops in exactly this | direction. | | I fear it's too late already :-( I hope it's not, though. I'm not up to | date with the work on the standard, is there still a commission | working on what to include in the standard? I really think this work is | extremely important if abc is to have any future. What seems to have happened is more or less consistent with the past work on abc. The (semi-official) standards committee started with the idea that what it needed was a clear formulation of abc version 1.6 as a standard, and has worked on codifying that. New features are to be put off until the current standard is established. Of course, this is of little relevance to people who need things not covered by version 1.6, so those of us have continued on our merry way inventing random extensions for our own use, and wondering if the standards folks will ever catch up. Actually, this is also pretty consistent with most industry standards which, most of the time, end up making official what a few of the major players have done and imposed as a de-facto standard. Some have argued that this is the best way to make standards. Their argument is that separate standards efforts always bog down in exactly the way that abc has bogged down, in long legalistic discussions of arcane details that confuse most of the readers until they go away. This leaves only the pickiest of the legal types, who then produce a standard that nobody can understand or implement. So implementers do a lousy job of trying to follow a standard that they can't understand while users wonder what they hell the standards folks were thinking when they came up with such an ungodly mess. Meanwhile, those who just want something useful continue to build what they think is useful, and check back with the standards effort now and then to see if there's anything there they can understand well enough to actually implement. There are a lot of such people, and what they do isn't always consistent or compatible. We're continuing in a long tradition ... (As you may have guessed, I've been involved in a few computer industry standards efforts. ;-) To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
[abcusers] the abc standard [was: abc - the new HTML?]
On Wed, 6 Feb 2002, John Chambers wrote: | snip I'm not up to | date with the work on the standard, is there still a commission | working on what to include in the standard? I really think this work is | extremely important if abc is to have any future. What seems to have happened is more or less consistent with the past work on abc. The (semi-official) standards committee started with the idea that what it needed was a clear formulation of abc version 1.6 as a standard, and has worked on codifying that. New features are to be put off until the current standard is established. Of course, this is of little relevance to people who need things not covered by version 1.6, so those of us have continued on our merry way inventing random extensions for our own use, and wondering if the standards folks will ever catch up. Ok, who's in the committee, where can one follow the progress of their work, and what do they have to say? -- Atte To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
