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] 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
Re: [abcusers] tempo
Hello, I was out travellin for one week, and just tried to recapitulate last weeks mail exchange, and must say I cannot follow it completely. But I must add that: [EMAIL PROTECTED] wrote: On Sun, 2 Dec 2001, Laurie Griffiths wrote: Q:Allegro -- uses Allegro which must have been already defined. Does this mean that a transcriber can't specify a tempo without also defining it metronomically? I'm not sure I like the idea of *forcing* them to add information that the composer didn't provide, but I can live with it. I could *not* live with such a solution. It *must* be possible to use words for describing tempo whithout having to define them in numbers. If the words used for describing a tempo do not match any already defined string of words they simply cannot affect a programms playback (but these words will still affect the musicans playback). Simon Wascher -- 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
On Fri 07 Dec 2001 at 01:38PM +0100, Simon Wascher wrote: I could *not* live with such a solution. It *must* be possible to use words for describing tempo whithout having to define them in numbers. A man's life hangs in the balance here, depending on the finer points of abc syntax. Clearly this is important stuff. :-) James Allwright To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] tempo
James Allwright writes: | On Fri 07 Dec 2001 at 01:38PM +0100, Simon Wascher wrote: | | I could *not* live with such a solution. It *must* be possible to use | words for describing tempo whithout having to define them in numbers. | | A man's life hangs in the balance here, depending on the finer | points of abc syntax. Clearly this is important stuff. :-) Yeah; I also had the image of Simon hanging himself in response to the New! Improved! ABC standard. In any case, we might point out again that the metronome was invented around 1820, and any metronome indication for earlier music is a modern editor's addition. So if ABC requires definitions of such terms, the result will be to lock out the entire Early Music crowd, who will be forbidden to do urtext ABC transcriptions. Such a rule would also invalidate a considerable body of current ABC files. I know that abc2ps casually accepts Q:Allegro. It does seem to want the quotes; maybe I should fix that. I've seen this sort of Q line in quite a number of files. Accepting them makes a lot of sense. It's obviously a problem for a player, but no more of a problem than a tune with no Q line at all (which covers at least 90% of the ABC out there). After all, to a great many ABC users, R:reel is a perfectly good and sufficient tempo indicator. To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] tempo
Laurie's suggestion seems to take care of most of the tempoish things you'd want to ask a printing or playback program to do, except...how do you ask it *not* to print the tempo? Cheers, John Walsh To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
[abcusers] tempo
Whew! a lot of syntax... One extra thing you get in actual scores: multiple names for the same tempo, which in your notation might be Q:allegro=Tempo I so that Tempo I is defined by a double indirection, in your BNF QLine ::= Q: string = string This might also be useful in translating terms between different languages. I am not sure what your proposal does about leading and trailing spaces in tempo names. They mustn't make any difference, anyway - otherwise trying to spot why your tempo definition isn't being acted on could get impossibly difficult as these would all have different effects: Q:1/4=124=allegro Q:1/4=124=allegro Q:1/4=124 =allegro % from Hogwood's recording Q:1/4=124= allegro % from Hogwood's recording Q:1/4=124=allegro % from Hogwood's recording That is, the lines QLine ::= Q: speed = string QLine ::= Q: beat = speed = string need to use a definition of string that eliminates leading and trailing spaces. (You should still be able to surround the string with whitespace for readability). Otherwise, spot-on. === http://www.purr.demon.co.uk/jack/ === To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] tempo
On Sun, 2 Dec 2001, Laurie Griffiths wrote: Q:Allegro -- uses Allegro which must have been already defined. Does this mean that a transcriber can't specify a tempo without also defining it metronomically? I'm not sure I like the idea of *forcing* them to add information that the composer didn't provide, but I can live with it. John To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] tempo
This is an attempt to roll this up and include all the fixes suggested by others, clarifications etc. Here we go. Text to the right of and including -- is a meta-comment, that is to say it is part of this discussion and not part of the syntax in question, not even as a comment. Q:120 -- as before, backwards compatible Q:C2=120 -- as before Q:1/4=120 -- as before -- in fact ALL currently legal Q: lines are still legal and have exactly the same meaning as before. This is essential so that we do not break existing ABC. Some of these forms are still deprecated. Q:140 = sorta quickish -- Defines sorta quickish -- this can be later used as Sorta Quickish, SORTA QUICKISH, SorTa QuICKiSh and so on but NOT as sortaquickish. sortaquickish (with multiple spaces) and so on. Q:120=Allegro -- the popular example. Same idea Q:160=2fast -- ILLEGAL!! the string must not start with a number. Q:150=C2=140 -- ILLEGAL!! The string must not look like an old Q: -- otherwise Q:C2=140 is totally ambiguous. -- The restriction is that the name of the tempo must start with a letter and the next non-space character must not be a number. Q:3/8 -- defines or redefines the beat as being a dotted crotchet -- in particular if the beat was 1/4 then Q:3/8 means that 3/8 will now take the time that 1/4 used to. Q:1/4=sorta quickish -- sets the tempo to 1/4=140 (the defined meaning of sorta quickish AND defines the beat to be 1/4. Q:Allegro -- uses Allegro which must have been already defined. -- There are now to be 120 of the current beat per minute -- the next examples are to be read together: Q:120=Allegro Q:110=a bit slower Q:1/4=Allegro -- beat is 1/4 and there are 120 of them per minute Q:3/8 -- beat is 3/8 and there are 120 of *them* per minute Q:A Bit Slower -- beat is now 3/8=110 Q:3/8=140=A bit quicker -- changes beat to 140 AND defines 140 to be a bit quicker Q:1/4 -- beat is now 1/4 so now 1/4=140 Q:A bit slower -- slow down to 110 Q:A bit quicker -- speed up to 140. Note that A bit quicker means 140 - it does NOT mean 3/8=140. In fact we now have 1/4=140. Q:1/8=A bit quicker -- This is poor style because we have just dropped to half speed since now 1/8=140, so 1/4=70 and A bit quicker is a very poor description. A human reader who knows English will be upset. A computer player program won't realise what the problem is. WHAT PROGRAMS *MIGHT* DO with this. Q:120 -- print .|=120 and set the tempo appropriately (it might not be .|) -- possible warn if the beat has not been explicitly set (deprecation) Q:C2=120 -- similar, depending on how long C2 is according to L: etc. -- more possible deprecation Q:1/4=120 -- print .|=120 and set the tempo, remember beat is 1/4 Q:140 = sorta quickish -- Just remember the definition Q:120=Allegro -- Just remember the definition Q:160=2fast -- Complain! Q:3/8 -- possibly print .|=.|. or some such if the beat has changed -- adjust playback tempo if the beat has changed -- remember the beat is now 3/8 -- Exactly what a display/print program displays/prints is up to the program but note that it KNOWS WHAT THE OLD beat was and the new beat is now set. If the two are different then it should will probably show that in an appropriate style, conforming to the general style of output that it is generating. Q:1/4=sorta quickish -- print sort quickish -- set tempo to 1/4=140 -- set current beat to be 1/4. Q:1/4=100=Slower -- print Slower -- set tempo to 1/4=100 -- remember that Slower means 100 Q:Allegro -- print Allegro, set tempo to 120 of current beat per minute Naturally all the printing would probably be in the style which that program used for displaying tempi. ADVANTAGES 1. 100% compatible with all existing ABC 2. Allows definition of musical terms by people who want to do that 3. Concise syntax for setting tempo, changing tempo 4. Allows printing programs to know that this text is a tempo 5. Because name always occurs on the end of a line lots of escape questions don't arise. 6. The syntax is small, not a lot of extra stuff for something really simple and it (almost) parses left-to-right with no surprises. More formal syntax: top ::= noteletter | numerator | noteletternumerator beat ::= top [/ denominator -- e.g. beat is C or C2 or 1 or 1/4 or c3/8 rate ::= speed | string -- string must have been previously defined QLine ::= Q: beat QLine ::= Q: speed QLine ::= Q: beat = speed QLine ::= Q: speed = string -- this defines string QLine ::= Q: beat = speed = string noteletter ::= A|B|C|D|E|F|G|a|b|c|d|e|f|g -- (or L???) numerator is a natural number (a string of digits, not 0) speed is a natural number (a string of digits, not 0) denominator is a power of two 1, 2, 4, 8, 16, etc. string is a string of characters that does not include newline, which starts with a letter, is at least two characters long, and whose second non-blank character is not a number. zero or more spaces are
Re: [abcusers] tempo
Jack said ...Your suggestions have exactly the expressive power I was asking for, with one minor omission: the label dotted minim = minim you get in staff notation when the metre changes Q:1/2 -- sets the beat to minim abc abc Q:3/2 -- sets the beat to dotted minim which therefore equals the old minim (you mean 3/4) That's what I meant by saying you had the same semantics, but wouldn't that be difficult for a staff-notation generator to figure out? - the program has to look back some way to locate the RHS of the identity, and in the presence of variant repeats, the lookup would have to follow the dynamic order rather than the textual sequence even to discover whether anything needed to be printed at that point: M:2/2 Q:1/2 ... |: ... [1 [M:3/2] [Q:3/4]... :| [2 || % no metre or beat change ... [M:3/2][Q:3/4] % this *IS* a change of beat even though the % last beat assignment in the text is the same ... which is why I thought an explicit command might be easier to implement. (You could have even more fun by adding parts in different metres with a playing order in the header - there are examples of that in pibroch). If the implementors think it's not too hard, no problem. Heads-up for a special case that is going to appear eventually: someday we are going to have da capos, and if the DC is back to a different beat than the one currently in force, the change will have to be indicated at the DC mark, not at the start of the score (whereas these indications go above the first bar of the music with the new beat setting otherwise). === http://www.purr.demon.co.uk/jack/ === To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] tempo
Laurie writes: | Jack said ...Your suggestions have exactly the expressive power I was | asking for, with one minor omission: the label dotted minim = minim you | get in staff notation when the metre changes | | Q:1/2 -- sets the beat to minim | abc abc | Q:3/2 -- sets the beat to dotted minim which therefore equals the old minim Well, yes, for the purposes of software. But if this just produced the dotted minim above the staff in the printed music, few if any musicians would have even the slightest idea what was intended. If they noticed the inexplicable note above the staff, they'd mostly guess that it was some sort of printer's hiccup, since it obviously has no musical meaning. Unless, of course, the note head is too close to the staff, in which case they'd treat it as a g note (which would also obviously be a mistake after the first playing). To get it treated as anything other than a mistake, you'd have to say Q:1/2=3/2 and the displayed/printed output would have to show the two notes with the '=' in between. (And I suppose we should also state in the spec that the first length is the old beat and the second is the new, or half the people writing abc players would do it the other way 'round. ;-) To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] tempo
Not so. This is back to the question of does the notation tell the program what to print or does it describe the music. The answer is that it describes the music and software can figure out how to express that in any other medium (for instance sound waves, MIDI codes or tadpoles on 5 bar gates). I *suggest* that a good thing to print for this case would be note shape denoting old beat = note shape denoting new beat Laurie - Original Message - From: John Chambers [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, November 29, 2001 2:50 PM Subject: Re: [abcusers] tempo Laurie writes: | Jack said ...Your suggestions have exactly the expressive power I was | asking for, with one minor omission: the label dotted minim = minim you | get in staff notation when the metre changes | | Q:1/2 -- sets the beat to minim | abc abc | Q:3/2 -- sets the beat to dotted minim which therefore equals the old minim Well, yes, for the purposes of software. But if this just produced the dotted minim above the staff in the printed music, few if any musicians would have even the slightest idea what was intended. If they noticed the inexplicable note above the staff, they'd mostly guess that it was some sort of printer's hiccup, since it obviously has no musical meaning. Unless, of course, the note head is too close to the staff, in which case they'd treat it as a g note (which would also obviously be a mistake after the first playing). To get it treated as anything other than a mistake, you'd have to say Q:1/2=3/2 and the displayed/printed output would have to show the two notes with the '=' in between. (And I suppose we should also state in the spec that the first length is the old beat and the second is the new, or half the people writing abc players would do it the other way 'round. ;-) 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] tempo
I thought that the beat was a property of the static text. That is you scan left-to-right, top-to-bottom and the last beat indication that you found is the one in force. If you encounter a Da Capo or a :| or anything else it means that the player will revert to the beat that was in force at that point. Your example is vile :-) and I can argue it either way! Other implementers must comment on what might be implementable. To Muse it is no problem because Muse is inherently a two pass system. Pass 1 (on loading the file) translates to Muse internal format. Pass 2 plays it (or prints it or whatever). From what I glean of the way BarFly works this might be a problem, but Phil will have to say. (yes I meant 3/4) Laurie - Original Message - From: Jack Campin [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, November 29, 2001 2:29 PM Subject: Re: [abcusers] tempo Jack said ...Your suggestions have exactly the expressive power I was asking for, with one minor omission: the label dotted minim = minim you get in staff notation when the metre changes Q:1/2 -- sets the beat to minim abc abc Q:3/2 -- sets the beat to dotted minim which therefore equals the old minim (you mean 3/4) That's what I meant by saying you had the same semantics, but wouldn't that be difficult for a staff-notation generator to figure out? - the program has to look back some way to locate the RHS of the identity, and in the presence of variant repeats, the lookup would have to follow the dynamic order rather than the textual sequence even to discover whether anything needed to be printed at that point: M:2/2 Q:1/2 ... |: ... [1 [M:3/2] [Q:3/4]... :| [2 || % no metre or beat change ... [M:3/2][Q:3/4] % this *IS* a change of beat even though the % last beat assignment in the text is the same ... which is why I thought an explicit command might be easier to implement. (You could have even more fun by adding parts in different metres with a playing order in the header - there are examples of that in pibroch). If the implementors think it's not too hard, no problem. Heads-up for a special case that is going to appear eventually: someday we are going to have da capos, and if the DC is back to a different beat than the one currently in force, the change will have to be indicated at the DC mark, not at the start of the score (whereas these indications go above the first bar of the music with the new beat setting otherwise). === http://www.purr.demon.co.uk/jack/ === 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] tempo
On Thu 29 Nov 2001 at 10:40AM -, Laurie Griffiths wrote: Not so. This is back to the question of does the notation tell the program what to print or does it describe the music. The answer is that it describes the music and software can figure out how to express that in any other medium (for instance sound waves, MIDI codes or tadpoles on 5 bar gates). I *suggest* that a good thing to print for this case would be note shape denoting old beat = note shape denoting new beat If you want to do this sort of thing, my suggestion (based on personal taste rather than historical precedent) would be to use an arrow rather than an equals sign in the printed output. Using an equals sign to indicate a change only really makes sense if you are a programmer (but not a Pascal programmer). I can't recall actually having seen this notation used. Morris tunes frequently have slows, where a passage is played at half speed and this is normally notated by using notes of double the length. James Allwright To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] tempo miscellanea
At 23:47 2001/11/27 +, Jack Campin wrote: : So, *how* does it describe the speed? How does your suggestion : distinguish texts that define speeds from arbitrary gibberish? : It doesn't, at least it doesn't any more than a program can : distinguish between the actual title of the tune in the title field and : arbitrary gibberish. I don't see a standard (as in ABC standard) way : of being able to check this field without severely limiting the text : that can be put in here I suggested a way: sdbdkjvhfdb defines a tempo if there's a tempo definition in the environment, i.e. a line like Q:[3/4] sdbdkjvhfdb 1/4=96 It seems as though the principle sticking point here is whether the association of a tempo with an arbitrary text string should go in the ABC file or be separate. I guess that this depends on whether it would make more sense to have tempos defined on a 'per file' or 'per user' basis. : Any syntax that works in an external file can work in an ABC tune : file. : I don't think I understand what you're talking about here. Do you : mean that any external file that any program decides to use should : be capable of being put into an ABC file? I mean that if the external file syntax is sanely designed we can add the design to the syntax of ABC. As it stands, it seems that externality is being used as an excuse for using any old rubbish as notation - on the assumption that only one program will ever use it and hence that only one programmer needs to care how twisted it is. There are enough historical precedents now to say how dangerous an attitude that is in the long term. Whilst I agree that would could add sanely designed external file syntax to ABC I'm not sure we'd want to. I can't speak for anyone else, but my reason for wanting to put things into external files is to try and get a good split between things that belong in ABC as part of the representation of the music, and things that are 'presentation options' that can live elsewhere. My preference would be for ABC to be as small as possible, but no smaller. Bob -- -- Bob Archer [EMAIL PROTECTED] To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] tempo
(I think that you meant dotted quarter a few places where you said dotted eighth; 3/8 is dotted 1/4) My intention was that in your example: M:2/4 Q:1/4=120 -- program probably displays 1/4 note symbol=120 ... M:6/8 Q:3/8 -- program probably displays 3/8note symbol=1/4 note symbol but I think I get implicitly from John that this is not intuitive (it seemed fine to me!) and that what people will want to write is 3/8=1/4, or should that be 1/4=3/8. I don't like that just because I have no feeling for which way round it should be! Q:3/8 says that a beat is a 3/8 note and that in the absence of any other indication the metronome (or the conductor's baton or the drummer's foot) is to carry on at the same rate as before. Laurie - Original Message - From: John Chambers [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, November 29, 2001 9:50 PM Subject: Re: [abcusers] tempo OK, but one question is: Suppose a program sees: M:2/4 Q:1/4=120 ... M:6/8 Q:3/8 With just this information, should the second be displayed as a dotted eighths note, or as quarter = dotted eighths? This might not have been at all what was intended. The intent could have been to switch to 6/8 but not specify a tempo. I can see this leading to a lot of confusion and wildly different implementations. This is personally mostly an intellectual interest point; I don't really see myself using this much, since I rarely feed ABC to players. But this could easily lead to bad ABC on my part. If I were transcribing some printed music and saw a tempo indication such as 1/4=3/8 (as notes of course), I'd probably do my best to translate this to a Q line. But I'd probably get it wrong, since I wouldn't be a regular user of this feature. This is similar to all the extant ABC that has wildly incorrect tempos in the current notation. In any case, I'd prefer that the software just do what I type, and not try to outsmart me. If I write Q:1/4=3/8, I'd hope the obvious two notes and '=' would be displayed. If I write only Q:3/8, I'd hope that only a dotted eighths note would be displayed, despite its obvious lack of meaning to me and most other musicians. It does occur to me that if the software will just blindly put out the contents of the Q line with fractions converted to notes, it would work to notate the conventional Balkan rhythm notations: Q: 4/8 3/8 4/8=70 Let's see if it works with abc2ps ... ... Nope. But I spent about 20 minutes looking at the write_tempo() routine, and I figured out why it failed. It was just a missing test of the return value of sscanf(). It's fixed now, and looks real pretty. Since my clone (jcabc2ps) is what my Tune Finder uses, I can now use this notation on the Web and Balkan musicians will get the notation that they expect. I think I'll now go off and add this to all the irregular tunes in my .../Intl/ directory. Any other Balkan musicians out there who think this would be a useful thing to somehow get into the ABC standard? Or maybe we should just say Hey, it's not a violation of the current standard; it's just an undocumented case which obviously oughta work. It is standard music notation, after all. (I'm glad you encouraged me to look into this. ;-) Laurie writes: | This is back to the question of does the notation tell the program what to | print or does it describe the music. The answer is that it describes the | music and software can figure out how to express that in any other medium | (for instance sound waves, MIDI codes or tadpoles on 5 bar gates). I | *suggest* that a good thing to print for this case would be | note shape denoting old beat = note shape denoting new beat | ... I wrote: | To get it treated as anything other than a mistake, you'd have to say | Q:1/2=3/2 and the displayed/printed output would have to show the two | notes with the '=' in between. (And I suppose we should also state in | the spec that the first length is the old beat and the second is the | new, or half the people writing abc players would do it the other way | 'round. ;-) 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] tempo miscellanea
On Tue, 27 Nov 2001, Jack Campin wrote: + in every printed score I own, the tempo text, expression text, and + guitar chords are distinguishable from one another by their typeface + alone. But they aren't *identifiable* by their typeface alone - no two publishers use the same set of conventions. That doesn't matter. The point is, distinguishing between different kinds of text *in some way* is beneficial to the performer. Performers who are used to reading music will take this convention for granted. In any case, is merely being able to implicitly specify a different typeface for tempo indications a feature worth the bother of implementing? This is not a matter of merely changing typeface. I was adding just one example to many other good points. There are other benefits to specifying a context for text information. Sorting, filtering, and extracting information based on context would be useful. I regularly do this kind of thing, for instance to extract just the titles and words from a large collection of tunes. This would not be possible if lyrics were written _like _this. John To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] tempo
I would like to propose the following. I will give the syntax first as examples with explanations and then some more formal stuff to try to eliminate ambiguities and assist implementation. Text to the right of and including -- is a meta-comment, that is to say it is part of this discussion and not part of the syntax in question, not even as a comment. Q:120 -- as before, backwards compatible Q:C2=120 -- as before Q:1/4=120 -- as before -- in fact ALL currently legal Q: lines are still legal and have exactly the same meaning as before. This is essential so that we do not break existing ABC. Some of these forms are still deprecated. Q:140 = sorta quickish -- Defines sorta quickish -- this can be later used as Sorta Quickish, SORTA QUICKISH, SorTa QuICKiSh and so on but NOT as sortaquickish. sortaquickish (with mulktiple spaces) and so on. Q:120=Allegro -- the popular example. Same idea Q:160=2fast -- ILLEGAL!! the string must not start with a number. Q:3/8 -- defines or redefines the beat as being a dotted crotchet -- in particular if the beat was 1/4 then Q:3/8 means that 3/8 will now take the time that 1/4 used to. Q:1/4=sorta quickish -- sets the tempo to 1/4=140 AND defines the beat to be 1/4. Q:Allegro -- uses Allegro which must have been already defined. -- There are now to be 120 of the current beat per minute -- the next examples are to be read together: Q:120=Allegro Q:110=a bit slower Q:1/4=Allegro -- beat is 1/4 and there are 120 of them per minute Q:3/8 -- beat is 3/8 and there are 120 of *them* per minute Q:A Bit Slower -- beat is now 3/8=110 WHAT PROGRAMS *MIGHT* DO with this. Q:120 -- print .|=120 and set the tempo appropriately (it might not be .|) Q:C2=120 -- similar, depending on how long C2 is according to L: etc. Q:1/4=120 -- print .|=120 and set the tempo, remember beat is 1/4 Q:140 = sorta quickish -- Remember the definition Q:120=Allegro -- Remember the definition Q:160=2fast -- Complain! Q:3/8 -- possibly print .|=.|. or some such if the beat has changed -- adjust playback tempo if the beat has changed -- remember the beat is now 3/8 Q:1/4=sorta quickish -- print sort quickish -- set tempo to 1/4=140 -- set current beat to be 1/4. Q:Allegro -- print Allegro, set tempo to 120 of current beat per minute Naturally all the printing would probably be in the style which that program used for displaying tempi. ADVANTAGES 1. 100% compatible with all existing ABC 2. Allows definition of musical terms by people who want to do that 3. Concise syntax for setting tempo, changing tempo 4. Allows printing programs to know that this text is a tempo 5. Because name always occurs on the end of a line lots of escape questions don't arise. There are two restrictions to be lived with - tempo names must not start with a number and they must have more than one character. 6. The syntax is small, not a lot of extra stuff for something really simple and it (almost) parses left-to-right with no surprises. More formal syntax: A QLine ::= Q: number B QLine ::= Q: letter = speed C QLine ::= Q: letternum = speed D QLine ::= Q: letter/[denom] = speed E QLine ::= Q: letter/ = speed F QLine ::= Q: letternum/denom = speed G QLine ::= Q: num / denom = speed H Line ::= Q: num / denom = name I QLine ::= Q: num / denom J QLine ::= Q: num = name K QLine ::= Q: name num (the numerator), denom (the denominator) and speed (the speed) are all unsigned integers, i.e. strings of digits. zero or more spaces are allowed wherever I have shown a space. Discussion (though by now I think you've got it!) A Q:120 -- old style, possibly no longer deprecated (see below) B Q:C=120 -- old style, deprecated C Q:L3=90 -- old style, deprecated D Q:C/4=480 -- old style, deprecated E Q:C/=240 -- old style, deprecated F Q:C3/8=120 -- old style, deprecated (the C is needless) G Q:3/8=120 -- valid, current style H Q:3/8=Allegro -- new, uses Allegro (must be defined) I Q:3/8 -- new, defines or redefines the current beat J Q:120=Allegro -- new, defines (or redefines) Allegro K Q:Allegro -- new, sets current beat to Allegro A and K are in effect the same thing. The old Q:120 becomes rehabilitated if there has been a preceding Q:1/4 or Q:1/4=220 to define the beat. Q:Allegro WITHOUT any previous setting of the beat has to be deprecated because it is as peculiar as the old Q:120 was, so the first tempo setting for a tune should use form G or H. After that forms I or K can be convenient shorthand if the time signature or feel of the piece changes or the tempo changes. Almost none of this is new. I'd like us to get to a vote, and fairly soon. Laurie To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] tempo
Laurie writes: | I would like to propose the following. ... ... | Q:1/4=120 -- as before | -- in fact ALL currently legal Q: lines are still legal and have exactly the | same meaning as before. ... | Q:120=Allegro -- the popular example. Same idea One thing I didn't see in the examples is whether combining these would be legal, as in: Q:1/4=120=Allegro It seems that this should obviously be allowed. Then there's the question about the syntax that some programs accept now: Q:1/4=120 Allegro' Would this mean the same thing? Or would it just cause the Allegro to be displayed but not define it as 120? This does seem reasonable, with the idea that = is used in definitions, but it should probably be stated. Myself, I don't think I'd make too much use of the partial forms. I keep finding that it's more useful to over-specify such things, since it doesn't take very many bytes. Thus, I always include M and L lines, even when I know the defaults are correct. There's a lot of abc software around whose authors had better ideas than following the standard (such as it is). And I can see a lengthy ABC file's tempos getting to the state that a reader would have to do careful backwards study to determine what was intended at some particular point. To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] tempo
Laurie wrote: I would like to propose the following. [suggestions I have hardly any problems with, except...] Q:C2=120 -- as before Do we really need this? Did it ever catch on? (I think you suggest deprecating it, I reckon something more drastic might be in order). Q:120=Allegro -- the popular example. Same idea Nothing else in ABC uses postfix definition, and it's pretty strange for most people to figure out and perhaps even stranger if you consider an audience of programmers instead of people... I guess you're doing it this way for easy parsing where the term might have spaces? I think I'd leave the = sign out if it's going to be in this order, or use =: or *something* to indicate that I'm not really trying to redefine the number 120. Your suggestions have exactly the expressive power I was asking for, with one minor omission: the label dotted minim = minim you get in staff notation when the metre changes. There seems to be nothing in your proposals that could trigger the printing of such a thing in the staff notation, even though the semantic effect is there. Can you see a way to fix this? Q:Allegro WITHOUT any previous setting of the beat has to be deprecated because it is as peculiar as the old Q:120 was We could be a bit more relaxed about this - a program that only needs to print could accept it. Anybody who put a tune like that on the web could then officially be told they'd be fielding emails saying what metronome speed did you have in mind? till hell freezes over, though... But basically I like this set of proposals and could live with it. - Jack Campin * 11 Third Street, Newtongrange, Midlothian EH22 4PU, Scotland tel 0131 660 4760 * fax 0870 055 4975 * http://www.purr.demon.co.uk/jack/ food intolerance data recipes, freeware Mac logic fonts, and Scottish music To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] tempo
Jack said ...Your suggestions have exactly the expressive power I was asking for, with one minor omission: the label dotted minim = minim you get in staff notation when the metre changes Q:1/2 -- sets the beat to minim abc abc Q:3/2 -- sets the beat to dotted minim which therefore equals the old minim To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] tempo
John Chambers wrote: One thing I didn't see in the examples is whether combining these would be legal, as in: Q:1/4=120=Allegro It seems that this should obviously be allowed. Then there's the question about the syntax that some programs accept now: It wasn't, but I agree it should be. Consider it adopted into the proposal. As for Q:1/4=120 Allegro Clearly the quotes are superfluous but I would be happy to include Q:1/4=120 Allegro which means the tempo is 1/4=120 and it's called 'Allegro' . Laurie To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
[abcusers] tempo miscellanea
Chord notation is not free text. It is a chord. There may be no restriction to the syntax of a chord to be presented, but semantically, it's a chord. And for some playback programs (Muse is one, I think) chord semantics is both precisely defined and used by the interpreter; Laurie suggested standardizing it a while back and nobody seemed to have much problem with what he suggested (where there are idioms with different conventions, this is another place where a definition mechanism could be used). A tool that created ABC piano scores from guitar-style notation (are there any?) would need the same semantics, i.e. this isn't just about playback. Likewise, tempo indicators are not free text. They are tempo indicators. There may be no restriction to the syntax of a tempo indication, but semantically, it's a tempo indicator. Semantics is about giving expressions *values*. It's a feeble sense of the word that ignores that. An indication that doesn't have a value and can't be given one doesn't have a semantics the way I see it. _Excitedly and _Placidly are not tempo indicators. They may print out in tadpoles as tempo indicators, but they will not be read by human readers of the ABC notation, nor by playback programs, as tempo indicators. They fit just fine into the remit of the R: field, though. It wouldn't hurt a bit if we made finer distinctions than staff notation does over this one. (Icky example from a 19th century edition I've got: finale of Beethoven's string quartet op18 no6, La Malinconia Adagio all in the same font used for tempi elsewhere - since when was La Malinconia a tempo?) : So, *how* does it describe the speed? How does your suggestion : distinguish texts that define speeds from arbitrary gibberish? : It doesn't, at least it doesn't any more than a program can : distinguish between the actual title of the tune in the title field and : arbitrary gibberish. I don't see a standard (as in ABC standard) way : of being able to check this field without severely limiting the text : that can be put in here I suggested a way: sdbdkjvhfdb defines a tempo if there's a tempo definition in the environment, i.e. a line like Q:[3/4] sdbdkjvhfdb 1/4=96 : Any syntax that works in an external file can work in an ABC tune : file. : I don't think I understand what you're talking about here. Do you : mean that any external file that any program decides to use should : be capable of being put into an ABC file? I mean that if the external file syntax is sanely designed we can add the design to the syntax of ABC. As it stands, it seems that externality is being used as an excuse for using any old rubbish as notation - on the assumption that only one program will ever use it and hence that only one programmer needs to care how twisted it is. There are enough historical precedents now to say how dangerous an attitude that is in the long term. : What happens if you put a q: field into a tune and feed it to : abc2win? (If it breaks, there's no advantage over altering the : syntax for Q:). : And again, this illustrates the need for some sort of namespacing : to allow us to add features to the standard without breaking : backwards compatibility, and also to allow program specific : extensions. In future, yes, but for this specific case, if abc2win behaves as I'm guessing it might, there is *no* way forward without letting people create ABC files it can't handle. So we might as well redefine the existing field's syntax and save q: for something else later on. Once we get all commonly used programs doing the silent-acceptance thing, we can follow the line you're advocating. ] how does abc distinguish between `arbitrary gibberish' and music in ] general? The way it currently interprets the note A. The only way it can assign a duration to that is by looking up an L: field (or inferring one from an M: field) and the only way it can assign a definite pitch to it is by looking at the K: field. I'm suggesting tempo should be a matter for another environment lookup, but a nonlocal one to an extent that the standard already permits for M: and L:. It *might* be okay to relax things so that files didn't need to define all the tempi they use; that would not be portable, but it would be portable among display-only programs, and there aren't so many tempi in any one source that adding the definitions would be a great hassle for people using the same files for purposes like playback or the computation of overall timings. (I was talking about proposals for definitions of tempo by formalisms confined to external files...) ] Which has what syntax? ] field namecolontext ] examples: ] q:gayment ] q:allegro con moto That's not what I was I was asking for. That's *use*, I was talking about *definition*. How would you define allegro con moto in an external file? Why does doing so make the syntactic problem any easier? + in every printed score I own, the tempo text, expression
Re: [abcusers] Tempo indicators
Largo is slower than Lento. Odd because Lento actually means Slow so you'd think that would be the one, whereas Largo means broad. I do not know whether Largo/Lento and Presto/Veloce are equivalent pairs or not. There were also some German terms given which were a small subset of the Italian ones. To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] Tempo indicators
James == James Allwright [EMAIL PROTECTED] writes: James 1. Musical terms would be better put in a new field (I think q: has been James suggested) than added to the existing Q: field. Possibly N: would be James acceptable. No, it wouldn't. N: is used for notes. I use it for describing differences between my transcription and the original I was transcribing from. Some printing programs have a style for printing it, which can be modified from the command line, and which is suitable for annotations of a transcription, but not for printing tempo indications. It certainly shouldn't be co-opted for anything to do with playback. -- Laura (mailto:[EMAIL PROTECTED] , http://www.laymusic.org/ ) (617) 661-8097 fax: (801) 365-6574 233 Broadway, Cambridge, MA 02139 To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] tempo defaults
Frank Nordberg [EMAIL PROTECTED] wrote : [EMAIL PROTECTED] wrote: I am new to this stuff but am really intrigued. I have the abc2win and have been having problems with the quickplay playing tunes at Q:443 if there is no specified tempo in the file. Is there a way to change the default? Cindy Welcome to the abcusers community, Cindy :) I have no idea how to change the defaults of abc2win, but unless you're working on a large number of tunes, it shouldn't be too hard to add a Q: line to each tune. Not the best answer, I know, but since it seems nobody who actually knows that program is going to answer, it'll have to do. Although I'm a heavy abc2Win user I thought about, but then didn't answer the question, mainly because I was unable to reproduce the original problem. Q:443? Blimey, (nearly) everyone would complain that *that* was playing reels too fast :-) The best thing to do, as Frank says, is to add a definite value to the Q: field of every tune. To then avoid being emailed (quite rudely sometimes it must be said!!) by people who download your file and want to use it in other abc playback software you might well be advised to use the full Q: syntax of note value = tempo eg Q:1/8=120 [ or, to be specific to abc2Win, you'd enter 1/8=120 into the Q: field on the tune input form ]. OK? Steve Mansfield [EMAIL PROTECTED] http://www.lesession.demon.co.uk - abc music notation tutorial and other goodies To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] tempo defaults
I am new to this stuff but am really intrigued. I have the abc2win and have been having problems with the quickplay playing tunes at Q:443 if there is no specified tempo in the file. Is there a way to change the default? I have no idea how to change the defaults of abc2win, but unless you're working on a large number of tunes, it shouldn't be too hard to add a Q: line to each tune. Not the best answer, I know, but since it seems nobody who actually knows that program is going to answer, it'll have to do. ?? The default tempo for playback is based on the rhythm. For reels it is 224. The player tempo can be adjusted during play by using the + and - keys. The player is only intended to offer a way to listen to a tune to check it's notation. For years I have been recommending abcmus or abcplay for playback. These actually use your sound card and have a windows interface.. The Q: line is the easiest way to specify a tempo. The command line interface in playqabc is full-featured but you need some comfort with the DOS command line. By typing playqabc /? you will see a full list of commands that are accepted by the program. If you play a file, you may select tunes, set tempos for each and number of repeats. If you need additional information, please write directly to me. Jim Vint ___ ABC2Win Shareware -- www.abc2win.com/ Co. Clare Comhaltas www.c7r.com/cce/ Clare Music Archive www.c7r.com/archive/ Fleadh Nua 24-28 May '01 www.fleadhnua.com/ Irish Set Dancing -- www.c7r.com/setdance/ To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] tempo defaults
[EMAIL PROTECTED] wrote: I am new to this stuff but am really intrigued. I have the abc2win and have been having problems with the quickplay playing tunes at Q:443 if there is no specified tempo in the file. Is there a way to change the default? Cindy Welcome to the abcusers community, Cindy :) I have no idea how to change the defaults of abc2win, but unless you're working on a large number of tunes, it shouldn't be too hard to add a Q: line to each tune. Not the best answer, I know, but since it seems nobody who actually knows that program is going to answer, it'll have to do. I'm not an abc2win user either, but if it follows the abc 1.6 standard, you should be able to change the default just by adding a single Q: field at the very top of the file. Open the abc file with a text editor and enter Q:300 (or whatever you want as the default) on the first line of the file. Phil Taylor To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
