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] Re: File-global header fields (R, M)
Hear, Hear! File-global header symbols are a minor convenience in that they save some typing if you have a large collection of say, 6/8 Jigs. They also make certain things possible to express that cannot be done reasonably any other way. I have beside me a book of Galician folksongs, Daniel Gonzalez's Asi Canta Galicia (1963). Most of the tempi are given in Italian, with no numerical equivalent. What speed is andantino as used by a Spanish folklorist in the Sixties? I've no idea; I could look it up, but why should I do so before I start transcribing? What speed is implied by aire de muineira, one of the non-Italian ones? Not a clue. But if I had redefinable file-global tempi I could still transcribe these pieces, knowing that I could *later* consult the New Grove or someone with specific knowledge and insert the correct definition. I have a bunch of files like this already, with tempi using the syntax I suggested. BarFly can't process them unless I comment the textual tempi out. But there is no way in hell I am going to post them on the web, ever, with my guess at the numerical values fixed per-tune; that would be utterly irresponsible stupidity, as bad as the abc2win tempo fuckup. Another example: ornamentation, as BarFly does it by macros. There are some ornament signs which are essentially style-dependent, and for that matter instrument-dependent. If you want to hear what a piece written for flute with trills might sound like on the harp, you had better redefine those trills to be no-ops, because the result would otherwise both be unplayable and sound hellacious. For the Highland pipes, there are tunes which have been played for 150 years or so with the ornaments getting steadily more complicated as players get more virtuosic. The natural way to write this in ABC is to have the ornament given as a macro defined at the start of the file or in an external file: that way you take a single tune and get 19th or 20th century versions of it just by changing one line. Editing pipe ornamentation in ABC is not easy, and any sort of abstraction mechanism will cut the workload by a substantial factor. It means you can't take a large collection and turn it into a ZIP archive, one member per tune, There are collections already that you can't do this with, simply because you won't have a clue how to use the music without the textual commentary provided by the file. Look at the George Skene pipe tunes on my website. Some are gibberish if you don't know their background. (I've had more emails about those than every other tune on my site put together; they're getting careful and informed attention by people who want to use them for real). or store an arbitrarily large collection of tunes in a relational database, etc., etc. Twaddle. Add a few extra fields to represent the values inherited from the environment and, to be on the safe side, another one identifying the file (or other environment) the tune was extracted from. It takes a certain amount of pre-processing to get that information (something you could write in Awk or Perl in an afternoon if you're halfway competent with either) but *storing* it is no problem at all for the relational model. In fact the relational model is specifically designed to avoid update anomalies of the sort I was talking about, and the reasoning behind my proposal is absolutely standard in data modelling. *Not* doing some such normalization in a relational design for a tune database would be laughable - what do you think higher normal forms are for? Is 1NF as far as you think? Do you even know the difference between a relational database and a personal computer address book? Adopting James' proposal represents a significant gain at a trivial cost. A simple one-pass conversion tool could be provided to read in any valid existing ABC file and spit out a copy, with all the global fields properly distributed to each individual tune which lacked them. Since it would only alter tunes lacking the global fields, such a tool is always safe to run, even on input already converted. It's safe except that it loses global redefinability, which is the point of using the more interesting global fields in the first place. There might be times when such a tool could be useful - e.g. when adapting well-structured ABC files to a crippled or legacy implementation - but for most purposes it would be better inside the ABC interpreter. (For macros, BarFly already provides this as a source-to-source utility, as well as an internal function). In these days of cut and paste, the saved typing convenience is inconsequential. If you've looked at any of the ABC I've written you should see instantly that typing convenience is *not* something I concern myself with. Some of that stuff must be among the slowest-entered ABC on the web. A fast 6/8 Jig should not become a slow 3/4 March just because you re-organize how you store your tunes. And *how* fast is a jig,
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
[abcusers] a partial solution to the tempo definition problem by macros
BarFly's macro mechanism provides part of what I need. I can define two separate macro files, each defining a q macro, one containing the line: m: q con moto = [Q:1/4=120] and the other: m: q con moto = ^Con Moto and then use the definition in a tune file like this: X:1 T:test M:C L:1/4 K:C q con moto cdec|] which when I get the program to expand macros, becomes X:1 T:test M:C L:1/4 K:C [Q:1/4=120] cdec|] for playback if I choose the first macro file or X:1 T:test M:C L:1/4 K:C ^Con Moto cdec|] for printing if I choose the second macro file. The problems with that are: - it's a hack - there's no syntax identifying the macros as tempo constructs - I can't put the required macros at the top of the file (I don't understand this, it works for other macros as in Phil's Goldberg Variations example) - they have to be in a separate file - there's nothing like a #include construct to link a file to the macros it needs - the linkage has to be done through application preferences - I can only use this in tune bodies since macros don't work in headers (not much of a problem for me, maybe would be for other people) - it would be much nicer if BarFly never printed numerical tempi in the first place; that way I could get away with just one macro file - I'd hate to ask anybody else to do it. But I'd *much* rather insist on people going through those hoops, and additionally restrict them to using software that can handle Barfly- style macros, than hardwire my interpretive guesses till the end of time. So, in the absence of any discernible progress, I think I'll just start doing it, and put a pair of suitable macro files on my website that you will have to use to make sense of anything I upload from now on. Note, this mechanism subsumes the suggestions made for constructs that would put the tempo indication in a distinctive typeface, because the quoted-string mechanisms of programs that allow multiple typefaces can be invoked by whatever I put on the RHS of a macro definition. === http://www.purr.demon.co.uk/jack/ === To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
