Re: [abcusers] Progress towards a new abc standard
Bryan Creer just thought he'd ask: | John Chambers recently said - | But it's possible that we could put it to a vote, | | How would this be administered? Who would get a vote? Just the BIG 6? Only | developers? Anybody who wants to? | | But again, it's not topic of major importance. More important is that | we get some action making this sort of ending part of the published | abc standard syntax. | | Published where? The central point of contact for abc is Chris Walshaw's abc | home page. It is referenced widely in abc sites across the internet. Are | there arrangements for updating the standard held there or do you envision | setting up an alternative standard? Do you intend to co-operate with Guido | Gonzato or would his be a third separate standard? Well, that's a rather elegant summary of the usual problems. There is an ABC committee (which I thought should have called itself the ABC cabal), but their generally agreed policy has always been that any decisions would be put to a vote on abcusers. Then they wandered off in the direction of first codifying the 1.6 pseudo-standard, and that's sorta where things hang now. The rules for a vote have never been codified, to my knowledge. There's enough precedence on other lists and newsgroups that we could probably work out our own rules in short order, if we wanted to. Part of this was Chris's comment that he didn't particularly want to be the active center of such discussions, and he suggested a cabal, uh, committee, to give some coordination to the effort. Anyway, it's pretty clear that there's no intent to try to keep any discussion private. And there has been much more discussion on this list than in the standards list. It may be that the standards list will go the way of the old abc developers' list, which seems to have died out mostly because all the developers preferred an open discussion among all users. You'd think that there would be separate discussions of implementation details, but even there, the implementers prefer to discuss ideas here. This is probably because abcusers isn't such a high-volume list that mere users feel the need to expell the geeks to their own list. This is usually why a separate experts list gets created, not for any sort of privacy or exclusion, but simply to limit the flood of email. My impression is that Guido is also willing to coordinate his efforts with others; he just decided to do something because he didn't see any others doing it. This is also the motive behind a lot of the independent development of ABC extensions, including mine. I need this now, and those nice folks on abcusers don't seem to be able to settle any of the issues. They just keep wandering off into picky details and attempts to solve all the world's musical problems, and nothing ever gets decided. So I'll just do it myself and maybe some day they'll catch up. Chide, chide ... ;-) To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] Progress towards a new abc standard
Actually some of the most recent mail on the Cabal list (where there has recently been *very* little activity) was to question whether it should simply disband itself. And I notice (with a smile) that nobody seems to have bothered to answer the question - or was that in itself an answer!? Laurie - Original Message - From: John Chambers [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, December 12, 2001 4:09 PM Subject: Re: [abcusers] Progress towards a new abc standard Bryan Creer just thought he'd ask: | John Chambers recently said - | But it's possible that we could put it to a vote, | | How would this be administered? Who would get a vote? Just the BIG 6? Only | developers? Anybody who wants to? | | But again, it's not topic of major importance. More important is that | we get some action making this sort of ending part of the published | abc standard syntax. | | Published where? The central point of contact for abc is Chris Walshaw's abc | home page. It is referenced widely in abc sites across the internet. Are | there arrangements for updating the standard held there or do you envision | setting up an alternative standard? Do you intend to co-operate with Guido | Gonzato or would his be a third separate standard? Well, that's a rather elegant summary of the usual problems. There is an ABC committee (which I thought should have called itself the ABC cabal), but their generally agreed policy has always been that any decisions would be put to a vote on abcusers. Then they wandered off in the direction of first codifying the 1.6 pseudo-standard, and that's sorta where things hang now. The rules for a vote have never been codified, to my knowledge. There's enough precedence on other lists and newsgroups that we could probably work out our own rules in short order, if we wanted to. Part of this was Chris's comment that he didn't particularly want to be the active center of such discussions, and he suggested a cabal, uh, committee, to give some coordination to the effort. Anyway, it's pretty clear that there's no intent to try to keep any discussion private. And there has been much more discussion on this list than in the standards list. It may be that the standards list will go the way of the old abc developers' list, which seems to have died out mostly because all the developers preferred an open discussion among all users. You'd think that there would be separate discussions of implementation details, but even there, the implementers prefer to discuss ideas here. This is probably because abcusers isn't such a high-volume list that mere users feel the need to expell the geeks to their own list. This is usually why a separate experts list gets created, not for any sort of privacy or exclusion, but simply to limit the flood of email. My impression is that Guido is also willing to coordinate his efforts with others; he just decided to do something because he didn't see any others doing it. This is also the motive behind a lot of the independent development of ABC extensions, including mine. I need this now, and those nice folks on abcusers don't seem to be able to settle any of the issues. They just keep wandering off into picky details and attempts to solve all the world's musical problems, and nothing ever gets decided. So I'll just do it myself and maybe some day they'll catch up. Chide, chide ... ;-) 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] Progress towards a new abc standard
John Chambers recently said - But it's possible that we could put it to a vote, How would this be administered? Who would get a vote? Just the BIG 6? Only developers? Anybody who wants to? But again, it's not topic of major importance. More important is that we get some action making this sort of ending part of the published abc standard syntax. Published where? The central point of contact for abc is Chris Walshaw's abc home page. It is referenced widely in abc sites across the internet. Are there arrangements for updating the standard held there or do you envision setting up an alternative standard? Do you intend to co-operate with Guido Gonzato or would his be a third separate standard? Just thought I'd ask. Bryan Creer
Re: [abcusers] Progress towards a new abc standard is philosophy
Hello, I think the main topic here is about abc format philosophy. Laurie Griffiths: Why have these alternatives? They add nothing to the expressiveness of the language. To me a syntax should allow to write everything that does not harm its integrity. It is not the target to tell how a text must be written, but how it must not be written. Any expression a person wants to use should be legal as long as it does not collide with the integrity of the syntax. Even if I would not acctually know a person who wants to use a certain expression I would opt for the right to write that expression as long as it does not break the integrity of the code. Not asking all the time why should we allow this ? but Why not? and rejection not just being the personal oppinion that it is silly. Its one of the basic freedom rights, this right to do things others may call silly. regards Simon Wascher - Vienna, Austria http://members.chello.at/simon.wascher/ To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] Progress towards a new abc standard is [1,3
Hello,
John Chambers:
Simon Wascher writes:
| I would like to add:
| [1+3
| and
| [13
(...)
My current implementation has
-,.0123456789 as the legal chars; making it -,.+0123456789 is a
one-line change. (In an earlier discussion, someone also suggested
including x, but I don't recall what that meant.)
By the way: '[1+3' and '[13' (thirteen) should be legal but '[13+' ('+'
being the last char, not followed by a number) cannot be legal: its
ambigous with the +CEG+ chord notation. Similar case is '[n-' and '[n.'
[nx .
This leads to a list for all chars that *cannot* be part of the
'numeral' ending syntax:
1) all letters and obviously: '%', '\'
2) following chars cannot be the *last* char of a ending string (exept
in the proposed text case):
'+', '-', '.', '(', '[', '~', 'space', '_', '^', '=', '{',
In fact the last char in the numeral ending syntax must be a number.
All other chars would be recognized as part of the following abc text.
More general one could say:
$ a numeral ending begins with a '[' sign followed
$ by any number or by a string of any chars exept letters
$ (and '%' or '\'). The string must end with a number.
I know this is fairly liberal, but thats my weltanschauung.
Simon Wascher - Vienna, Austria
http://members.chello.at/simon.wascher/
To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] Progress towards a new abc standard is philosophy
On Mon 10 Dec 2001 at 01:05PM +0100, Simon Wascher wrote: Hello, I think the main topic here is about abc format philosophy. Laurie Griffiths: Why have these alternatives? They add nothing to the expressiveness of the language. To me a syntax should allow to write everything that does not harm its integrity. It is not the target to tell how a text must be written, but how it must not be written. Any expression a person wants to use should be legal as long as it does not collide with the integrity of the syntax. In short, why Occam's Razor instead of Occam's entire workshop of shaving instruments ? I think the answer is that you want people to actually write programs that will do things with abc. The more encrusted with options and strange cases a language becomes, the harder it is write a parser for it and the more likely that the parser will have bugs in at the end of it all. Also, the harder it becomes to add further encrustations at a later stage. James Allwright To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] Progress towards a new abc standard is philosophy
Simon Wascher [EMAIL PROTECTED] writes: Any expression a person wants to use should be legal as long as it does not collide with the integrity of the syntax. Not asking all the time why should we allow this ? but Why not? No. Extraneous ways of writing down the same thing means that programs which process the notation need to be more complicated in order to process all the possible variants instead of just one that is standardized. More complicated programs have a greater likelihood of containing mistakes. We emphatically do not need programs that contain more mistakes than necessary -- the world is full of them already. On a more abstract level, having several ways of writing down the same thing makes the standard longer. A longer standard takes longer for a person to read and understand, and therefore the extra complexity should be restricted to things that actually add expressive power to the ABC language. Allowing `13' and `1+3' in addition to `1,3' does not add expressive power, thus should be rejected. Finally, people new to ABC will wonder whether `1,3', `13' and `1+3' actually do mean the same thing in ABC or whether there are subtle, non-obvious differences between the three that they don't know about. This will be unnecessarily confusing. The word is `KISS'. Anselm -- Anselm Lingnau .. [EMAIL PROTECTED] I'd rather poke myself in the eye with a sharp stick than do GUI programming in Java. -- Mo DeJong To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] Progress towards a new abc standard is [1,3
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. I would suggest that interpreting it as a null ending should be in the spec as required behaviour. This is something I've often wanted with the existing repeat syntax but BarFly (at least) doesn't support it. It'd be particularly helpful for getting anacruses to add up when the tune shifts them between repeats (which is quite common). There is a problem with the way you've written that. The existing standard says there is NO extra repeat sign at the end, so it ought to have been |: ... |1,3 ... :|4 ... || The way you had it suggests you do the whole thing again once you get to the end of the 4th time. I have seen that kind of nested-repeat syntax used for real, but only in a manuscript by somebody who was desperate to save space. This is a mistake you find all over the net and it would be a great help if more programs produced warnings about it. It's an annoyance for sightreading: you see that repeat sign and briefly think back to where?, however often you've seen it before. I would much prefer it if there were some redundancy checking for this construct, by declaring the number of times at the start too. So your example would go |4: ... |1,3 ... :|4 ... || That would assist a program in correctness checking and it would warn the reader of the ABC source that something unusual was about to happen. There would be no obligation on display programs to print anything corresponding to the initial number. Also, I take it you mean to accept ... |[1,3 ... :|[4 ... and ... |... [1,3 ... :|... [4 ... as well? I never use the number-next-to-a-bar special case any more (the more general [n syntax is enough for me and it suits the kind of source layout I prefer). : I would like to add: :[1+3 : and :[13 Please NO. We might need those characters for something else one day (e.g. controlling the voice entries in rounds). : and a way of saying for example : [last time Good idea, but I don't think this is the same construct; usually it goes on the end of the *whole tune*, and strophic repeats are not represented in ABC (they'd need a nested-repeat syntax, as the tune might have internal repeats). It's a distinct topic. As this is a more emphatic, large-scale sort of variant repeat, how about this? [[^ ... % first time [[. ... % usual case [[$ ... % last time Any notation is going to be unfamiliar to most people but at least that's vaguely mnemonic to folks who've used Unix pattern matchers. === http://www.purr.demon.co.uk/jack/ === To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] Progress towards a new abc standard is [1,3
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 13 differ from each other and from 1,3. Well, the [1+3 and [13 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
Re: [abcusers] Progress towards a new abc standard is [1,3
Hello, John Chambers: Well, the [1+3 and [13 cases are silly, Well, to me it is what I write in tadpoles notation, maybe this is an austrian speciality but I understand 1+3 as first *and* third ending and 1+3 is a shortcut for this. by the way, I thought we came to the conclusion not to qualify other listmembers postings as silly. Not every bit of notation I do not share, use or understand is neccessarily silly. :-| Simon Wascher - Vienna, Austria http://members.chello.at/simon.wascher/ To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] Progress towards a new abc standard is [1,3
John Chambers: | [last time Yeah; this is useful. But a problem in the past has been that the discussion of how to do this bogs down as people try to solve all possible repeat problems. After a while, people get bored trying to follow the abstrusities, the topic dies, and nothing happens. I'd suggest that we first make sure that [1,3 and similar endings are explicitly legal, so that they'll get implemented and people can use them. The general case should be a separate discussion. If we delve into it again, we'll never get anything but first and second endings. | `|(spaces, backslashes, linebreakes, tabs)[numeraltext' | | where numeral also could be any of the extentions proposed earlier. There is a serious ambiguity here. Consider something like: [1FooABC Ooops, an euphoric lack of concentration, pardon and thanks for the correction. But anyway [last time will work without troubles. But I agree that the votes on [1,3 and on [text must be separated. regards Simon Wascher - Vienna, Austria http://members.chello.at/simon.wascher/ P.S.:(I know you warned me to go on with this): [textnumeral would work. Not that I really need this :-) . To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] Progress towards a new abc standard is [1,3
If you want an apology then it means I have been misunderstood and I am sorry for any offence (which *is* an apology). I described the IDEA as silly. Not at all the same thing as describing the person as silly. (Show me the person who has never had a silly idea and I'll show you a person who has few ideas). There may also be a language thing - silly is to my ear very mild. I understand that 1,3 means first *and* third ending 13 means first *and* third ending 1+3 means first *and* third ending 1.3 means first *and* third ending but why not have 1 3 1 and 3 1st, 3rd 1er3me #1,#3 first and third premier et troisieme too while we are at it? I also understand that 1-3 means first, second and third ending but why not 1/3 1~3 for the same thing? I would still personally prefer to have just one way to write it rather than all of these variants. I care rather little which of the variants is chosen but my preference is for ones towards the tops of the lists of alternatives. Laurie Griffiths http://www.musements.co.uk/muse where you will find music notation software for PCs. - Original Message - From: Simon Wascher [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Sunday, December 09, 2001 11:44 PM Subject: Re: [abcusers] Progress towards a new abc standard is [1,3 Hello, John Chambers: Well, the [1+3 and [13 cases are silly, Well, to me it is what I write in tadpoles notation, maybe this is an austrian speciality but I understand 1+3 as first *and* third ending and 1+3 is a shortcut for this. by the way, I thought we came to the conclusion not to qualify other listmembers postings as silly. Not every bit of notation I do not share, use or understand is neccessarily silly. :-| Simon Wascher - Vienna, Austria http://members.chello.at/simon.wascher/ 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] Progress towards a new abc standard is [1,3
If you want an apology then it means I have been misunderstood and I am sorry for any offence (which *is* an apology). I described the IDEA as silly. Not at all the same thing as describing the person as silly. (Show me the person who has never had a silly idea and I'll show you a person who has few ideas). There may also be a language thing - silly is to my ear very mild. Also, there is nothing silly about any of the alternatives - the thing that's silly is having more than one of them to mean the same thing when they are not even shorter. Sharps are currently written as ^c, we don't allow c# as an alternative. Why have these alternatives? They add nothing to the expressiveness of the language. I understand that 1,3 means first *and* third ending 13 means first *and* third ending 1+3 means first *and* third ending 1.3 means first *and* third ending but why not have 1 3 1 and 3 1st, 3rd 1er3me #1,#3 first and third premier et troisieme too while we are at it? I also understand that 1-3 means first, second and third ending but why not 1/3 1~3 for the same thing? I would still personally prefer to have just one way to write it rather than all of these variants. I care rather little which of the variants is chosen but my preference is for ones towards the tops of the lists of alternatives. Laurie Griffiths http://www.musements.co.uk/muse where you will find music notation software for PCs. - Original Message - From: Simon Wascher [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Sunday, December 09, 2001 11:44 PM Subject: Re: [abcusers] Progress towards a new abc standard is [1,3 Hello, John Chambers: Well, the [1+3 and [13 cases are silly, Well, to me it is what I write in tadpoles notation, maybe this is an austrian speciality but I understand 1+3 as first *and* third ending and 1+3 is a shortcut for this. by the way, I thought we came to the conclusion not to qualify other listmembers postings as silly. Not every bit of notation I do not share, use or understand is neccessarily silly. :-| Simon Wascher - Vienna, Austria http://members.chello.at/simon.wascher/ 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] Progress towards a new abc standard is [1,3
On Tue, Dec 04, 2001 at 04:26:57PM -, Laurie Griffiths wrote: I would still personally prefer to have just one way to write it rather than all of these variants. I care rather little which of the variants is chosen but my preference is for ones towards the tops of the lists of alternatives. Hear, hear! -- Taral [EMAIL PROTECTED] This message is digitally signed. Please PGP encrypt mail to me. Any technology, no matter how primitive, is magic to those who don't understand it. -- Florence Ambrose msg03026/pgp0.pgp Description: PGP signature
Re: [abcusers] Progress towards a new abc standard is [1,3
Simon Wascher writes: | John Chambers: | Well, the [1+3 and [13 cases are silly, | | Well, to me it is what I write in tadpoles notation, maybe this is an | austrian speciality but I understand 1+3 as first *and* third ending | and 1+3 is a shortcut for this. | | by the way, I thought we came to the conclusion not to qualify other | listmembers postings as silly. Not every bit of notation I do not | share, use or understand is neccessarily silly. | | :-| Sorry if I offended. I was basically just being a bit flippant. By silly I don't really mean there's anything wrong with it, just that it seems like something that's not one or the world's major problems at the moment. While I've seen this use of '+', I haven't seen it often. Commas are by far the overwhelming choice of most publishers for this usage. I can see why people would want to not bother with anything else, but on the other hand, allowing such alternate chars is also not a big deal to a programmer. My response to such things would be to shrug and add it to the program (which I've already done with my abc2ps clone). But it's possible that we could put it to a vote, in which case it could easily be rejected. But again, it's not topic of major importance. More important is that we get some action making this sort of ending part of the published abc standard syntax. To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] Progress towards a new abc standard is: |:: ... ::|
Hello, there is no reason to reject ::| and :::| notation as far as I see. Additive complementary constructs (intriguing to me) could be: :text| and :numeral| the text construct would allow to specify freely any text that gives information on the number of repeats. examples: :repeat this bit as often as you feel like| :3 times| :(3x)| :add one repeatation every time through| by chance existing programs may accept this 'text' like any other text in quotes, and only those who have such a feature implemented will recognize a 'text' within the repeat sign as being a special text for describing the number of repeatations. In extention to this clever playback programms eventually could filter through the :'text'| and search for numerals and even numbers in words and use these for playback. in the :numeral| construct the numeral gives the number of repeats, which easily could be interpreted by playback *and* display programs, to do whatever they are programmed to in such a case. examples: :2| % equals :| :3| % play section three times :5| % play section five times As a final extention-extention :numeraltext| could be allowed where the numeral defines the number of repeats for playback and the 'text' is displayed. This may be usefull if the 'text' does *not* contain computer-readable information, and the transcriber wants to suggest that the section should be repeated by the playback program three or maybe nine times exemplarily. One nice things with these constructions, which could be used paralell to the ':::|' construct , is that they do allow a very user/transcriber orientated approach with very little limitations, as the number of repeats can be choosen free, and alternatively a text which can be identified by programs as repeat-related can be added to extend the possibilities further out. I think such a solution would end discussions on this topic for a long time. Simon Wascher John Chambers wrote: Jack Campin writes: | Something I've also implemented is the conventional |:: ... ::| | notation that says three times through. ... | In music I've seen that uses this construct, it's represented by | printing (3x) above the staff. A staff-notation generator could | do whatever it liked with |:: ... ::|, but I suspect that most | non-Scandiwegian users would be happier with some such explicit | representation using honest-to-god numerals. Yeah; I've seen that, too. OTOH, I've seen the |::: ... :::| notation used a fair amount in music from Eastern Europe and the Balkans, and even musicians who claim not to have seen the notation before always seem to know what it means without explanation. I don't thing I've ever seen it used for more than 3 repeats (four times through). It would get difficult to count. One problem with using (3x) is that this looks a lot like a strange chord symbol to software. Maybe it should be ^(3x). | Does any system of notation have a sign for repeat this bit as often | as you feel like? The definitive use of that is in Terry Riley's | In C, but it occurs implicitly in quite a few genres. In fact, this happens in Scandinavian and German folk dance. It's usually tied in with a dance that has two different steps that match the music (e.g., zwiefacher). There are some tunes that are often played with irregular repeats, to see if the dancers can handle it. A slightly simpler version, for non-expert dancers, would do something like an arithmetic progression, playing the phrase N times in the Nth time through the dance, or something like that. All the notation I've seen for this has been idiosyncratic. And often in German or Swedish or Finnish. Some years back, Scientific American published the Telnet Song that had nested for-loops as the repeat indicators. It was a cute song that described the escape sequences required to back out gracefully from a chain of telnet connections without leaving any dangling connections alive on any of the machines. -- Simon Wascher - Vienna, Austria http://members.chello.at/simon.wascher/ To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] Progress towards a new abc standard is [1,3
Hello, John Chambers wrote: (...) [First and second repeats] After several online discussions, I (and probably a few others) have implemented the rather trivial extension of allowing any string of digits, commas, hyphens and periods to label an ending. This means that endings like [1,3 and [1-3 work with a very few abc tools. If you use them in your tunes, my Tune Finder will handle them and return correct PS or GIF notation. I agree that [1,3 and [1-3 should be standard. It is easy to separate this ending stuff from other abc text. I would like to add: [1+3 and [13 and a way of saying for example [last time (this can be found in arrangements for traditional tunes) I want to give it a try: the standard for combining chords and guitarchords correctly is: [Order of symbols from the 1.6 standard] `Open and close chord symbols, [], should enclose entire note sequences (except for guitar chords), i.e. C[CEGc]' since the annotation syntax derivates from the guitarchord syntax I presume that this is also the legal order for annotations. What I want to create is a text field that is not an ordinary annotation but a text that *replaces* (or adds to) the number in the endings bracket. The standard for ending brackets is: [First and second repeats from the 1.6 standard] `First and second repeats can be generated with the symbols [1 and [2, When adjacent to bar lines, these can be shortened to |1 and :|2 ...' My Idea is to use the annotation syntax and the first and second ending (i.e. `repeats') syntax and combine them to textual ending syntax. On first sight it is clear that `|last time' would be accepted by all programmes but just as ordinary annotation. So such an extention cannot work with this shortcut. But with the standards *normal* version using the squarebracket (begin) as indicator for the special case `first or second ending', no serious troubles arise: `[last time' is non-ambiguous since [ is not legal under any other circumstances. (the meaning can be backed by the fact that the squarebracket as ending indicator is allways preceded by a | character (legally followed by no other characters than backslashes, spaces, linebreakes, tabs), meaning never preceded by a letter. So my proposal is: $ the numbers in the brackets of a first or second ending % (may we call these `multiple endings'?) $ can be replaced by a text in quotes. In this case it $ does not work to use the shortcut |text since this $ would be interpreted as a guitarchord Again I do not see any troubles to allow the extention-extention: `|(spaces, backslashes, linebreakes, tabs)[numeraltext' where numeral also could be any of the extentions proposed earlier. Example: abcdefg |1+3 a2bcdefg :|\ [2+4 b2cdefga ||\ [last ending c8 |] Or abcdefg |1+3last ending a2bcdefg :|\ [2+4 b2cdefga |] regards, Simon Wascher - Vienna, Austria http://members.chello.at/simon.wascher/ To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] Progress towards a new abc standard is [1,3
If 1+3 means the same as 1,3 then I would NOT like to see it. Multiple different ways to write the same thing just makes things more complicated. I presume that 1-3 means the same as 1,2,3. I can live with that as it could save a lot of typing;1-6 is much shorter than 1,2,3,4,5,6. Laurie - Original Message - From: Simon Wascher [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Saturday, December 08, 2001 2:00 PM Subject: Re: [abcusers] Progress towards a new abc standard is [1,3 Hello, John Chambers wrote: (...) [First and second repeats] After several online discussions, I (and probably a few others) have implemented the rather trivial extension of allowing any string of digits, commas, hyphens and periods to label an ending. This means that endings like [1,3 and [1-3 work with a very few abc tools. If you use them in your tunes, my Tune Finder will handle them and return correct PS or GIF notation. I agree that [1,3 and [1-3 should be standard. It is easy to separate this ending stuff from other abc text. I would like to add: [1+3 and [13 and a way of saying for example [last time (this can be found in arrangements for traditional tunes) I want to give it a try: the standard for combining chords and guitarchords correctly is: [Order of symbols from the 1.6 standard] `Open and close chord symbols, [], should enclose entire note sequences (except for guitar chords), i.e. C[CEGc]' since the annotation syntax derivates from the guitarchord syntax I presume that this is also the legal order for annotations. What I want to create is a text field that is not an ordinary annotation but a text that *replaces* (or adds to) the number in the endings bracket. The standard for ending brackets is: [First and second repeats from the 1.6 standard] `First and second repeats can be generated with the symbols [1 and [2, When adjacent to bar lines, these can be shortened to |1 and :|2 ...' My Idea is to use the annotation syntax and the first and second ending (i.e. `repeats') syntax and combine them to textual ending syntax. On first sight it is clear that `|last time' would be accepted by all programmes but just as ordinary annotation. So such an extention cannot work with this shortcut. But with the standards *normal* version using the squarebracket (begin) as indicator for the special case `first or second ending', no serious troubles arise: `[last time' is non-ambiguous since [ is not legal under any other circumstances. (the meaning can be backed by the fact that the squarebracket as ending indicator is allways preceded by a | character (legally followed by no other characters than backslashes, spaces, linebreakes, tabs), meaning never preceded by a letter. So my proposal is: $ the numbers in the brackets of a first or second ending % (may we call these `multiple endings'?) $ can be replaced by a text in quotes. In this case it $ does not work to use the shortcut |text since this $ would be interpreted as a guitarchord Again I do not see any troubles to allow the extention-extention: `|(spaces, backslashes, linebreakes, tabs)[numeraltext' where numeral also could be any of the extentions proposed earlier. Example: abcdefg |1+3 a2bcdefg :|\ [2+4 b2cdefga ||\ [last ending c8 |] Or abcdefg |1+3last ending a2bcdefg :|\ [2+4 b2cdefga |] regards, Simon Wascher - Vienna, Austria http://members.chello.at/simon.wascher/ 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] Progress towards a new abc standard is: |:: ... ::|
Simon Wascher [EMAIL PROTECTED] writes: Hello, there is no reason to reject ::| and :::| notation as far as I see. Additive complementary constructs (intriguing to me) could be: :text| and :numeral| assume rest of proposal is included by reference I second this proposal. I have a lot of pieces where :3| would be extremely useful. Right now, the alternatives are: 1) unroll the repeats (convert |: abcd :3| to |abcd|abcd|abcd|) 2) Turn the repeated section into a part, and use P:A3 to get the repeats Neither are particularly good. The first both eats up lots of space and hides what's really going on. The second can get rediculously complicated. I have on piece which has several parts, each of which would be :3|. So I have P:A3B3C3D3E3F3, which is rediculous. I would also like, if possible, to be able to do |: |: ... :3| |: ... :3| :3|, but I can probably live with P:(AB)3 in that case. -- Buddha Buck [EMAIL PROTECTED] I will not die an ironic death -- Scott Ian, lead singer for the metal band Anthrax, after bioterrorist attacks using anthrax. To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] Progress towards a new abc standard is [1,3
Simon Wascher writes: | I would like to add: | [1+3 | and | [13 This is easy; it adds a couple of chars to the list of acceptable chars in the ending string. As long as these chars can't start another ABC term, there's no ambiguity. My current implementation has -,.0123456789 as the legal chars; making it -,.+0123456789 is a one-line change. (In an earlier discussion, someone also suggested including x, but I don't recall what that meant.) | and | a way of saying for example | | [last time Yeah; this is useful. But a problem in the past has been that the discussion of how to do this bogs down as people try to solve all possible repeat problems. After a while, people get bored trying to follow the abstrusities, the topic dies, and nothing happens. I'd suggest that we first make sure that [1,3 and similar endings are explicitly legal, so that they'll get implemented and people can use them. The general case should be a separate discussion. If we delve into it again, we'll never get anything but first and second endings. | `[last time' is non-ambiguous since [ is not legal under any other | circumstances. ... | `|(spaces, backslashes, linebreakes, tabs)[numeraltext' | | where numeral also could be any of the extentions proposed earlier. There is a serious ambiguity here. Consider something like: [1FooABC Under the current semi-standard, Foo is a chord symbol. Under your syntax, it is also an ending notation. It can't be both. Note also that, strictly speaking, the | isn't part of ABC's ending syntax. Endings need not start at bar lines. They usually do, true, but not always. The |1 notation is a shorthand for |[1 based on the fact that there's no ambiguity since a bracket can't otherwise be followed by a digit. But in the current syntax, [ followed by a digit is what tells a parser that it's an ending. Several possible extended syntaxes have been suggested in the past. But since this has led to endless discussions that have led nowhere, I'd still suggest we put this off until we can get agreement that trivial cases like [3 and [1-3 and [2,4 are legal. (Then we can wander off into discussing the introduction of for-loop notation into ABC as a general solution to looping problems. ;-) To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] Progress towards a new abc standard is: |:: ... ::|
there is no reason to reject ::| and :::| notation as far as I see. You go on to suggest a more powerful formalism, so one reason would be that we simply don't need it. [Simon's message rearranged...] Additive complementary constructs (intriguing to me) could be: :numeral| This looks good, but perhaps it would help to do the same as staff notation here: use paired bracketing signs. |numeral: ... :numeral| Where the numerals must match. With a construct like this you don't want people invoking it accidentally by a single miskeying; it might not be obvious you'd made a mistake and you could perpetrate persistent misinformation. How this gets displayed is up to the staff notation software and maybe the user. It could print |:: and ::| signs or (3x) above the staff depending on what the programmer likes, or the user might be given a choice. They mean the same, it's just a presentation issue. Maybe we could add some free choice constructs the same way: |2-: ... :2-| repeat at most once if you want |2+: ... :2+| repeat at least once No tearing hurry for that, I guess. :text| the text construct would allow to specify freely any text that gives information on the number of repeats. examples: :repeat this bit as often as you feel like| :3 times| :(3x)| :add one repeatation every time through| by chance existing programs may accept this 'text' like any other text in quotes, and only those who have such a feature implemented will recognize a 'text' within the repeat sign as being a special text for describing the number of repeatations. In extention to this clever playback programms eventually could filter through the :'text'| and search for numerals and even numbers in words and use these for playback. This sounds like a recipe for trouble: ... :repeated only on the 1930 recording| but probably not repeated 1930 times, as an over-helpful player program might conclude. As a final extention-extention :numeraltext| could be allowed where the numeral defines the number of repeats for playback and the 'text' is displayed. This may be usefull if the 'text' does *not* contain computer-readable information, and the transcriber wants to suggest that the section should be repeated by the playback program three or maybe nine times exemplarily. I much prefer this, it separates the bits computers and people are expected to understand. Text should rarely be needed: only the last of your examples is something a computer implementation would have real trouble with (in fact I've seen a program that played cumulative song tunes from a grammar rule specification some 20 years ago, but the notation it interpreted wasn't as general as ABC). Most often you'd want these textual instructions to be printed at the start of the repeated section, so they might be better placed there in the ABC as well. === http://www.purr.demon.co.uk/jack/ === To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] Progress towards a new abc standard
Jack Campin wrote: In music I've seen that uses this construct, it's represented by printing (3x) above the staff. A staff-notation generator could do whatever it liked with |:: ... ::|, but I suspect that most non-Scandiwegian users would be happier with some such explicit representation using honest-to-god numerals. So you're picking on us poor peaceful vikings again, eh? ;-) I wouldn't say that kind of notation is common in my part of the world, really. I know about it, and I've seen one or two occurences, but very few. It might be more used in Sweden trhan in Norway, though. Traditional Norwegian music (or at least what survives of it) tends to be either rather free improvisational pieces without any repeats at all or strictly built on one of the continental art music forms (binary, trinary or rondo). As a matter of fact, two of the best known Norwegian folk tunes were composed by Leopold Mozart and Jean-Baptiste Lully respectively ;-) Does any system of notation have a sign for repeat this bit as often as you feel like? The definitive use of that is in Terry Riley's In C, but it occurs implicitly in quite a few genres. In jazz and related music forms you usually write rep. ad lib or something like that above the repeat sign. Frank Nordberg http://www.musicaviva.com To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] Progress towards a new abc standard
After several online discussions, I (and probably a few others) have implemented the rather trivial extension of allowing any string of digits, commas, hyphens and periods to label an ending. This means that endings like [1,3 and [1-3 work with a very few abc tools. It seems that this should be a rather trivial addition to most abc programs (though players would have a bigger problem of needing to actually understand the ending syntax in some minimal sense). Does it behave correctly in this case?... ... K:D ...(a)... |: ...(b)... [1,3 [K:D Minor] ...(c)... :| [2 ...(d)... || % no key change ...(e)... The key signature is two sharps for the (a), (b) and (d) music and one flat for the (c) and (e) sections. (I can easily imagine a piece actually having this structure, and if there isn't one already out there maybe I'll just write one...) Display-only programs sometimes need to simulate execution too. === http://www.purr.demon.co.uk/jack/ === To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] Progress towards a new abc standard
Jack writes: | After several online discussions, I (and probably a few others) have | implemented the rather trivial extension of allowing any string of | digits, commas, hyphens and periods to label an ending. This means | that endings like [1,3 and [1-3 work with a very few abc tools. ... | | Does it behave correctly in this case?... |... |K:D |...(a)... ||: ...(b)... [1,3 [K:D Minor] ...(c)... :| | [2 ...(d)... || % no key change |...(e)... | | The key signature is two sharps for the (a), (b) and (d) music and | one flat for the (c) and (e) sections. (I can easily imagine a piece | actually having this structure, and if there isn't one already out | there maybe I'll just write one...) Well, what I'd say is that it doesn't much matter, because this is rather bad notation. If you were to stick it on stands in front of a bunch of musicians, some would play (e) in D major and others would play (d) in D minor. You can insult the musicians all you want, but that wouldn't get them to do it right. (Of course, it's still a bit odd to see abc notation on a music stand. ;-) The right way is to put an advisory key change at the start of (e) to make it clear to everyone (human and software) what the intended key is. Otherwise, you are asking for a disaster when that point in the music is reached. Standard music notation is a bit of an oxymoron, and subtleties like this are not understood in any consistent manner by musicians. It may be true that a lot of musicians are not very well educated in notational matters. But the only workable solution is to not leave such ambiguities in your notation. I'd also predict that, no matter what we might decide here, many of the folks who write abc software would probably not much notice, and would do whatever they damned well please. Or they'd not even consider the problem, and what the code does would be an accident. So, while it may be a Good Idea to say in the standard what happens in such cases, it wouldn't help all that much. What abc2ps does is just take things in order. The [K:Dminor] causes a D minor signature to appear thereafter, until there's another K field. This is probably more or less an accident, though Michael may have thought of the topic. I wouldn't be surprised if some abc players reverted to D major on the repeat and kept that key for (e). I wouldn't criticise either programmer for this; I'd criticise the person who typed the low-quality abc with the missing K field. (I wonder if there are any players that would stay in D minor for the start of the repeat? Isn't that what the music says? ;-) But back to endings ... One of the reasons that I've implemented the [1,3 type endings is that the current abc standard leads to a specific musical disaster that I've seen too many times. If only [1 and [2 are allowed, the only way you can get the usual four-time pattern is by writing: |: ... |[1 ... :|[2 ... :| In this case, the final :| is a very subtle clue that you should then repeat the entire section. But most musicians react to this by either not noticing the final colon, or by deciding that it's gotta be a typo, since the ending brackets very clearly say that there are only a first and second ending. This has turned up repeatedly in our open band Scandinavian dances. Traditional Scand music typically repeats phrases four times, usually with two different endings. Sitins who are reading the music (and don't know the style well) will almost always ignore the :| and barge ahead with the next part, while the experienced Scand musicians will do the third repeat. The result is usually a total collapse of the music. And often someone will observe that the music clearly shows only two endings. This is very misleading, but what can ya do if the software won't permit third and fourth endings? But abc2ps is open source, so I didn't have to live with a showstopper like this; I could fix it. The fact is that most musicians use the 1,3 and 2,4 in the ending brackets to determine the repeat pattern, and pretty much ignore the colons. This is totally conventional music notation, and almost all literate musicians understand it. Including the ,3 and ,4 under the ending brackets prevents the musical disaster. There's no excuse for this not being in abc after all these years. If we can't get it into the standard, the only sensible approach for musicians like me is to just ignore the standard and do what we have to do to get the music correct. To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] Progress towards a new abc standard
| After several online discussions, I (and probably a few others) have | implemented the rather trivial extension of allowing any string of | digits, commas, hyphens and periods to label an ending. This means | that endings like [1,3 and [1-3 work with a very few abc tools. ... | | Does it behave correctly in this case?... |... |K:D |...(a)... ||: ...(b)... [1,3 [K:D Minor] ...(c)... :| | [2 ...(d)... || % no key change |...(e)... | | The key signature is two sharps for the (a), (b) and (d) music and | one flat for the (c) and (e) sections. (I can easily imagine a piece | actually having this structure, and if there isn't one already out | there maybe I'll just write one...) Well, what I'd say is that it doesn't much matter, because this is rather bad notation. If you were to stick it on stands in front of a bunch of musicians, some would play (e) in D major and others would play (d) in D minor. You can insult the musicians all you want, but that wouldn't get them to do it right. (Of course, it's still a bit odd to see abc notation on a music stand. ;-) The right way is to put an advisory key change at the start of (e) to make it clear to everyone (human and software) what the intended key is. Otherwise, you are asking for a disaster when that point in the music is reached. If the semantics is specified it *is* clear to the software. You could simply say my example was illegal and *require* such an advisory key signature, but your software would have to do exactly the same semantic analysis to decide that the advisory was needed. So that's no simplification at all for programmers. Standard music notation is a bit of an oxymoron, and subtleties like this are not understood in any consistent manner by musicians. Doesn't matter if the musician is using the output of a correctly implemented ABC-to-staff-notation generator. It'll put the right key signature in for section (e) and the user doesn't need to know how it got there. I'd also predict that, no matter what we might decide here, many of the folks who write abc software would probably not much notice, and would do whatever they damned well please. Or they'd not even consider the problem, and what the code does would be an accident. So, while it may be a Good Idea to say in the standard what happens in such cases, it wouldn't help all that much. The point of my raising it was to get people to consider the problem. I don't think there are any currently active developers as disconnected from this list as you're suggesting. What abc2ps does is just take things in order. The [K:Dminor] causes a D minor signature to appear thereafter, until there's another K field. This is correct if thereafter means the actual sequence of notes played, wrong if it means the sequence of characters in the file. In fact the description above wouldn't even work with the latter interpretation for a 1.6-standard [1 ... [2 ... repeat, if the key change was only on the first time. (I wonder if there are any players that would stay in D minor for the start of the repeat? Isn't that what the music says? ;-) Laurie went over the precise analogue of this for the case of tempo and beat constructs. The only difference is that key is something display programs can't ignore. Here is a real-life example (slightly reorganized from one in my modes tutorial): X:1 T:Sister Jean S:Catriona Macdonald M:6/8 L:1/8 Q:3/8=80 R:andante K:DDor D2E F2G|ABA G2F|E2C C2G|E3D2C|D2E F2G|ABA A2G| A2d d2c|d3 D3:| K:DMix A2B c2d|efe e2c|A2B c2G|E3 [1 C3 |A2B c2d|efe e2d|[K:D]f2d d2c|d3 A3:| [2 C2B|A2A F2D|A2A F2D| A2d d2c|d3 D3|] BarFly gets the staff notation for that wrong but plays it correctly: that is, the c's in the second-time repeat are printed sharp and played natural. Does abc2ps print a two-sharp signature for the last line too? Yes, it would be more conventional to just notate the above using accidentals, but in the context it came from there was a specific reason for using key/mode signatures instead. There's no excuse for this not being in abc after all these years. Not having its interaction with the rest of the notation properly specified so that it can be generally implemented seems a pretty good excuse to me. I imagine many implementors vaguely anticipated troubles along the lines of the those I've described, decided here be dragons, and put it off to such time as it might be unavoidable. But the difficulties aren't insurmountable. Unrolling repeats and header-controlled part order are source-to-source operations of the sort that any decent ABC editing toolkit ought to have; they don't require the implementors of player programs to understand PostScript or those of formatters to understand MIDI. This stuff should be common ground. If we're considering an open-source parser there's no excuse
Re: [abcusers] Progress towards a new abc standard
Something I've also implemented is the conventional |:: ... ::| notation that says three times through. Every now and then I see repeat signs with 4 dots in a line instead of 2, which are simply a different style of ordinary repeat. Do you have a reference to back up your assertion that |:: is conventional ? This is certainly a useful thing to have, but it would be good to be sure that we are using widely understood conventions rather than adopting someone's ad hoc solution. The other reservation I have about this notation is that it doesn't generalize very well to n times through. In music I've seen that uses this construct, it's represented by printing (3x) above the staff. A staff-notation generator could do whatever it liked with |:: ... ::|, but I suspect that most non-Scandiwegian users would be happier with some such explicit representation using honest-to-god numerals. Does any system of notation have a sign for repeat this bit as often as you feel like? The definitive use of that is in Terry Riley's In C, but it occurs implicitly in quite a few genres. === http://www.purr.demon.co.uk/jack/ === To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] Progress towards a new abc standard
Jack Campin writes: | Something I've also implemented is the conventional |:: ... ::| | notation that says three times through. ... | In music I've seen that uses this construct, it's represented by | printing (3x) above the staff. A staff-notation generator could | do whatever it liked with |:: ... ::|, but I suspect that most | non-Scandiwegian users would be happier with some such explicit | representation using honest-to-god numerals. Yeah; I've seen that, too. OTOH, I've seen the |::: ... :::| notation used a fair amount in music from Eastern Europe and the Balkans, and even musicians who claim not to have seen the notation before always seem to know what it means without explanation. I don't thing I've ever seen it used for more than 3 repeats (four times through). It would get difficult to count. One problem with using (3x) is that this looks a lot like a strange chord symbol to software. Maybe it should be ^(3x). | Does any system of notation have a sign for repeat this bit as often | as you feel like? The definitive use of that is in Terry Riley's | In C, but it occurs implicitly in quite a few genres. In fact, this happens in Scandinavian and German folk dance. It's usually tied in with a dance that has two different steps that match the music (e.g., zwiefacher). There are some tunes that are often played with irregular repeats, to see if the dancers can handle it. A slightly simpler version, for non-expert dancers, would do something like an arithmetic progression, playing the phrase N times in the Nth time through the dance, or something like that. All the notation I've seen for this has been idiosyncratic. And often in German or Swedish or Finnish. Some years back, Scientific American published the Telnet Song that had nested for-loops as the repeat indicators. It was a cute song that described the escape sequences required to back out gracefully from a chain of telnet connections without leaving any dangling connections alive on any of the machines. To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] Progress towards a new abc standard
Jack Campin writes: | Here is a real-life example (slightly reorganized from one in my modes | tutorial): | | X:1 | T:Sister Jean | S:Catriona Macdonald | M:6/8 | L:1/8 | Q:3/8=80 | R:andante | K:DDor | D2E F2G|ABA G2F|E2C C2G|E3D2C|D2E F2G|ABA A2G| A2d d2c|d3 D3:| | K:DMix | A2B c2d|efe e2c|A2B c2G|E3 [1 C3 |A2B c2d|efe e2d|[K:D]f2d d2c|d3 A3:| |[2 C2B|A2A F2D|A2A F2D| A2d d2c|d3 D3|] | | BarFly gets the staff notation for that wrong but plays it correctly: | that is, the c's in the second-time repeat are printed sharp and played | natural. Does abc2ps print a two-sharp signature for the last line too? Thanks for the example; I've added it to my abc test directory. What abc2ps does is probably not surprising: The third staff had a key signature of two sharps. That's sorta what I'd expect, though I'm not too happy with the whole mess. I do know a number of (mostly Scandinavian) tunes that do this sort of thing. It's always notated with accidentals. I can see why one might prefer a key change in some cases for aesthetic reasons, though I'd probably be paranoid and insert another key change in the second ending to make sure that nobody can get it wrong. Unless I'm trying to do an urtext version, I've learned to be overly redundant about such things. (And even then, some people just don't believe the notation and do something normal instead. ;-) Maybe I should look for opportunities to do this sort of thing ... To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] Progress towards a new abc standard
James Allwright wrote a week or so ago: | For those who have wondered what got discussed by the abc standards | committee, here is a summary of our discussion. The section numbers | referred to can be found at | | http://abc.sourceforge.net/standard-propose/ Y'know, I've been wondering whether anything was happening with this. Then I found that I'd been dropped from abcusers, which explained why it was sorta quiet. But in looking around, I still get the feeling that not much has happened ... One things I see in the above file is no change at all for something that I and a few others have discussed on numerous occasions: |3.7 First and second repeats | |3.7.0.1 |First and second repeats can be generated with the symbols [1 |and [2, e.g. faf gfe|[1 dfe dBA:|[2 d2e dcB|]. When adjacent to |bar lines, these can be shortened to |1 and :|2, but with regard |to spaces | [1 is legal, | 1 is not. There's a real problem here that most abc tools still implement only the [1 and [2 cases, and forbid the use of 3rd and later endings. The above doesn't actually outlaw 3rd endings; of course; it merely gives two examples and leaves other endings to the reader's imagination. It's fairly obvious how to notate the usual endings, but there's still no part of the proposed abc standard that mentions or explicitly legalizes them. After several online discussions, I (and probably a few others) have implemented the rather trivial extension of allowing any string of digits, commas, hyphens and periods to label an ending. This means that endings like [1,3 and [1-3 work with a very few abc tools. If you use them in your tunes, my Tune Finder will handle them and return correct PS or GIF notation. It seems that this should be a rather trivial addition to most abc programs (though players would have a bigger problem of needing to actually understand the ending syntax in some minimal sense). It took me maybe half an hour to get this working in abc2ps, and now I can notate my Scandinavian musical endings correctly. This omission isn't surprising when you consider that ABC started off as a tool for British-Isles folk music. Thus, when I open my copy of O'Neill's 1850 at random, it takes a half dozen tries before I find a page with any first and second endings at all. You don't often need them in this tradition. But this is one of many examples of something that is required for other sorts of music. The impression that I get is that decades from now the abc standard will probably still include the above passage, and musicians will have to find other software because most abc tools are still so primitive that they can't even handle 3rd and 4th endings. I'd also observe that the term repeat in the above should be changed to ending. Repeats are something different, indicated in abc with colons. Repeats and endings are inter-related, of course, since repeats tend to have different endings. Something I've also implemented is the conventional |:: ... ::| notation that says three times through. This can be important at times, mostly if you are dealing with dance music. There are lots of traditions in which it's common to play phrases four times. When there aren't separate endings for the repeats, this is how the repeats are usually indicated. chide Maybe we could get something moving here. How many years has it been so far? /chide -- Notice: This message is copyright by the sender, and was doubly encrypted by applying the ROT13 encryption algorithm twice. Unauthorized decryption of this message within the jurisdiction of US courts by anyone other than the intended recipient(s) is a violation of the Digital Millenium Copyright Act, and in punishable by five years in jail, a $500,000 fine, or both. To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] Progress towards a new abc standard
John Chambers wrote: James Allwright wrote a week or so ago: | For those who have wondered what got discussed by the abc standards | committee, here is a summary of our discussion. The section numbers | referred to can be found at | | http://abc.sourceforge.net/standard-propose/ Y'know, I've been wondering whether anything was happening with this. Then I found that I'd been dropped from abcusers, which explained why it was sorta quiet. But in looking around, I still get the feeling that not much has happened ... Sorry about that John, your mail account on trillian.mit.edu started bouncing all mail, and I have scripting in place to remove any email addresses from the list that bounce mail for more then 3 days. Otherwise, I would spend all my free time manually unsubscribing dead email addresses. Toby To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
[abcusers] Progress towards a new abc standard
For those who have wondered what got discussed by the abc standards
committee, here is a summary of our discussion. The section numbers
referred to can be found at
http://abc.sourceforge.net/standard-propose/
James Allwright
This is a summary of the new features proposed in the new abc standard :
Section Feature Description
--- --- ---
2.1.0.3F:File name
2.1.0.3U:Macro definition
3.13.0.1
3.13.0.2
2.1.0.3w:lyrics aligned with tune
2.1.0.6K:global accidentals
2.1.0.6K:clef specifier with clef= and without
3.9.0.2
3.2.0.4//Multiple / to specify note length
3.9.0.4[]In-line fields
3.11.0.2 A{g}AGrace notes within broken rhythm
3.12.0.2 THLMPSpre-defined musical symbols
3.12.0.4 ! ! musical terms and symbols list
3.15.0.2 Accompaniment chord format
3.15.0.3/ Meaning of / within an accompaniment chord
3.15.0.4() Alternate chords
3.16.0.1 _@ Text Annotation
3.18.0.1 Q:Beat unit
Sections where the committee all agree:
3.2.0.4//
3.9.0.4[]
3.11.0.2 A{g}A
3.15.0.4()
3.16.0.1 _@
Sections needing minor modification:
2.1.0.3F:
2.1.0.3w:
2.1.0.9Note lengths
Sections needing much work:
2.1.0.3U:
3.13.0.1
3.13.0.2
2.1.0.6K: (GAs)
2.1.0.6K: (clefs)
3.9.0.2
3.12.0.2 THLMPS
3.12.0.4 ! !
3.15.0.2
3.18.0.1 Q:
To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
