OK - I can live with + and & but I still think it's not a good idea. If full stops (periods) are allowed, do they mean the same as commas?
There are other peculiarities to worry about, for instance Muse normally does automatic bar-length counting. For normal music (I will leave "normal" undefined!!) this eliminates a *lot* of misprints. Given that repeats can, and do fall part way between bars (the posh word is anacrusis) one needs to know what things are supposed to mean. The same problem re-surfaces in a player with a stress pattern - for instance if a British hornpipe is written "straight" but to be played "dotted" - what does it mean if a repeat has a beat missing? There is a real tension between the desire to correct misprints (very common) and the desire to be able to represent unusual tunes (by definition unusual, but that's not the same as "never"). For me repeats are a bit of a minefield and abc2ps (whether open-source or not) is not, I repeat not a good model. In fact I have never implemented the playing of parts as specified by P: syntax because of uncertainties in this area. Laurie ----- Original Message ----- From: John Chambers <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Sunday, December 09, 2001 5:24 AM Subject: Re: [abcusers] Progress towards a new abc standard is [1,3 | But it's silly. It adds nothing. Yes, it's only a few lines of code, but | it's adding code to achieve nothing new. Or else, please tell me how the | semantics of 1+3 and 1&3 differ from each other and from 1,3. Well, the [1+3 and [1&3 cases are silly, but they're trivial and easy to implement, so why not? It sorta like we allow Dm and Dmin and Dminor, all of which mean the same thing. Such things add no functionality, but they do add a bit of user friendliness at almost no implementation cost. | I wholeheartedly agree with John "we put this off until we can get | agreement that trivial cases like [3 and [1-3 and [2,4 are legal." | | You want me to start implementing 1,3 or you want me to argue about syntax | and what the complicated ones mean? I'd much prefer that people implement the simple cases. What's mostly needed is to just allow a string of digits, commas and hyphens. I also allow periods, because a lot of printed music uses them, though this also adds no functionality. The suggestion that '+' and '&' also be allowed was just a suggestion that could be vetoed if we want to take a vote on it. They definitely aren't necessary. For a music formatter like abc2ps, implementing endings like [1,3 and [1-3 is rather easy. But we might want to take pity on people writing abc players, and discuss the implementation a bit. If there are any real gotchas, it might be nice to know about them and discuss how to handle them. The obvious problem for a player is that people can easily type all sorts of of malformed endings. For example: |: ... |1,3 ... :|4 ... :| There's no 2nd ending here. I'd probably say that there are at least two possible behaviors here: You could play it three times, skipping the missing 2nd pass. Or you could play it four times, with a "null" ending on the second pass. I'd suggest that if the listed endings don't form a proper 1..N progression, that the behavior is up to the implementer. A player might want to produce a warning. A formatter wouldn't need to; it could just produce what the ABC says and let someone else worry about understanding those funny lists of numbers. Actually, I've seen music that had such "null" endings. For example, I've heard tunes that had an extra bar tacked onto the 2nd and 4th times. This would presumably be written as: |: AAA :|2,4 BBB :| Obviously, "AAA" and "BBB" represent much longer chunks of music. This would expand to | AAA | AAA | BBB | AAA | AAA | BBB |. This is something that's obviously not common, but it does happen in some kinds of music. So it shouldn't be treated as an error. 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
