[abcusers] Re: File-global header fields (R, M)
James Allwright wrote (regarding file-global header fields like R: and M:) This is not a widely implemented feature of the abc standard and I would personally like it to become deprecated. My reasoning is that if you have global fields, you can't treat a single abc tune as something that can be edited out of its source file (which you might do if you wanted to print off just one tune from a collection). 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. But as James noted, they make it impossible to operate on one or more individual tunes without reading and parsing through the ABC file from beginning to each particular tune of interest. This means you can't just grab a specific tune out of a file and paste it in a E-mail message with confidence it will be correctly printed/played by the recipient. It means you can't take a large collection and turn it into a ZIP archive, one member per tune, or store an arbitrarily large collection of tunes in a relational database, etc., etc. 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. In these days of cut and paste, the saved typing convenience is inconsequential. A fast 6/8 Jig should not become a slow 3/4 March just because you re-organize how you store your tunes. Naturally, the same argument applies to any other file-global operators various implementors may have added through special comments like '%MIDI'. Alan S. Watt [EMAIL PROTECTED] 770-469-7544 (USA) [Voice/FAX] http://www.mindspring.com/~alan.watt To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] a request to developers
On Wed, 28 Nov 2001, Jack Campin wrote: I am about to release a CD-ROM with a large number of very carefully edited and documented tunes linked off a hypertext commentary (see http://www.purr.demon.co.uk/embro/). This is the work which all the ABC on my website is spinoffs from. I would like to include a choice of ABC applications along with it. Would any developers out there (other than the ones I've already contacted) like to get a copy, try it out, and report major incompatibilities? Have you got any Linux-based testers ? If not, I'd be happy to see what I can do. -- Richard Robinson The whole plan hinged upon the natural curiosity of potatoes - S. Lem To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
[abcusers] Open Source Project?
This is NOT directly ABC related, so you might call it Spam. If so, I apologise. I will try not to do it often! Taking some of Laura's pleas to heart I want to experiment with Open Source. I'm not prepared to risk the source code of Muse in this way at present, but I am working on another music related project. This is a Music Analyser. Currently it works on PCM encoded WAV files on PCs running 32 bit Windows systems only. It can already * play the music at any speed (musicians are usually interested in slowing it down), * FFT it and display the spectrum with peaks labelled in musical terms, * guess at the exact tuning and key (e.g. key of A 17 cents flat), * filter the sound, * try a couple of non-FFT ways of getting exact pitches from short notes (i.e. only a few cycles), * display the waveform which you can scroll and zoom in various ways, * display a piano keyboard with the active notes highlighted * (almost) make good voiceprints. Possible enhancements are almost boundless. Some of the more obvious ones are on the input side to work from mp3 or CD, on the processing side to make more use of stereo channels, play reference tones for comparison, automatic feature detection, better phase matching in the play slowly code, noise cleanup, speed change with pitch-shift by re-sampling (e.g. to alter the tuning), guessing the mode or scale in use, guessing the rhythm, converting underlying note lengths to musical terms, identifying and ignoring overtones in the spectrum, analysis of vibrato,... it's endless! The code is multi-threaded: Highest: real-time code to play the sound Above normal: filtering when the sound is playing Normal: UI stuff Below normal: long operations, FFT, spectrum, voiceprint etc. Lowest: filtering (in advance) when the sound is not playing The question is, on what terms should the source be opened? Here is what I have in mind. 1. Developers undertake not to market a competing product (whether free or for money) and will not incorporate any of the code into a competing product. 2. Developers may make any use of the source code for their private use. 3. Enhancements should be incorporated back into the main product base. Developers undertake that any contributions they make are free of any legal entanglements (i.e. they own the copyright, they give a non-exclusive free licence to the project and they know of no patent infringements). 4. Developers should receive a share of any profits. Formula yet to be worked out, but don't start thinking greedy thoughts. That probably means irregular pocket money not wages! If any developer is interested, initially I suggest that they email me off-list. Unless they say not to, I would distribute their emails to others who reply (but not to the ABC list). Feel free to distribute this further if you know anyone who might be interested. Laurie Griffiths http://www.musements.co.uk/muse where you will find music notation software for PCs. 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
[abcusers] request for info
One or two abc files I have downloaded recently have a lower case m: field, as in m: Tn = (3n/o/n/ Can you tell me what this means please? Ray Davies To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] Open Source Project?
At 03:18 PM 11-28-2001 +, Laurie Griffiths you wrote: This is NOT directly ABC related, so you might call it Spam. If so, I apologise. I will try not to do it often! Taking some of Laura's pleas to heart I want to experiment with Open Source. I'm not prepared to risk the source code of Muse in this way at present, but I am working on another music related project. snip I'm just going to comment on the Open Source aspects of this... The project itself sounds very interesting. The question is, on what terms should the source be opened? Here is what I have in mind. 1. Developers undertake not to market a competing product (whether free or for money) and will not incorporate any of the code into a competing product. 2. Developers may make any use of the source code for their private use. 3. Enhancements should be incorporated back into the main product base. Developers undertake that any contributions they make are free of any legal entanglements (i.e. they own the copyright, they give a non-exclusive free licence to the project and they know of no patent infringements). 4. Developers should receive a share of any profits. Formula yet to be worked out, but don't start thinking greedy thoughts. That probably means irregular pocket money not wages! This is -not- Open Source. Check out http://www.opensource.org for a description of Open Source from the Open Source Initiative -- the folks that coined the term. Open Source is -not- simply the source being available. Open Source typically grants the end-user several rights -- the right to make bug fixes, the right to create enhancements, the right to customize, and the right to further distribute the original software, customizations, bug-fixes and enhancements at will. Open Source prevents the user of the software from being dependent on the original developer. Your point 1 above is, to me, entirely contrary to Open Source. Would point one mean that a developer would be prevented from saying I submitted a patch to allow the Music Analyzer to work as delivered as a plug-in to FreeAmp, but he refuses to accept it. On my web site you can get the patched source code so you can build the Music Analyzer FreeAmp plug in for yourself. I also have pre-built binaries for Win2k, BSD, and Linux (both .rpm and .deb archives). -- as that would be incorporating the code into a competing product? Would it prevent a developer who's other open source activities are writing and maintaining sophisticated sound analysis and processing software from submitting a patch saying Your spectrum analysis code is OK, but it could be improved. Here's some code I am using in my open-source clone of baudline because baudline (and any clone) could be viewed as a competing product? In my opinion, if the answer to either question is yes (and it looks like it would be), it isn't Open Source. The other points are OK, but they seem to be missing the point of Open Source. If any developer is interested, initially I suggest that they email me off-list. Unless they say not to, I would distribute their emails to others who reply (but not to the ABC list). Feel free to distribute this further if you know anyone who might be interested. Laurie Griffiths http://www.musements.co.uk/muse where you will find music notation software for PCs. 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] Open Source Project?
Laurie == Laurie Griffiths [EMAIL PROTECTED] writes: Laurie The question is, on what terms should the source be opened? Here is what I Laurie have in mind. You don't say anything about the source being available to anyone. This is what makes an open source project open source. If you don't do this, and make the source available only to developers who sign some kind of agreement, it may be an interesting volunteer developer opportunity, but I don't think you can call it open source by any of the definitions I know anything about. I agree that this list is the wrong place to discuss the philosophy of open source development. But the word does get used here often enough that I think making sure we all mean something vaguely similar by it is probably constructive. -- Laura (mailto:[EMAIL PROTECTED] , http://www.laymusic.org/ ) (617) 661-8097 fax: (801) 365-6574 233 Broadway, Cambridge, MA 02139 (If I haven't invited you to my party on December 16, I'm sure it's an oversight.) 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] request for info
One or two abc files I have downloaded recently have a lower case m: field, as in m: Tn = (3n/o/n/ Can you tell me what this means please? It's a BarFly macro. What it does is to define how the T symbol gets played. In this case, what it means is that the symbol Tc would cause the note to be played as a triplet, (3c/d/c/. There's a full description of the macro system on the BarFly site: http://www.barfly.dial.pipex.com/bfextensions.html Phil Taylor To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] Open Source
Apologies to Buddha and Laura for abusing the term open source. I hadn't meant to. I am discussing things with them off-list. 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
