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 [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 [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 [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
