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] tempo
I've been off sailing. Let me try (below) to clear up the tempo thread for the last week. Do we have a concensus? Can we adopt this yet? Laurie Jack Campin: One extra thing you get in actual scores: multiple names for the same tempo, which in your notation might be Q:allegro=Tempo I Laurie: I am not in favour of this. The more levels of indirection the trickier it is to follow what's intended. So you'd have to do a little more writing. For instance: Q:120=allegro Q:120=Tempo I Jack Campin: I am not sure what your proposal does about leading and trailing spaces in tempo names Laurie: You can put leading and/or trailing spaces where you define them or use them but they are not part of the name. Thus: (the trailing spaces are not so obvious) Q:120= Allegro Q:145 =a little too fast Q:allegro Q:A little too fast is legal, but Q: a little too fast would not be recognised as the same. (That's should simplify implementation). John (jhoerr) Does this mean that a transcriber can't specify a tempo without also defining it metronomically? Laurie: That depends on the program. For a player program one might get a warning to the effect that it is going to play it at a default tempo because it doesn't understand the given tempo. For a printing-only program one might get no complaint. From a syntax checker one probably should get a warning. John Walsh: how do you ask it *not* to print the tempo? Laurie: That's a program dependent thing. The ABC defines what the music means, not what a program is to do with it. Obvious possibilities include: %%nifty NO_TEMPO_PRINTING Q:Allegro C: Nifty MyTune.abc /NewStandard /NoTempoPrinting Bring down Options menu then Printing then ABC then Tempo and remove the checkmark. Simon Wascher: It *must* be possible to use words for describing tempo whithout having to define them in numbers. Laurie: Same as jhoerr's objection. A player program *must* either guess or give up in these circumstances and *may* choose to warn/complain/throw a fit. A non-playing program may be quite happy. (Please don't kill yourself!) 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] Sharps 'n flats
They are absolute. Thus, no matter what key you are in, _e means E flat. - Eric -Original Message- From: Erik Ronström [mailto:[EMAIL PROTECTED]] What the accidentals =, ^, _ mean? Are they absolute (e g _e means e flat) or are they in relation to the key (e g =e means e flat in Bb major)? 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] tempo
I feel these suggestions are making it complicated. I would like to follow the engineering maxim of Keep It Simple (yes, I know there's normally another S on the end and I know what it stands for but I don't want to insult anyone). - Original Message - From: Buddha Buck [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Saturday, December 08, 2001 5:30 PM Subject: Re: [abcusers] tempo Laurie Griffiths [EMAIL PROTECTED] writes: I've been off sailing. Let me try (below) to clear up the tempo thread for the last week. Do we have a concensus? Can we adopt this yet? Laurie Jack Campin: One extra thing you get in actual scores: multiple names for the same tempo, which in your notation might be Q:allegro=Tempo I Laurie: I am not in favour of this. The more levels of indirection the trickier it is to follow what's intended. So you'd have to do a little more writing. For instance: Q:120=allegro Q:120=Tempo I That's not always good enough... Imagine something like: X:1 % Arbeau didn't give any tempo indicators. However, Pavanes are processionals Q:processional ... X:2 % This is an Italian 15th Century Balli. I need to document it as having a % Bassa Danza tempo, because that's what the period source material said. % That's a processional pace Q:processional=Bassa Danza Q:Bassa Danza ... Then, when I play it back, I tell my player that processional tempo is 60bpm, and both the pavane and the balli are played at the correct speed. If my dancers complain that that's too slow, no problem, just adjust processional to 70bpm, 80 bpm, etc, and all is right again. John (jhoerr) Does this mean that a transcriber can't specify a tempo without also defining it metronomically? Laurie: That depends on the program. For a player program one might get a warning to the effect that it is going to play it at a default tempo because it doesn't understand the given tempo. For a printing-only program one might get no complaint. From a syntax checker one probably should get a warning. At most a warning, in my opinion. I'd even suggest that the warning should be very low-level, or only available as an option. I sort of like the idea of playback hints, or a way of clarifying, within the notation, what is meant if the player doesn't know itself. Assuming a q: field for tempo hints, I would see it being interpreted as If no Q: field exists, use the default tempo for playback. If a Q: field exists, use it for the tempo. If the program does not understand the value for the Q: field, look for a q: field. If no q: field exists, use the default tempo, optionally generating a warning. If a q: field exists, use it's value for the tempo. If the q: field exists and the player does not understand it's value, generate an error. When displaying a tempo, use the value of the Q: field, if one exists. Along those lines, the Bassadanza example I gave above would simply use Q: Bassa Danza q: processional If the program knew how to play Bassa Danza's, it would do that, otherwise, it would play it as a processional. -- 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 To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
