Re: [abcusers] tuplet beaming
On 5 Dec 2004, at 16:09, [EMAIL PROTECTED] wrote: Hello. The code: (6abc``def is (normally) interpreted as 6 notes in the time of 2 notes. Try use a more precise syntax for tuplets, like: (6:4abc``def which stands for 6 notes in the time of 4 notes; or the complete form: (6:4:6abc``def which stands for a proportion of 6 notes in the time of 4, for the next 6 notes; so it's possible do this: (6:4:4cd2``ef2 Hudson is correct. BarFly tells you if the bars don't add up as expected, so you should have caught that one. Also BarFly does let you change clefs in mid-voice; you should put the word 'bass' in a K: field. This will display correctly: (At least if you have a screen a yard wide to accommodate that many notes per line:-) X:3 T:Oh Callar Spirlings (variation 4) C:Domenico Corri V:1 V:2 M:3/4 L:1/16 Q:1/4=90 K:D Minor [V:1][L:1/16] A2|(6:4:6d^cd`ABc (6:4:6dag``fed (6:4:6^cde``ABc |(6:4:6d^cf`efe (6:4:6a^gad'^c'd' f'2 z2 |\ (6:4:6c=Bc`ede (6:4:6g^fg`c'=bc' d'2 z2 |(6:4:6d^cd`A=Bc (6:4:6dag`fed(6:4:6cde``ABc | [V:2][L:1/8] z | [DF]`[DF][DF]`[DF][AEG][A,EG] | [D2F2] z2 z(3G,/A,/=B,/ |\ [C2E2]z2 z (3A,/=B,/^C/| D```[DF] [DF][DF][A,EG]`[A,EG]| % [V:1][L:1/16] A2|(6:4:6d^cd`ABc (6:4:6dag``fed (6:4:6^cde``ABc |(6:4:6d^cf`efe (6:4:6a^gad'^c'd' f'2 z2 |\ (6:4:6bab``d'c'b (6:4:6agf``efg (6:4:6 fed`^cde |(6:4:6dfa``fad' d4z2 || [V:2][L:1/8] z | D```[DF][DF]`[DF][AEG][A,EG] | [D2F2] z2 [K:bass] z (3G,/A,/=B,/ |\ G,2 A,2 A,,2 | D,2 (6:4:6D,,/F,,/A,/D,/A,,/F,,/ D,,|| (You will need to do a bit of editing to get the abc to align the way you like it though.) Phil Taylor To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] tuplet beaming
On 5 Dec 2004, at 19:30, RWW Taylor wrote: The back-quote character appears on the standard Mac keyboard on the upper-leftmost key, above the tab very convenient. On my G4 PowerBook it's the key to the left of the Z, so I guess it's not really standardised, even on the same platform. Phil Taylor To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] tuplet beaming
% display totally messed up, playback wrong, it's not reading (6:4 as (6:4:6 You need both colons; (6, (6:: and (6:4: are all legal, 6:4 isn't. Phil Taylor To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] Finale GHB
On 3 Dec 2004, at 08:52, Bernard Hill wrote: In message [EMAIL PROTECTED], Christian M. Cepel [EMAIL PROTECTED] writes Any workaround to Finale's inablity to play GBH music (ornamentations gracenotes) as they should sound in GBH music? LOL! I think you mean GHB - Great Highland Bagpipe. GBH means Grievous Bodily Harm. All the Brits here will have been tickled by that. If you get drunk, get into a fight and hit somebody with a bottle, he ends up in hospital and you end up in a prison cell. GBH is what you get charged with. Phil Taylor To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] Bryan Creer (?)
On 30 Nov 2004, at 06:52, Don Whitener wrote: I have been out of touch lately, so I offer my sincere apologies should I blunder onto any toes. So far as I can tell, Bryan Creer has not posted to this group since early August 2003... Has he dropped out for a while? He does rather tend to drop out for long periods of time, then return to start a mighty argument. You may find him at [EMAIL PROTECTED] Phil Taylor To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] Recommendations for graphical entry software
On 17 Nov 2004, at 10:51, Iain (Jethro) Anderson wrote: xemacs with abc-mode.el and then e.g. abcm2ps to produce printed output The OP wanted graphical input. Not many abc programs will do that - offhand I can only think of MUSE, which is very out of date and whose author is now sadly deceased. If you can get to grips with learning abc, then using a text editor plus various free abc tools will do everything you want. Or maybe someone can tell me how I go about buying Guitar Studio (whose author wants to be paid in Euros) from California? You can pay for it in dollars ($40) using the online registration page: http://nmanel.free.fr/en_gs_commande.html Phil Taylor To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] how well supported is the overlay operator
On 12 Nov 2004, at 02:16, Richard Robinson wrote: On Thu, Nov 11, 2004 at 11:23:59PM +, Phil Taylor wrote: On 11 Nov 2004, at 20:32, Atte André Jensen wrote: Hi I'm wondering how standard the overlay operator is? Which programs supports the following for instance: L:1/8 | G3G- G2FG [C8D8] | AFAIK only abcm2ps supports it at the moment. I intend to support it in BarFly in due course. abc2mtex did something with it, didn't it ? But I forget the details. Did it really? There's no mention of it in the docs, and I don't have a working copy at the moment to try it out. Phil Taylor To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] how well supported is the overlay operator
On 12 Nov 2004, at 14:07, Richard Robinson wrote: From usrguide.tex :- the character is carried straight through to the TeX output and the characters produce a \enotes\notes pair. Thus the input DEFG ABcd A4 e2 c2| produces [2 staves] To explain this to those unfamiliar with MusicTeX, the DEFG are put on the lowest stave. The then tells MusicTeX to move up a stave, where it puts the ABcd. The first notes of each group are aligned. The (or a bar line) moves the output back down to the lowest stave and resets the alignment, so that in this case, the A4 is on the lower stave, and is aligned with the e2 on the upper stave. ah ... related, then, but not altogether similiar. I see - it's a MusicTex function then, rather than part of abc2mtex? Phil Taylor To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] how well supported is the overlay operator
On 11 Nov 2004, at 20:32, Atte André Jensen wrote: Hi I'm wondering how standard the overlay operator is? Which programs supports the following for instance: L:1/8 | G3G- G2FG [C8D8] | AFAIK only abcm2ps supports it at the moment. I intend to support it in BarFly in due course. Phil Taylor To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] Overlay operator
On 10 Nov 2004, at 06:34, Remo D. wrote: I realized that the overlay operator is the only one that moves the time backward. I think the 2.0 standard is not very clear on this operator, I'll try to summarize how it will implemented in ABCp, of course everything is subject to discussions and comments from your side!! Reading both the standard and the abcm2ps docs I understood the syntax should work as follows: (a=b means a is vertically aligned with b) 1) splits a measure GA | bc de | Fg-- d = b, e = c OK. 2) Duration counts! GA | bc e2 | Fg-- e2 = b OK. 3) overaly may occur on multiple measures G(A | bc d | F)g -- d = A, F = b, g = c No, I think the operator sets the time back to the bar line, so this should be A=G d=b (bar doesn't add up) and g=F. Or have I got the wrong end of the stick? but some questions are left unanswered: 1) What is durations don't match? Should we add rests or give an error? GA | b de | Fg-- d =b, e=? Definitely give an error. If the user really wants |[bd] e | here he can write that, or use an invisible rest | b x de |. 2) The example on the abc2.0 standard page seems to suggest that the operator splits the line and not the measure. I assume the example is from an old proposal and should be read as: (g4 f4 | e6 e2 \ (d8 | c6) c2 ) I don't understand that either. 3) The abc2.0 standard present it as voice overlay but they do not really defines a separate voice (as the V: field does), correct? Yes. It's a way of writing overlapping chords within a single voice. 4) What's the meaning of ? I found it in a couple of examples around. An error? I haven't a clue. 5) Anything else I missed on overlays? Let me know your thoughts. MusicXML has an equivalent backup operator which takes a numerical value which indicates how far the time point should be backed up. The time point may not be backed up further than the previous bar line. There is also a matching forward tag, which is essentially an invisible rest. Unfortunately these get horribly over used, so that a piano part where several voices are being played by one hand will be written with that hand all in one voice, with lots of backup and forward tags in each measure. The result is impossible to read and also tricky to parse. Let's not go there! Phil Taylor To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] [ABCp] Line continuation
On 23 Oct 2004, at 09:36, Remo D. wrote: Hudson Lacerda wrote: It seems that you coded a line continuation similar to those of bash or C That's what I did. Continuation gets reported (a T_CONTINUE event) and the scanner stays in the same state. That's correct. We have had long discussions on this subject previously, and the overall conclusion was that the continuation symbol should simply mean continued on the next line. The alternative, where it would mean continued on the next line of the same type was rejected because it leads to too many ambiguous and un-intuitive constructs. [V:1] abcde \ [V:2] ABCDE \ [V:1] cdedc [V:2] CDEDC is equivalent to: [V:1] abcde cdedc [V:2] ABCDE CDEDC but not to: [V:1] abcde [V:2] ABCDE [V:1] etc. That's difficult! Neither the 1.6 nor the 2.0 draft mentioned it! :( Do you mean that continuations should be treated as continuation within a voice? I hope not, it really would be difficult to handle. No, don't go that way! I hope many others will provide their comments about this issue so to reach a consesus on this topic. I intended to solve the issue treating ABC | def |\ M:1/4 gab |] as if it was: ABC | def | [M:1/4] \ gab |] That's fine. It is important to deal with this construct as it was specifically mentioned in earlier standards (before [inline fields] were introduced it was the only way to specify a key or metre change in mid-line), and there are many tunes on the net which incorporate it. Phil Taylor To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] [ABCp] Testsuite needed!
On 16 Oct 2004, at 20:00, Remo D. wrote: snip impressive progress report I would appreciate if someone could share with me a set of abc file to be used as test suite. I remember someone mentioned the fact he was working on something similar. I have a test suite which I used to test BarFly, but I'm afraid it only covers abc v1.6. Still, it does include a lot of awkward cases which still fall within the 1.6 definition, and you may find it useful. You can download it from http://www.barfly.dial.pipex.com/testsuite.abc Phil Taylor To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] ABCp output data structure
of the human ear it works fine. All you need to do in practice is to settle on a resolution which exceeds that of the human ear. You don't need to represent anything exactly for playing purposes. Phil Taylor To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] Call for an API
On 31 Aug 2004, at 21:14, Remo D. wrote: I have to admit that I have absolutely no idea on how to shape an API for the parser. I would rather define the API first and then the data structure instead of the other way around, the risk of over-engineering would be too high! Two major operation should be made easy: playing and printing. For playing it seems to me that a temporal iterator is needed. In other words, a way to traverse the structure obtaining all the musical events that happen at a certain time. You need that for printing too, at least if you're going to handle multi-voice abc. Notes in different voices which occur at the same time need to be vertically aligned, so you need to include exact timing to determine note spacing, unless of course you're going to do that within the parser. What about printing? I'm not sure. Anyone with an idea? I'd like to keep the API as simple as possible. Pass in a pointer to a string containing one tune, get back a pointer to a linked list of structs which is easy to convert to a picture of the music (anything from postscript to a bitmap) or to sound (midi, Quicktime tune or whatever). The devil of course is in the detail. Phil Taylor To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] Project for someone or already available?
On 26 Aug 2004, at 05:44, Chuck Boody wrote: First n bars would be the way to go. The layout of the title and incipit should be horozontal though, and not title above incipit. Yes, that's what makes it tricky to do properly. I'd need a way to create and display the index with two columns; text on the left and pictures on the right. I also wonder if you might be able to set up an interface to abc2mtex similar to the abcm2ps. John Walsh suggested abc2mtex has the indexing feature and maybe that could go to postscript. Or maybe the capability is in abcm2ps and I just haven't discovered it?? It's a long, long time since I last used abc2mtex. It was infuriatingly complex to set up, and since it hasn't been updated for many years it is now very limited compared with the modern programs. I'd rather not mess with it, unless somebody's prepared to put together a nice installer which will install abc2mtex along with musixtex on OS X. Would your suggestion work? I think so, but as you admit the abcm2ps can do a better job a parsing because it doesn't have to do it on the fly as Barfly does. So, I have some concerns about the output from what you are suggesting. I don't think you would need to work it into the current user interface though any more that transposition or some of the other things are worked in. Come to think of it: Might it work to create a file of incipits in a manner similar to what you do with transposition? i.e. create a new file with just the incipit in it. Then you'd only need to add the proper printing routine. BarFly's utility commands (e.g. Transpose, Change default note length etc.) all work by text to text conversion. While I could make one which converted a file of tunes into one big tune with many parts, each of which represents the first n bars of a tune, this isn't really what you want. Another possibility would be to output a picture file containing a tall narrow picture of the text and music in two columns. You would then have to open that and print it from a graphics program. The problem there would be that you would inevitably get page breaks through the middle of some lines. I could get round that by doing the page formatting myself, and outputting multiple files which could be printed individually, each representing one page of output, but now we're getting complicated. While I'm babbling about this: it would be nice to have control of the print size of the music. One might want to get many on a page and perhaps to get two columns on a page by keeping the output size small. Yes, you'd really want incipits to be as small as your eyesight will allow. In sum: Yes your suggestion would probably work. If you decide to tackle this in any way and want to pass a beta this way I'll be happy to test it. Sure thing. Phil Taylor To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] Project for someone or already available?
On 25 Aug 2004, at 22:47, Chuck Boody wrote: Greetings, I find that I frequently could use an index of an abc file (or set of files) that contains title followed by the first few bars (say 2-4). This would be invaluable for those situations where everyone remembers the title but not how it starts and for other such situations. Is there a simply way to do this (on a Mac for me)? If not is this a feature someone might like to add to a program (Phil? Barfly?) An index of incipits. It is a frequently-requested feature, and something I've been thinking about. Displaying such a beast in BarFly is difficult to fit in with the current user interface. One possibility would be to give the program the option of displaying only the first line, or the first n bars of each tune. Then you could select the whole file (or some subset of tunes) and print it. Would that do? Phil Taylor To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] K:none
On 19 Aug 2004, at 16:37, Steven Bennett wrote: K: by itself is not documented in ANY version of the ABC spec as a valid sequence, and cannot be assumed to work in any program. In my own parser, again, that would cause an error on the field, which would cause the field to be ignored (in an attempt to recover), which would then cause all kinds of havoc. Stick with K:none instead. Agreed. The bare K: is most likely to be an error (user couldn't immediately figure out the correct entry, and put it off until later, then forgot about it). Programs should flag it as an error, rather than assuming that it means C. Phil Taylor To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] K:none
On 18 Aug 2004, at 08:07, Atte André Jensen wrote: Hi Some tunes are not in any specific key, but it seems abc doesn't have any way to notate this. If I use K:C the song is shown correctly, but this opviously is corrupted when transposing it. Is there a solution withinn the current abc definition that I overlooked or should we consider extending the K: to allow K:none? It has been suggested before, and seems not unreasonable. Transposition routines would have to be re-written to deal with it though. Currently BarFly's transpose command will only transpose to a named key, so if I wanted to transpose Giant Steps up a whole tone I'd have to tell it to transpose to D, and I'd get a key signature with two sharps, which I suppose is what you mean by corrupted. BarFly's melody analysis thinks it's in Bb Phrygian by the way, although it's not at all sure, and gives two other (equally unlikely) alternatives... Phil Taylor To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] On parsers again
On 13 Aug 2004, at 18:13, Remo D. wrote: A question for the ABC tools programmers around here. Did you hand-code your ABC parser or did you use some standard tool (Lex, re2c, ...)? BarFly includes two separate parsers, for playing and display. Both hand coded in old fashioned procedural Pascal. It also has an xml parser for importing MusicXML written the same way, but that was fairly trivial by comparison. abc is hard to parse because it has grown and been extended by people who write it without worrying about how computers will deal with it. It's verging on being a natural language with it's own strange dialects and idioms. Phil Taylor To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] How to transpose abc to abc?
On 6 Aug 2004, at 07:09, Richard Walker wrote: Is there an option/switch to transpose abc-files into abc-files? I use abc2abc with -e to get rid of errors and -t with either a positive or negative number of half steps to transpose. If everything is OK I end it by redirecting the output to a file with somefile.abc abc2abc input.abc -e -t n output.abc If I have a tune in C, and I want it in C#, is there any way of doing that? The command above always gives me Db. Phil Taylor To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] ABC parser output data structure.
On 30 Jul 2004, at 13:34, John Chambers wrote: | In message [EMAIL PROTECTED], John Chambers | [EMAIL PROTECTED] writes | I hope you've found the FreeTTS project. | | Yes. Although we haven't tested it yet for various reasons. And, to make it relevant to this group, you'll have to start a sub-project to control the length and pitch of each syllable, so you can write a program that takes abc files with words and sings them in any of the available voices. (For those who wonder what I'm talking about, FreeTTS is an project that's producing an open-source text-to-speech package, all written in java.) Myriad, the people who make Melody/Harmony assistant are working on a browser plugin which displays, plays and even sings MusicXML. There's a mock-up demo of it here: http://www.myriad-online.com/misc/forum/testmusicxml/ (You'll have to download the plugin, but it seems fairly automatic.) Since they already have code to import abc, I wonder if they'll be making this capable of handling our format? Phil Taylor To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] Dublin Reel (?)
On 6 Jul 2004, at 17:06, John Barnaby wrote:
Phil
I emailed thanks and a snippet of the tune, but don't know if it got
posted.
Thanks again anyway for your help. I have done what I should have done
in
the first place and transcribed the arrangement. It comes out roughly
as
follows:
DF {G}((3FGF) DFEF| DF {G}((3FGF) AFEF|DF {G}((3FGF) D3 d|(3cdc Bc
AFEF|
!DF {G}((3FGF) DFEF| DF {G}((3FGF) AFEF|DF {G}((3FGF) D3 d|(3cdc Bc
AFEF||
!A2 (3AAA e2 (3AAA|ABcA BGEB|A2 (3AAA e2 (3AAA|AGEF GABG|
!A2 (3AAA e2 (3AAA|ABcA BGEB|A2 (3AAA a2 ga| ~f2 ec dBAF||
Can you comment on the arrangement?
John
Seems to be a tune which generates lots of variants, doesn't it?
You'll need a header to make the abc work, like this:
X:1
T:Dublin Reel
R:Reel
M:C|
K:D
DF {G}((3FGF) DFEF| DF {G}((3FGF) AFEF|DF {G}((3FGF) D3 d|(3cdc Bc AFEF|
!DF {G}((3FGF) DFEF| DF {G}((3FGF) AFEF|DF {G}((3FGF) D3 d|(3cdc Bc
AFEF||
!A2 (3AAA e2 (3AAA|ABcA BGEB|A2 (3AAA e2 (3AAA|AGEF GABG|
!A2 (3AAA e2 (3AAA|ABcA BGEB|A2 (3AAA a2 ga| ~f2 ec dBAF||
The exclamation marks would only be used by abc2win.
As to the musical arrangement, I'm not a fiddler but it looks and
sounds OK to me.
Phil Taylor
To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] Dublin Reel (?)
On 3 Jul 2004, at 20:31, John Barnaby wrote:
Can anyone help with abc's, or another name, for the version of Dublin
Reel
on Beginish: Stormy Weather?
Don't know that recording, but here's a whole bunch of them, various
transcribers
and in various keys:
X:20
T:Dublin Reel, The
T:Jackson's Reel
M:C|
R:Reel
S:O'Neill's
K:G
gB {d}(3BAB gBaB|gB {d}(3BAB dBAB|gB {d}(3BAB gbag|fdec dcBA|\
GB {d}(3BAB GB {d}(3BAB|GB {d}(3BAB dBAB|\
GB {d}(3BAB G2 ag|fdec d2fg|:\
ad (3ddd adbd|ad (3ddd {e}dBAB|1 ad (3ddd abag|fdec dBAg:|2\
g2{a}gf gbag|fdec d2ef|:\
g2 {a}gf gdBd|~g3d BGGf|1 g2 {a}gf gbag|fdec d2ef:|2\
gbag g2ag|fdec d2ef||
X:48
T:Dublin Reel II
R:Reel
M:C|
K:D
dFF2 dedc|dFF2 AFEF|dFF2 dfed|cABF AFEF|\
dFF2 dedc|dFF2 AFEF|d3c dfed|cABF AFEF||\
eAA2 eAfA|eAA2 BAFA|eAA2 egfe|dBcA BAFA|\
eAA2 eAfA|eAA2 BAFA|e3d egfe|dBcA BAFA||\
d3c dFF2|dedB AFEF|d3c dfed|cABF AFEF|\
d3c dFF2|dedB AFEF|dcdf egfe|dABc d3z||
X:49
T:Dublin Reel III
R:Reel
M:C|
K:G
G~B3 G2GD|G~B3 dBAB|G~B3 G2ge|fdec dBAB|\
G~B3 G2GD|G~B3 dBAB|G~B3 G2ge|fed^c defg||\
a~d3 adbd|a~d3 dBA2|a~d3 adbd|egfe dBA2|\
a~d3 adbd|a~d3 dBA2|g2gf gbag|fge^c d2ef||\
g2gf gdBd|gfgd BGBd|g2gf gbag|fge^c d2ef|\
g2gf gdBd|gfgd BGBd|g2gf gbag|fge^c d2ef||\
g~B3 gBaB|g~B3 dBAB|g~B3 gbag|fge^c d2ef|\
g~B3 gBaB|g~B3 dBAB|g~B3 gbag|fge^c d=cBA||
X:323
T:Dublin Reel, The
R:reel
H:See also #670, in G
D:Noel Hill: The Irish Concertina
Z:id:hn-reel-323
M:C|
K:D
dF~F2 dFeF|dF~F2 AFEF|1 dF~F2 dfed|cABG AFEF:|2 d2dc dfed|cABG AFEf||
|:eA~A2 eAfA|eA~A2 BAFA|1 eA~A2 egfe|dBcA BAFA:|2 e2ed egfe|dBcA BAFA||
|:d2dc dAFA|dcdA FDFA|1 d2dc dfed|cABG AFEF:|2 d2df e2eg|fdBc dfec||
Variations:
dF~F2 dfec|dF~F2 AFEF|1 dF~F2 d2ed|cABF AFEF:|2 d2dc d2ed|cABF ABcd||
|:eA~A2 eAfA|eA~A2 BAFA|1 eA~A2 e2fe|dBcA BAFA:|2 ~e3d e2fe|dBcA BAFA||
|:dfec dF~F2|dedB AFEF|1 Addc dfed|cABF AFEF:|2 dcdf egfe|dABc d3z||
X:670
T:Dublin Reel, The
R:reel
H:See also #323, in D
D:Michael Coleman 1925
Z:id:hn-reel-670
M:C|
K:G
gB~B2 GB~B2|gB~B2 dBAB|gB~B2 gbag|fge^c dBAB||
GB~B2 GB~B2|GB~B2 dBAB|GB~B2 GBag|fge^c dBAB||
ad~d2 adbd|ad~d2 dBAB|ad~d2 abag|fgfe dBAB|
ad~d2 bd~d2|ad~d2 dBAB|g2gf gbag|fge^c d2ef||
gbaf gdBd|~g3e dBAB|g2gf gbag|fgfe dBAB|
g2gf gdBd|~g3e dBAB|g2gf g2eg|(3fgf (3efe d2ef||
Phil Taylor
To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] Anyone up for writing a little script?
On 1 Jul 2004, at 06:43, Atte André Jensen wrote: Dafydd Monks wrote: Anyone out there up for writing a little ABC processor (midi and GIF) in PHP? You mean like this: http://www.atte.dk/abc/ I submitted a minimal abc tune to this to try it out: X:1 T:test C:nobody M:C K:C ABcd ABcd |] Transpose worked OK (but only into flat keys), but neither Mac Preview nor Acrobat could display the pdf. Both said it was corrupted. I tried the postscript version and Ghostscript barfed on that too. I'd guess this is something going wrong with abc(m)2ps, rather than the php, but you might want to take a look at it Atte. Phil Taylor To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] Alternate endings?
On 29 Jun 2004, at 06:53, Neil Jennings wrote: Programs which actually make use of, and play, the chord names which are supposed to be in the quotes, wouldn't like this. Nor would player programs in general! (Unless, that is they can be made smart enough to understand arbitrary English instructions.) Phil Taylor To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] ANN: new version of Five Line Skink - Comments and a wish.
On 18 Jun 2004, at 06:39, Chuck Boody wrote: I just tried 5 line Skink. It is a very nice clean implementation of at least the basic things (I didn't try it on multi parts or anything too complex). Bravo to Wil for adding a tool for us all (and for including three really good tunes in the package. Two I knew and like his versions, and one is totally new to me which is always fun). The syntax checker in Skink is very fussy (that's good I think) and does a fine job of locating the errors for you. It caught a bunch of things that didn't trouble BarFly or the abc2ps things much at all. I'll probably run a bunch of my files through it just to clean things up. I did find one file that it only gave me an empty error dialog box and refused to even put the tunes up (and this works perfectly in Bar Fly and is, as far as I can tell clean.). Wil if you'd like drop me a note and I'll send it on to you. Now to the main thing: How much of a problem might it be to integrate or build links to the abcmidi stuff from BarFly or Skink or some other Mac program? I'd really like to be able to generate MIDI files with or without the boom-chuck accompaniments, and currently I have to go to John's web site or fuss with using abcmidi in the terminal mode on the Mac (which I haven't done yet, but appears doable). Having that possibility makes producing teaching materials so very easy. While you are at it set it to allow generation of the melody and the accompaniment on separate midi voices. Then I can use two sounds, set the accompaniment to play on one side of a stereo recording and the melody on the other and create very nice files that allow my students to listen to melody or accompaniment or both as they learn. Any takers here? Or, is the capability already in some program and I just missed it? You can export midi (or QT movies or AIFF audio files) directly from BarFly. This has not worked well with some versions of Quicktime, but under OSX 10.3/QT 6.1.5 seems to be working OK. BarFly has an interface to abcm2ps, and you could also use this to send files to abcmidi if you wanted, just by changing the program name and entering the appropriate command-line arguments. However, in most cases BarFly will generate better sounding midi files than abc2midi, as it has better stress programming. BarFly doesn't play guitar chords, so if you want to hear them you should use the Expand Guitar Chords command, which will generate a new tune in two voices with the chords in V:2. Nothing fancy, mind you, just a plain pad accompaniment. What sort of errors does Skink catch and BarFly miss? I'd be interested to know. Phil Taylor And, the comments about running on a PDA are of interest too. I do have the little thing that does ABC on Palm OS, but it could certainly stand some improving Chuck Boody = 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] force a linefeed in the ps output
On 11 Jun 2004, at 15:52, Jack Campin wrote: How can I persuade abcm2ps to output a lf at the |: ? Or indeed anywthere ? Blah, it is so easy. I just put a T: before each |: I am really sorry for the stupidity of this question. The question's fine, it's the answer there's a problem with. T: lines are supposed to be in headers, not tune bodies. No, T: lines can go in the tune body too (so that if your tune is actually a set of tunes you can title them individually). If abcm2ps accepts your solution it's doing soemthing wrong. It is indeed. A T: line shouldn't force a staff break, as a tune may end, and the next one start in the middle of a line if that's what the user wants. We have been over this before, but by far the best wolution is for softwre to recognize an explicit staffbreak using !. I thought that had been implemented in abcm2ps already? (It comes from abc2win, which unfortunately doesn't recognize a source linebreak as a staffbreak, and is halfway-supported in BarFly). abcm2ps is also doing something wrong if it doesn't recognize a linebreak as a staffbreak. I thought it did? Have you configured it in an odd way? I would guess that he's entering tunes with \ at the ends of the lines and relying on the program to wrap the tune to the staves correctly. If so, all he has to do is remove the backslashes, and the program will usually place the staff ends where the line ends are in the text. The exception to this is if there are too many notes to fit on one line where it will create a new staff for the overspill notes. (BarFly just continues cramming the extra notes in, which is OK if it's just one or two but becomes unreadable when carried to excess.) Phil Taylor To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] What software will translate this correctly?
On 10 Jun 2004, at 07:04, Steve Wyrick wrote: Thanks John, I like the way that looks on abc2ps; unfortunately BarFly doesn't like the voice headers in that position and returns a score that's blank except for title composer! As you mentioned, abc2ps doesn't need the middle=d term. BarFly doesn't really need it either but I specified it for 2 reasons: to (hopefully) let me write code that was readable by both programs, and to save me typing so many commas in the bass line (e.g., without that term, C is written as C,,)! Steve, I think you should suggest to your friends that they get abcm2ps; it's much more up to date, is still being developed and there are versions for all three major platforms. You might want to look at it yourself too, as you can invoke it directly from BarFly to get a nice GUI. There are instructions for this in the Import/Export doc which comes with BarFly. Phil Taylor To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] What software will translate this correctly?
On 10 Jun 2004, at 16:22, Steve Wyrick wrote: Phil Taylor said: Steve, I think you should suggest to your friends that they get abcm2ps; it's much more up to date, is still being developed and there are versions for all three major platforms. You might want to look at it yourself too, as you can invoke it directly from BarFly to get a nice GUI. There are instructions for this in the Import/Export doc which comes with BarFly. Thanks Phil, I'll look into it, and suggest it to anyone who asks. Unfortunately, the majority of the people I interact with who use abc just dump it into the concertina.net tune-o-tron (http://www.concertina.net/tunes_convert.html), which uses abc2ps, abc2midi and ghostscript; or download tunes from JC's ABC Tunefinder as pdf files (John, does your site also use abc2ps as an intermediate step in going to pdf? What about the MIDI generator?). Since I planned to post this transcription I was looking for a format that even the dumbest abc translator could read! It's frustrating having to deal with the situation where the most-used program isn't the best one! -Steve There used to be at least one other abc to staff notation converter on the web at http://www.fojar.com/~steve/abctostaff/index.php but that just gave me a 404, and www.fojar.com gives a message which says Moving day, so maybe it will be back. It might be worth contacting the owners of concertina.net and asking them to change it to use abcm2ps. It would be a trivial job, as the interface is identical, and it would make no difference to simple tunes. As another alternative, perhaps Jon Freeman could consider adding a tune converter to FolkInfo? As he is already using abcm2ps to convert tunes from the FolkInfo database on the fly it might not be too difficult. Phil Taylor To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] this tune intentionally left blank
On 7 Jun 2004, at 08:46, Paulo Eleutério Tibúrcio wrote: Em Qua 02 Jun 2004 12:47, John Chambers escreveu: Jack Campin writes: [snip] | The problem is how best to say this. | There is a list of headers that could contain a code for no | notes. This field already uses a double quote to indicate that | accompaniment chords are present. I wonder if there's a good | single char that could stand for notes, or maybe for no | notes? Perhaps '*' (asterisk) could be used for this, as it | doesn't seem to have any other use, and it is conventionally | used to indicate an explanatory footnote. | | That sounds pretty good. Maybe I'll try implementing it. I don't think that would be a good idea. IMHO any characters that might still be available should be reserved to signal new, more productive contexts. The no notes context can be easily be indicated by a pseudocomment as long as a standard one be agreed upon. E.g. %% End of tune or %% No notes or %% End of X:tune identifier Of course, this would be just a redundant way of telling parsers that the transcriber _hasn't_ made the mistake of signaling the end of tune prematurely. Why not just use a tune which consists of a single barline? That is actually a minimal legal tune. BarFly will display an empty staff, with title, composer clef and metre. (Otherwise you get an error message which says No tune.) Not sure what other parsers will do. Phil Taylor To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] this tune intentionally left blank
On 7 Jun 2004, at 08:53, Paulo Eleutério Tibúrcio wrote: Em Qua 02 Jun 2004 14:26, Phil Taylor escreveu: Interesting. If you look at the html source for the first tune in that file it looks like this: p class=MsoNormal style='margin-right:.5in;tab-stops:.6in 1.1in 1.6in 2.1in 2.6in 3.1in 3.6in 4.1in 4.6in 5.1in 5.6in'span lang=EN-GB style='mso-ansi-language:EN-GB'Xspan class=GramE:1/spano:p/o:p/span/p [snip] It's a long way from abc. I suspect it's actually microsoftml, and probably written in MS Word. Surely is, with all that redundance in the 'mso' style tags. You see, this garbage is intended to solve MS Office's problems of interoperability, not to produce anything convenient or suitable for the Web. (In fact, if you check the source code for the page, you can see a META element saying it was generated by Microsoft Word 10.) The right way to HTMLize it would be something like pre class=music abcnotation title=ABC notation of A. A. Cameron's Strathspey in A Mix code X:1 T:A. A. Cameron's M:4/4 L:1/8 R:Strathspey K:A Mix |:eA3 A4 B3Gd3B|eA3 A4 d3g (3f2e2d2|eA3 A4 B3Gd3B| % And so on ... /code /pre I tried this with four different browsers, and it worked fine in all of them. (Of course, you'd have to substitute amp; lt; and gt; for any and characters respectively in the source. Defining presentation of the ABC segment would be simply a matter of defining a style for a CODE element which is a child of a PRE element with classes 'music' and 'abcnotation' set. It would also be straightforward to parse.) Probably better to eliminate the and characters entirely (they're only shortcuts after all). Maybe the standard should state (or at least recommend) how ABC source code should be embedded in HTML/XML. Using pre).../pre has been suggested before. I don't think John likes it because the tune finder bot will still have to parse .html files as well as .abc. And, of course there's the problem of getting people to use it. Phil Taylor To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] Re: PERL ABC script?
On 28 May 2004, at 02:28, Dafydd Monks wrote: Take a look at the site - I think you'll agree that the tunes have come out ok. (computer is an i686 running linux 2.2 abc2midi and that script on concertina.net that generates images) Nice site; great tunes. Here are some comments after a cursory look. It would be nice if the tunes were listed in alphabetical order, or if there were a search facility. Also, for those of us who collect abcs it would be nice to have the option of downloading all the tunes in one big file. abc2win has a few peculiarities, so tunes submitted using this program often need a little fixing to work correctly. Notoriously it plays abc at the wrong speed, so tunes which have a Q: field tend to play very slowly on other programs. Listen to Dwy Bleth o'i Gwallt Melyngoch for example. It says it's a jig, but plays like a funeral march. The solution is just to delete the Q: field and leave the tempo up to the playing program. Keep up the good work! Phil Taylor To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] AlphabetSoup output data structures
On 14 May 2004, at 07:56, Martin Tarenskeen wrote: I'm a user of MUP. There was a similar discussion some time ago about this subject in the mup-users mailing list. Just like in abc in mup the notes in a chord have to be of the same length, or else be in different voice. Notes in a chord don't have to be all the same length in abc. We've had this discussion many times before. The musical length of a chord (i.e. the time interval until the next note starts) is determined by the length of the first note in the chord. Whether there is any software that implements this is another matter, but the option is certainly there. If a user wants to break such a rule a notation software could implement the manual placement of noteheads, stems and other objects. In a graphically orientated package like Score Perfect Pro (great program and cheaper than Finale or Sibelius) this is easily done. It's also easy to do other illegal things like putting 5 quarter notes in 4/4 bar. In music notation languages like mup and abc this is much more difficult, or close to impossible. Where's your problem? It's perfectly easy to put 5 crotchets in a 4/4 bar in abc. To do so creates a sense of unease in the reader (is that a mistake or did you really intend it?), but is perfectly playable. Definately wrong, though. Phil Taylor To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] AlphabetSoup output data structures
On 15 May 2004, at 01:21, Jack Campin wrote:
A cautionary note here - how _would_ your parser behave on discovering
it was asked to parse one of these 'illegal' constructs?
I'm in agreement with the point you're making but not with any of your
examples...
there is a significant number of existing tune files (with hundreds
of tunes) that have things like:
{a}(Gab)
gracenote outside a slur - (oh, but I thought a gracenote was a
decoration and so should be applied to the directly following note...)
This has a clear meaning if it's being played on a fiddle - change bow
direction after the gracenote and keep it going the same way through
the slurred notes. And it's found in a lot of the 18th century sources
I've used (sometimes just to squeeze stuff into limited space,
sometimes
with deliberate intention).
Yes, this is fairly commonplace in abc, and perfectly acceptable.
a :: b
broken rhythm across a barline or repeat (oh, but I thought a broken
rhythm couldn't have intervening barlines...)
Nothing in any standard to prevent that that I know of, and it can make
the source more readable. (No reason why the construct shouldn't cross
part boundaries, either, or have non-local meaning in the presence of
alternate repeat sections; it can get complicated but it's always well
defined).
We discussed that one here some time ago and decided that it ought to be
illegal. Personally I don't think it does make the source more
readable,
and it sure as hell does pose problems for the parser writer.
a (bdc)
broken rhythm outside a slur. (oh, but... you get the idea...)
This is obviously legal and omitting it would make some kinds of
hornpipe bowing an unreadable mess. See Honeyman's Strathspey,
Reel and Hornpipe Tutor for examples: he systematically slurs the
short note of a dotted pair to the following long one. (However,
I have never put a space between a broken-rhythm marker and its
preceding note, as you did there; am I obeying a nonexistent rule?
I'd been thinking that a 2 and a b would cause equal problems
to parsers).
You have a choice as to whether the two notes are to be beamed together
or not (assuming they're less than a crotchet in length) so the space
has
to be OK. The slur is certainly legal. Gracenotes would also be legal:
e.g. a{gc}b as would a broken rhythm construct contained within a
tuplet:
(3abc. Broken rhythms are illegal between notes of different lengths:
a2b (because the meaning of that is ambiguous) and therefore also
illegal
where they cross a tuplet boundary: (3abcd.
Doesn't really matter if _I_ think the abc standard doesn't allow
that, people have done it and have invested time and effort in
notating tunes that way.
We can say something stronger: usually they knew what they meant
by it and had consistent, understandable expectations of how ABC
software should interpret it. Implementations need to go beyond
simply accepting such syntax, they need to handle its semantics.
|| I quote Gardner Read Music Notation page 69 Intervals
(involving
|| two note heads) or chords (three or more note heads) may use a
single
|| stem to join all the notes as a unit provided they are of equal
|| value.
| 18th century music printers and 20th century editors of guitar
music
| followed no such rule.
Just because some people don't follow a rule correctly doesn't mean
that it doesn't apply.
Rubbish. The consequence of that attitude is that your software
doesn't apply to my music. If Read's dogmas get in the way of
such a straightforward task as creating a type-facsimile of an
old-fashioned but instantly readable and unambiguous piece of staff
notation, they're roadkill.
I think the point to bear in mind here is that abc is not staff
notation,
nor is it simply source code for programs which generate staff notation.
While in general it follows the rules of staff notation it is a separate
and distinct musical notation in its own right; arguments based on what
is legal in staff notation are irrelevant when applied to abc.
abc can represent some musical constructs (e.g. chords with different
length
notes) which staff notation cannot. Another example is note-lengths;
in
abc you can write A7/13; it's legal and most abc players will play a
note
of that length without demur, but it can't be represented (at least not
exactly) in staff notation. It's a feature which makes abc capable of
representing un-quantised midi data, and is therefore potentially
useful,
although it will cause problems for programs which produce staff
notation.
Phil Taylor
To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] Re: mice
On 28 Apr 2004, at 04:33, Jim Russell wrote: till they get the message. (Quick, how *do* you remap the mouse buttons to use a mouse left-handed for the duration of a catalog Can't say I've ever thought about it but I am quite used to being a left hander in a right handed world (and play right handed). I'm left-handed as well, and have always hated remapped buttons. I use the mouse left-handed, but my middle finger clicks button-1 (left), while my index finger spends most of its time on the scroll wheel. Ah, well, I play right-handed guitars left-handed without restringing, too. From Elizabeth Cotton to Jimi Hendrix, you're in good company! Phil Taylor To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] reusable parser
On 28 Apr 2004, at 01:52, John Norvell wrote: Perhaps this is a good time to bring up the idea of a central set of parser test cases and test case fragments. In the past a number of list members have mentioned the desire to have a corporate body of test cases that could be used during testing and development of abc parsers.Perhaps this open source project could be a forum to officially start collecting those test cases. I have a collection of tunes in graded levels of difficulty, which I use for this purpose. It covers only abc 1.6, but that's where you want to start anyway. It's at http://www.barfly.dial.pipex.com/testsuite1.6.abc and you are welcome to use it. Hmm, I hope that file name with two full stops doesn't cause problems. It works OK for me. Phil Taylor To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] Falcon 68030
On 28 Apr 2004, at 14:16, Stephen Kellett wrote: In message [EMAIL PROTECTED], Martin Tarenskeen [EMAIL PROTECTED] writes apps that need long filenames, but don't like case-sensitivity. I can do it all on my 25 years old Falcon. No you can't. The Atari ST didn't come out until the mid 80s and the Falcon came after that. I think you may mean 15 years? 11 or 12. See: http://www.atarimuseum.com/computers/16bits/falcon030.html Phil Taylor To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] File names
On 28 Apr 2004, at 21:42, Steven Bennett wrote: That said, the file contents in the ABC specifications (including the 2.0 draft) are assumed to be strictly ASCII compliant, and I believe case sensitive everywhere. (Someone correct me if I missed something there.) I believe that the mode part of the K: field is case insensitive, and spaces between the key letter and the mode are permitted, so: K: Ador K: ADor K: A DOR are all equivalent. Certainly all those variants are commonly found in the wild, so a parser should be prepared to deal with them, even if it flags some of them as errors. Phil Taylor To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] something that ought to work...
On 16 Apr 2004, at 09:14, Jack Campin wrote: Using ! as a staffbreak has the same motivation - it's to reconcile conflicts between source readability and staff-notation readability. I don't know what BarFly does with multivoice tunes using ! as a staffbreak, but I suspect its implementation is too simple to work, so I didn't even try with this example, though I intend to migrate all my single-line tunes into that style eventually. BarFly's implementation of ! is pretty crude - it's done in the pre- processor, and it just strips out all of the line ends, then puts new ones in where the exclamation marks are. This is fine for single-voice, and allows files created by ABC2Win to display correctly (even works for the Village Music Project abcs), but it falls down on multivoice, because the program requires the lines of abc to be in the same order as they will be displayed in staff notation, and also requires the V: fields to be at the start of a line. If you use this mode in a multivoice tune the preprocessor will turn the tune into garbage. Phil Taylor To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] something that ought to work...
On 16 Apr 2004, at 17:11, Jack Campin wrote: BarFly's implementation of ! is pretty crude - it's done in the pre- processor, and it just strips out all of the line ends, then puts new ones in where the exclamation marks are. This is fine for single-voice, and allows files created by ABC2Win to display correctly (even works for the Village Music Project abcs), but it falls down on multivoice, because the program requires the lines of abc to be in the same order as they will be displayed in staff notation, and also requires the V: fields to be at the start of a line. And the P: K: L: and M: fields too, when they occur in mid-tune, and you know what it does to commmnt lines... You haven't looked recently, have you? Try this (with apologies to Robert Bley-Vroman, whose impeccably laid out tune I've messed up for the sake of this example): X: 8 T: Chorus Jig S: Miller and Perron New England Fiddler's Repertoire 1983 N: Adapted by Robert Bley-Vroman [EMAIL PROTECTED] April 1997 R: Reel M: C| L: 1/8 Q: 1/2=112 %%MIDI program 1 40 %%MIDI channel 1 K:D P: A AG | F2 DF AB AG | FA DF A2 d2 | D3 F AB AF | GF EF G2 :|! P: B K:G [| Bc | dB cA BG FG | Ad ^cd A2 B=c | dB cA BG FG | Ac BA G2 Bc |! dB cA BG FG | AB cd ef ge | dB cA BG FG | Ac BA G2 |]! P: C K:D |: ag | fd dd fd dd | fd fg ab ag | fd dd fd dd | =cd ef g2 :|! P: B K:G [| Bc | dB cA BG FG | Ad ^cd A2 B=c | dB cA BG FG | Ac BA G2 Bc |! d2 (3cdc BG FG | AB cd ef ge | dB cA BG FG | Ac BA G2 |]! The preprocessor is a bit smarter than I described; it doesn't remove line ends from comment lines, and it converts fields to [inline] format before starting, so they survive the process. It even keeps track of the positions of all the edits it has made so that when you click on a note head and highlight it the program can still work out where the corresponding abc symbol is and highlight that. In order to make this work with multivoice tunes I'd have to completely re- write the parser though, so unless I get a lot more requests from users I'm not in a hurry to start that. (Other BarFly users please note that this may not work for you - Jack has a pre-release copy of the next version.) Phil Taylor To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] something that ought to work...
On 16 Apr 2004, at 22:23, Jack Campin wrote: I had never even noticed that was possible before. It isn't dramatically obvious as I normally use BarFly on an enormous greyscale screen, and the highlight colour is pale grey. Tell you what, you couldn't make that highlighting show up in red for me, could you? Monday would be fine. Bit of a tall order on a grayscale screen. However, you could go to Apple Menu : Control Panels Appearance Click on the Appearance tab Ignore the preset colours on the Highlight Color popup menu (they're all pastel colours aimed at people with colour screens). Select Other... instead, and use one of the colorpicker dialogs to set a darker grey. (That's under OS 9; may be slightly different under earlier systems.) Phil Taylor To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] something that ought to work...
On 15 Apr 2004, at 18:54, Neil Jennings wrote: If you make a couple of small changes, my program HARMONY can deal with it a) Put [ and ] around the v:1 and v:2 in the body (But not in the header) OK either way in BarFly, but the way Neil suggests is the way you should have done it, as the other way is deprecated, and may not be supported in future. b) remove Hp from the key signature - Harmony does not support pipes key signatures BarFly does support pipes signatures, but you can't have both, so E Hp is wrong (they're different keys anyway). c) replace the back quotes by upright quotes - maybe HARMONY got this wrong? please let me know. I was working from the abc v2 draft, which does seem to leave a lot out. Back quotes are just text spacers and should have no effect on the interpretation of the abc. Upright quote (ascii apostrophe) shifts the pitch of a note up by an octave. d) remove the word merge (What does it do?) It means draw the second voice on the same staff as the first. Phil Taylor To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] ABC and MusicXML
On 6 Apr 2004, at 21:10, Jack Campin wrote: Regarding lining up barlines... I had thought that spaces in position 0 on a line were illegal. IE, the # here fe|d2B2 A2F2|A4 A2AB|d4 e2de|f2e2 egfe| ###d2B2 A2F2|A4 A2AB|d4 e2de|f2d2 d2 :| No, they're fine by all standards since 1.5 at least - nor, as far as I know, has any ABC software ever had a problem with them in practice. Provided, that is that the line doesn't start with a field letter. A space before a non-inline field is illegal. Phil Taylor To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
[abcusers] BarFly version 1.53 available
There's a new version of BarFly up for grabs at http://www.barfly.dial.pipex.com As usual this is a free update. New stuff: * Recent files menu. * Line number display. * Coda added to list of musical symbols. * Symbol definitions can now be written between exclamation marks or + signs (if you must!). * Preferences for the Analyse Melody command are now persistent. * Plus a few bug fixes. Enjoy! Phil Taylor To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] ABC and MusicXML
On 1 Apr 2004, at 18:39, Richard Robinson wrote: On Thu, Apr 01, 2004 at 06:20:00PM +0100, Neil Jennings wrote: MusicXML is plain text, just as all the markup languages are, but that doesn't mean you don't have to decode it. Can you decode even simple HTML by just reading it?. Sure. Anything can be made hard to read if you have a machine generate it, even ABC. But things are usually easier to read if they're written by hand - html is, for certain. MusicXML needs to be read along with the DTD. ?? Try looking inside one, it's not often hard to see what things mean. No, it's not difficult to understand, in fact you can pretty much guess what most of it means, since everything is labelled. The problem is the sheer volume of text you have to wade through. In abc, each note occupies one or two characters, in MusicXML it occupies half a page. A page of music in MusicXML can take up 100K of text. I found it very difficult to debug my software because I was spending most of my time wading through the MusicXML source looking for the specific construct that was causing the problem. Phil Taylor To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] ABC and MusicXML
On 1 Apr 2004, at 22:19, Christian M. Cepel wrote: With this in mind, I've been struggleing while editing ABC lately. I'm not real good at reading music or ABC on the fly due to learing disability (latent cognition between reading and comprehending). There's a few things that prove to be making reading ABC on the fly a real difficult task. I wonder what other people feel about my stumbling stones. 1. inline chords. Flotsom floating down midstream making navigation difficult. You mean guitar chords? I agree with you. They do interrupt the flow of information. 2. spacing on either side of barlines... this actually is a very helpful deliniation for me... the problem arises with the numbered repeats |1 and :|2... all the programs I've tried only recognize these 'tokens' provided they do not have those spaces I like so much for readability | 1 aBc aBc :| 2 abc abc | Yes. Bar lines are much more visible when they have spaces on either side. I don't have much problem with the numbered repeats though. You can, of course write them as | [1 aBc aBc :| [2 if you really need the space here. (The programs are correct to object to | 1 aBc aBc :| 2 abc abc |, since that's specifically declared illegal in the standard.) Phil Taylor To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] Exporting to Midi.
On 31 Mar 2004, at 00:53, Jack Campin wrote: Phil Taylor wrote: there is a bug in Quicktime 6 which causes long notes to be truncated (played staccato) when generating a midi file. If you can use Quicktime movie files instead of midi it's not a problem. Likewise if you can use a pre- OS X operating system you can use Quicktime 4 (last good one). The problem happens when the delta time for note lengths requires more than two bytes to express it, so another possible work around is to generate the midi file at a fast tempo to keep all delta times within two bytes, then use a midi editor to change the tempo. Yuck. And the duration required isn't all that long either. Is there a tool for bulk conversion of QT movie files to MIDIs? That would be easier if it existed. No, and if there were it would depend on Quicktime, and would suffer from the same bug as BarFly and Quicktime Player Pro. Just what has been going wrong with the QuickTime development process that they've shipped such buggy products for so long? The guys that designed Quicktime Music Architecture left Apple, and were not replaced. QTMA itself was not successful. Although it plays music beautifully it has a complex and confusing API, only really of interest to musician programmers (as opposed to those who just want to record and playback audio). Very few programs depend on it. The rest of Quicktime _has_ been successful, but the introduction of OS X with its built-in Core Audio has resulted in QTMA being sidelined. The last time I discussed these problems with an Apple engineer he said that I really ought to be using Core audio instead. Trouble is, CA starts with midi. I'd have to re-write my software to generate midi instead of a QTMA tune to use it, in which case I would have solved the original problem anyway! Phil Taylor To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] ABC and MusicXML
On 27 Mar 2004, at 18:53, Richard Robinson wrote: The question that gets raised at this point, which I don't know the answer to, is - how easy is it to translate abc to xml ? How well does xml accomodate the concepts of ABC, how much of the possible information in an ABC file does MusicXML have encodings for ? So far as there are things in an ABC file that MusicXML can't represent, we'd have to invent some way of wrapping them up in comments, or something - find a way of shoehorning it into ABC - in a way that xml-abc translators could recognise, preferrably a way generally agreed upon (rather than carry the issue of dialects across to our generated XML). MusicXML is a very comprehensive music description language. For example, it is possible to include in a MusicXML file both the information to construct the staff notation, and that needed to construct a midi file. These are fairly independent of one another, so you can specify e.g. a mordent to be printed, but the notes which correspond to be played. The only feature I can think of which is present in abc but not MusicXML is the bagpipe key signatures. So abc - MusicXML is relatively easy. The reverse translation is much more difficult. (e.g. MusicXML permits multiple voices within the same part, so in a piano part, which may include four or more voices, each bar has several backup tags to allow the different voices to coexist. The voices can move independently across staves, change clefs and so on, and there's no way to do that in abc.) (A further question here; are there descriptions of MusicXML anywhere ? I have Recordare's Tutorial (V1.0), and I know the DTDs give all the sordid details, but they're a bit bulky for a beginner to find their way around). I think that's all there is. There is also a MusicXML mailing list, which is quite active, and is usually the best place to go to ask questions. And, yes, I guess that points of formatting would the trickiest to preserve, recording whitespace between ABC elements, comments and so on. Not impossible, but I can imagine a temptation to cut corners in the coding. Yes, whitespace which doesn't convey any information (as opposed to that which determines beaming) would be very hard to preserve. Since MusicXML is not intended to be read by humans, comments in the source would be useless, so abc comments would have to be preserved differently. Phil Taylor To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] ABC and MusicXML
On 26 Mar 2004, at 16:23, Richard Robinson wrote: There's a small error in the example files on your webpage: the DOCTYPE tags refer to local file:// URLS, which won't work on other computers. That's be the file:/c:/Program Files/MusicXML/partwise.dtd bit ? It doesn't work on mine, either. But it doesn't seem to stop things doing what they should - perhaps because I have a permanent net onnection so the external DTD reference can be used. Did it stop you being abe to use/render the files ? My processor also seems able to process without validation, which seems to stop it trying to use either (so the complaints go away). I did say the converter I'm using isn't perfect. But from the responses so far, it seems to be the only one. That's disappointing. You haven't actually included the external DTD reference. In place of the file:/c:/Program Files/MusicXML/partwise.dtd you should use http://www.musicxml.org/dtds/partwise.dtd;, then it should work for anybody who has an internet connection. The original file:// specification will only work if you happen to have a disk named c with the appropriate file on it. Tried it on my Mac with three different browsers: Internet Explorer objected to that file reference; if I download the file and change it as above, IE downloads all the DTDs, but then just displays the source. Safari gave this, so it's clearly trying: the Female Rake abc2xml 2004-03-23 Richard Robinson URL:http://www.leeds.ac.uk/music/Info/RRTuneBk/contact.html Jig England 960 2 major 6 8 G 2 A 4 480 eighth D 5 480 eighth begin etc. iCab opened the source. You can, of course download the source and import it with BarFly, but I noticed a snag here too. Safari downloads the file as untyped, and BarFly won't recognise it as a text file. Curiously, if you change the file extension to .txt it works fine. (One more little thing to fix.) Phil Taylor To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] ABC and MusicXML
On 26 Mar 2004, at 22:40, Richard Robinson wrote: I notice also, the public part of this refers to a 0.6 spec, whereas someone (Stephen Kellet, I think) posted a reference to a v1.0 spec a couple of months back. Current spec is 1.0. See http://www.recordare.com/dtds/versions.html. Quite a lot has been added, but everything in v0.6 is a still there in 1.0, so it should be backward-compatible. Phil Taylor To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] ABC and MusicXML
On 26 Mar 2004, at 21:48, Richard Robinson wrote: Safari downloads the file as untyped, and BarFly won't recognise it as a text file. Curiously, if you change the file extension to .txt it works fine. (One more little thing to fix.) It's served from the website as Content-Type: text/xml and the filename extensions are .xml. I don't know how a Mac manages these things ? That's fine. It's just that at the moment the Mac is in transition between two different systems for identifying the type of files, and which program owns a particular file. Safari makes no concession to the older way of doing things, and in some respects BarFly hasn't yet caught up. Phil Taylor To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] ABC and MusicXML
On 25 Mar 2004, at 22:14, I. Oppenheim wrote: Are many ABC programs currently capable of generating MusicXML ? There's a command-line Windows/Linux abc2xml There's also BarFly (Mac) and Noteedit (Linux). At the moment, BarFly only imports MusicXML. Export is still to come. Phil Taylor To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] Re: ABC 1.x continuations
On 16 Mar 2004, at 14:52, I. Oppenheim wrote: On Sun, 14 Mar 2004, Phil Taylor wrote: It's a pretty outrageous example. I don't think that parsers should have to deal with continuations in the middle of inline fields, let alone an example with another (non-inline) field inserted in the middle. In ABC 2.0, continuations and ordinary comments will typically be dealt with by the scanner, before the parser even sees them. Yes but this was the example: X:1 T:some made up tune M:4/4 K:Dminor abcd|efga|[K:\ M:3/4 G]def|gab| after dealing with the continued line you get this: X:1 T:some made up tune M:4/4 K:Dminor abcd|efga|[K:M:3/4 G]def|gab| Whether you choose to handle this in the parser or in a preprocessor, the result still aint legal abc. Phil Taylor To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] Exporting to Midi.
On 16 Mar 2004, at 19:03, Christian M. Cepel wrote: I'm sure this has been covered before, but does anyone have a favored way of generating a midi file from abc? I own ABC2Win, and have been playing with BarFly. I've been unable to redirect PlayQABC output to the midi synth to a file... I would think it's possible, but I've not been able to figure it out. So.. looking for favorite methods... preferably a player that's aware of the Rhythm R: field, rolls and repeats and the like and plays them correctly PlayQABC may be primitive, but it does alright :) Thanks Oh.. btw.. operating systems avail are Win2k, MacOsX, and *nix, provided admin access is not necessary. BarFly will do most of what you want under MacOS X; however, there is a bug in Quicktime 6 which causes long notes to be truncated (played staccato) when generating a midi file. If you can use Quicktime movie files instead of midi it's not a problem. Likewise if you can use a pre- OS X operating system you can use Quicktime 4 (last good one). The problem happens when the delta time for note lengths requires more than two bytes to express it, so another possible work around is to generate the midi file at a fast tempo to keep all delta times within two bytes, then use a midi editor to change the tempo. Phil Taylor To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] Re: ABC 1.x continuations
On 16 Mar 2004, at 20:50, Steven Bennett wrote: Steven Bennett writes: | It was an outrageous example on purpose. It's *definitely* not legal ABC | 2.0, but the definition I was hearing implied that it would be legal ABC | 1.*. Which I didn't think it *ought* to be. Which is why I offered my own | definition of what the actual 1.* behavior ought to be. | | That said, the following is perfectly legal in ABC 2.0, by the definition | currently in the August draft spec: | | X:1 | T:some made up tune | M:4/4 | K:Dminor | abcd|efga|[K:\ | G][M:3/4]def|gab| | | It's just not legal in ABC 1.*. IMHO. Well, I'd agree that it's legal ABC 2.0, but I'd also claim that it should work under the earlier standards. I don't see any reasonable way that a parser would classify the last line as anything other than music, which is the same type as the continued line. It's not a header line, because it doesn't have a ':' in column 2. It doesn't start with '%'. What else could it be except music? The problem I have with considering that as legal, is that it could just as easily have been written like this: X:1 T:some made up tune M:4/4 K:Dminor abcd|efga|[\ K:G][M:3/4]def|gab| If the one is legal in 1.*, the other should be. But this second one is a whole lot more ambiguous for a parser. It's just as well if we avoid the problem by treating *both* as illegal in 1.*, since it's unlikely anyone would actually want to use either form. And by doing so, you drastically simplify the parsing process. (Okay... You drastically simplify *my* parsing process. grin Someone using a different approach might find what you are suggesting easier to deal with...) Certainly if the one is legal then the other should be too. However, I suspect that neither is legal, since inline fields were not legal in 1.x. (Well they weren't legal in 1.6. I didn't pay too much attention to 1.7 since it was such a mess.) I think the tune would have to have been written like this: X:1 T:some made up tune M:4/4 L:1/4 K:Dminor abcd|efga|\ K:G M:3/4 def|gab| (That used to be the main reason for using continuations, so you could place fields in the middle of a line, while still writing the field definition on a line to itself.) Phil Taylor To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] Re: ABC 1.x continuations (was ABC 2.0 draft)
On 12 Mar 2004, at 23:24, Steven Bennett wrote: I. Oppenheim wrote: As for the 1.6 and 1.7.6 specifications, regardless of what program X, Y, or Z does, the written spec is awfully vague. I have several possible approaches to different elements of this, but the basic concept appears to be that \ at the end of a line isn't so much a continuation, but a don't break the staff here if you would normally. No. In 1.* it basically meant: continue on the next line of the same type. (Whereas in 2.0 it means: continue on the next physical line, regardless of the context) I don't think I can accept that definition, even though looking at the archives, I've seen that definition before. It implies far too many things which are problematic and not at all true for the programs I have here. Of course, I've only been testing with Barfly 1.52 and abcm2ps 3.7.18 right now. Doubtless other programs behave differently. Problem 1: It implies that you could break a line arbitrarily. For the ABC 2.0 style continuations, that is indeed the case, but we're talking about a 1.* specific parser here, where you can have other lines in-between. So if you allow breaking a line arbitrarily, you could end up with something like this: X:1 T:some made up tune M:4/4 K:Dminor abcd|efga|[K:\ M:3/4 G]def|gab| ...which would need to cache part of the first line (the [K: part) until the next tune data line arrived and it had the remaining info it needed to finish parsing stuff. Even without the meter change in the middle, both Barfly and abcm2ps give parse errors on that. It's a pretty outrageous example. I don't think that parsers should have to deal with continuations in the middle of inline fields, let alone an example with another (non-inline) field inserted in the middle. And it doesn't need a field -- try something like: abcd|efga|c'\ ''def|| ...and you still get errors with both programs, even with nothing inbetween the lines. Doesn't the standard say somewhere that the symbols which form a note cannot be split across line continuations? Even if it doesn't, it ought to. Likewise a lyric line would need to cache partial syllables. Take: X:2 T:another made up tune M:4/4 K:Dminor abcd|efga|bcde|| w:a1 b2 c3 d4 e5 f6 g\ w:7 a8 b9 c10 d11 e12 Now here, Barfly apparently only uses the abc 2.0 style continuations (for lyric lines - odd that it doesn't do the same for tune data lines...), It's supposed to. With the best will in the world I can't always cope with seriously strange interpretations of abc syntax like the above, even if they are technically legal. so it always ends up with gw:7 as a syllable, but ends up with the syllables in the right place. abcm2ps renders this with the g and the 7 as separate syllables, so all the following syllables are off by one note. All of which leads me to conclude that under 1.*, you cannot continue a tune line or a lyric line at any arbitrary character point -- you need to continue it at a point where a staff or lyric line break would be valid. In practice, yes. Problem 2: It doesn't have any inherent limitation on what line of the same type could be. Which means you could continue just about any sort of line. Such as: X:3 T:yet another made up tune M:4/4 K:Dminor abcd|efga|[K:G]\ M:3\ bcde|\ M:/4 def|gab| ...complains about the split Meter line in both Barfly and abcm2ps. (With or without the intervening bcde line...) So it appears to me that it can't work with just any arbitrary field -- IMHO, the only fields it even makes sense to use it on (under 1.*) are tune body lines and lyric lines. And even then it causes all sorts of problems. So... If it can only occur on tune and lyric lines, and it can only occur where a staff break or lyric line break would be valid, then that is why I suggested a definition along the lines of: A backslash (\) at the end of a line means do not break the staff or lyric line at this point if that's what would happen because of the following line ending. It becomes pretty straightforward (actually fairly easy) to parse if you define it that way, and seems fairly consistent with the 1.* usage. Anyone see any gaping holes in that logic? You have still left open the question of whether programs should look for a simple continuation on the next line, or look for a field identifier if appropriate. (e.g. a w: field) Phil Taylor To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] Continuation Lines
On 10 Mar 2004, at 23:39, Steven Bennett wrote: Hi! I'm in the process of writing Yet Another ABC Parser as part of a larger project I've been working on for a while. (There are umpteen jillion reasons why I'm not using an existing parser - the biggest being this one is written in Objective C, but that's besides the point...) Ideally I'd like this to be able to handle files which conform to ABC 1.6, ABC 1.7.6, and the ABC 2.0 draft spec (dated Aug 14, 2003), but there are numerous little quirks and differences. The quirk I'm wrestling with today is Continuation Lines, which seems to be the biggest single area (and the biggest can of worms on the list archive) where the 1.6 1.76 specs seriously conflict with the 2.0 draft spec. Files written one way will parse ONLY if you use the 1.6/1.7.6 method, and files written another way will parse ONLY with the 2.0 method. And I don't see any mechanism (short of a good AI) to figure out which way during the parse. So I'm going to implement both and allow the user to decide which to use via a runtime switch. So... The 2.0 continuation line specification is almost trivial to implement. The only area which could use a bit of clarification there is it's effect during History fields. For example: ... H: This is some history This continues the history So does this And this too %%and this isn't an xcommand % But is this a comment? If you display % the history field, is it included? % I believe the answer should be No... And what about this? X \ Would this appear on the same line as the X \ If the history was displayed to the user? (IMHO, Yes) And here's the real challenge: \ % oh boy O: Is this the Origin or part of the History? I think it's part of the history myself And that *this* line is the last line of the history. O: This is the real origin... ... Does this interpretation of the ABC 2.0 variant make sense? Comments aren't actually part of the history field, and continuations *do* apply? I'd agree with that, although since most of it is an abuse of the H: field it doesn't really matter! (Meaning that it's pretty obvious how the H: field is intended to be used, and programs can't really be blamed if they get a bit confused with strange constructions like the above.) As for the 1.6 and 1.7.6 specifications, regardless of what program X, Y, or Z does, the written spec is awfully vague. I have several possible approaches to different elements of this, but the basic concept appears to be that \ at the end of a line isn't so much a continuation, but a don't break the staff here if you would normally. The spec is indeed very vague. I have always interpreted it in the way specified in abc 2.0, and I see that spec as essentially a clarification of the previous ambiguity. However you may come across some abcs which interpret the spec differently. Taking that as a given, then \ would only be meaningful on tune body or lyric lines, and ignored (possibly generating warnings) on other fields. It would not allow putting field-like text inside a History field as described above. You would also require the w: at the start of the continued lyric line, unlike 2.0 which would require it NOT be there. Does anyone see anything I'm missing here? The question becomes how to deal with comments. I saw plenty of discussion of whether the \ is ignored if it follows a comment, or whether it's invalid if it isn't the very last character on the line. I guess it depends on whether you look for the \ first or the comment first. Is there any consensus out there as to which is the proper approach when you are parsing files using pre-2.0 continuations? (Or should I make *that* a user switch as well...) My own program has always permitted continuations in non-tune fields, and ignored the \ if it's not the last character in the line. Phil Taylor To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] ABC and Jazz notation
On 11 Mar 2004, at 14:52, John Chambers wrote:
Giovanni Ferro Luzzi writes:
|
| I am quite a new user of ABC, and would like to ask if it is
| possible to use jazz notation for chords symbols (with no notes),
| as follows:
|
| A7 Edim7 G-7 D alt.
| __
| __
| __
| __
| __
|
| so that the chords appear in boldface above the staff (or in the
| middle of it), but nothing else in the staff.
Chords have to be attached to notes or rests, but a lot of
abc software has long accepted 'x' as a rest ('z') that
isn't drawn. This is useful for producing uncluttered,
blank staff space. It also works with some abc software for
what you want. I tried the following tune with abc2ps,
and it worked fine:
X: 1
T: TEST: Chords Only
K: C
| Dmx2 Gmx2 | A7x2 Dmx2 |
This gave me a staff with the chords evenly spaced above
the staff, but nothing on the staff except the three bar
lines.
I don't know how many other abc programs will accept this.
Works fine in BarFly, as long as you add an M: field (M: none is fine).
(What's a D alt chord by the way?)
Phil Taylor
To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] Newbie Attempt at Bach Minuet 1
On 11 Mar 2004, at 15:26, John Heim wrote: X:1 T:Minuet 1 C: Bach, Johann Sebastian Z:John Heim M:3/4 L:1/4 K:G d(dd)BA/2B/2GA(dc)B2Adc/2B/2A/2G/2ec/2B/2A/2G/2FE/2D/2FG2 d(dd)BA/2B/2GA(dc)B2Adc/2B/2A/2G/2ec/2B/2A/2G/2FE/2D/2FG2 Be2^cB/2^c/2Adefe/2d/2^c/2B/2Aag/2f/2e/2d/2bg/2f/2e/2d/2^cA^cd2 dc/2B/2ABA/2B/2Gc2c/2B/2A2dc/2B/2A/2G/2ec/2B/2A/2G/2FE/2D/2FG2 Be2^cB/2^c/2Adefe/2d/2^c/2B/2Aag/2f/2e/2d/2bg/2f/2e/2d/2^cA^cd2 dc/2B/2ABA/2B/2Gc2c/2B/2A2dc/2B/2A/2G/2ec/2B/2A/2G/2FE/2D/2FG2 Bar lines would be nice. You can use / as a shortcut for /2, which makes the tune more readable. Also it helps to insert spaces between all the notes which aren't beamed, as this also improves readability. Phil Taylor To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] Newbie Attempt at Bach Minuet 1
On 11 Mar 2004, at 16:00, John Heim wrote: At 09:45 AM 3/11/2004, Phil Taylor wrote: Bar lines would be nice. [...] I'll have to ask my teacher what those are. :-) OK! I'm not just a newbie to ABC music I'm a newbie to music. I went blind a few years ago and decided to learn how to play the violin. Bach Minuet 1 is on the first Suzuki violin CD. That's how far I've gotten so far. In fact, I'm kind of iffy on the concept of a key, and very iffy on meter. we just haven't covered thos concepts yet. Well good luck to you. The things I pointed out will all make the abc easier for a sighted person to read, but I'm not sure whether or not they would matter to you. But I couldn't find Minuet 1 anywhere else so I figured I'd give it a shot. And why not. Phil Taylor To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] unfolding og repeats
On 24 Jan 2004, at 21:15, Atte André Jensen wrote: Atte André Jensen wrote: Is there any (pref. linux-based, commandline and open-source) software outthere that will unfold repeats? Thanks for the replies. So you're all suggesting that I go abc-midi-abc. This is not really ideal since *alot* of information obviously gets lost along the way. Are there other options? how about abc-musicxml-abc? MusicXML would preserve the repeats, rather than expanding them as happens with midi, so you'd end up with the same abc. If you really want to do this you'll have to write a (fairly basic) abc parser. Phil Taylor To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] unfolding og repeats
On 25 Jan 2004, at 21:44, Laura Conrad wrote: Phil == Phil Taylor [EMAIL PROTECTED] writes: Phil If you really want to do this you'll have to write a (fairly basic) Phil abc parser. Maybe the abc2abc program that comes with the ABCMIDI package could be modified fairly easily? I suspect you'd have the same problem as you would with conversion abc - midi - abc, i.e. some information would get lost. What you really need is a very basic parser which ignores everything in the abc apart from the repeats, simply passing it through unchanged. Phil Taylor To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] quarter tones (non-12 tone music)
On 21 Jan 2004, at 21:55, Jeff Senn wrote: On Jan 21, 2004, at 12:49 PM, John Chambers wrote: This does seem like a possibly desirable use of the substitution-type macro. I've seen microtone notation that uses an assortment of symbols. If we allowed notation like ^3/24, people might not always want to type all that. John- What did you mean by this? Do you refer to the !something! notation? Or is there some *real* macro proposal? Not just a proposal but a working implementation in use in BarFly for many years. John's suggestion would work. Given the macro definition: m: Pn = ^3/24n any note marked with a P would be rendered as ^3/24, and I could have the program interpret that as a real pitch. Not that I think that a particularly useful approach, since as Jack says, musicians who use these pitches don't think of them as fractional; we really should not adopt something which is totally at odds with existing musical practice. Phil Taylor To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] is BarFly going to interwork with GarageBand?
On 13 Jan 2004, at 10:32, Jack Campin wrote: I read about this on the latest TidBITS Digest. Some interesting possibilities here? http://www.apple.com/ilife/garageband/ GB looks to me like a poor man's CuBase, i.e. it deals primarily with audio tracks. CuBase can also include midi tracks, and has a music notation window which can display and edit midi as musical notation. I doubt if GB does even that - it's aimed at people who are not musically literate, but want to play around with multi-track audio. If that's the case I don't see a lot of scope for interworking with BarFly. If the AppleLoop format is documented I suppose I can add that to the export options. Phil Taylor To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] *portable* representation of a very simple 3-part piece?
On 13 Jan 2004, at 10:30, Jack Campin wrote: big snip If we're going to use ABC as an alternative to notations like Margo's original one on Usenet music forums, we need to do better than this. Can anybody come up with a version of the above piece which (a) displays and plays on BarFly (perhaps for now without doing the part order correctly, that can always be faked by a lot of copy and paste) (b) displays with abcm2ps (c) retains the source-readability of the above - this is essential as the notation would be posted to forums where most users have no previous experience of ABC and will object violently to gibberish in %% lines. Several problems here. Most important is the use of parts which don't actually fit together as notated. Also the continuation character \ is ambiguous when used in multi-voice. In BarFly it means continued on the next line. In abc2ps it means continued on the next line of the same type. It's such a small piece that it really would make sense to write it out in full: X:2 T: He Diex! quant verrai T: Adam de la Halle M:3/4 L:1/8 V:1 t=-12 V:2 t=-12 V:3 t=-12 K:F Lydian [V:1] c4 fg | a4(3gfe | d4 ef | gf ed B2 | c6|] [V:2] f4 f2 | ed e2 (3edc | B4 c2 | dc d2 e2 | f6|] [V:3] F4 F2 | A4A2| G4 A2 | G4G2 | F6|] % [V:1] c4 fg | a4(3gfe | d4 fg | a4(3gfe | d4 || [V:2] f4 f2 | ed e2 (3edc | B4 f2 | ed e2 (3edc | B4 || [V:3] F4 F2 | A4A2| G4 F2 | A4A2| G4 || % [V:1] |: fg | a4(3gfe | d4 ef | gf ed B2 |1 c4 :|2 c6 |] [V:2] |: f2 | ed e2 (3edc | B4 c2 | dc d2 e2 |1 f4 :|2 f6 |] [V:3] |: F2 | A4A2| G4 A2 | G4G2 |1 F4 :|2 F6 |] This works in BarFly and in abcm2ps, apart from the octavo markings, which BarFly gets from the t=-12. Not sure how to do that in abcm2ps. Phil Taylor To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] abcm2ps questions
On 2 Jan 2004, at 08:15, Frank Nordberg wrote: Jon Freeman wrote: OK, so I've not long back changed folkinfo to at least enable those who premit cookies to select a preference between letter and A4 for printing pdf files from the site. Should I also consider allowing 9 x 12 as a paper size or is that pretty much reserved for publications? I don't think that should be necessary. A4 seems to be the standard paper size all over the world. USA and Canada are the only important exceptions, and they both go for US letter. For those who are interested in further reading about the topic, try: http://www.cl.cam.ac.uk/~mgk25/iso-paper.html A fascinating site for the true nerd. It also has a link to this site: http://homepage.virgin.net/vernon.jenkins/PS.htm This is a site dedicated to biblical numerology, wherein the author proves quite conclusively that the dimensions of the A4 page, along with other features of the ISO 216 stationery standard including the number 216 itself were fortold in the Bible. We must therefore enjoin our American cousins to forsake their pagan paper sizes (letter, legal ledger etc.) and cleave only to the one true stationery standard prescribed in holy scripture. And a Happy New Year to all of you! Phil Taylor To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
[abcusers] test
My last post to abcusers a couple of days ago disappeared without trace. I don't know if it bounced, because I don't see bounce messages any more. (They look like spam and get rejected by my software; I now get so much spam that I've given up checking the rejected messages.) So this is just a test. Phil Taylor To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] [CEG]4
On Tuesday, December 9, 2003, at 10:04 AM, Atte André Jensen wrote: I discovered that abcm2ps accepts both [CEG]4, [C4E4G4] and [C4EG] and in each case does exactly what I would expect. But now I'm wondering how standard these variations are? Both in terms of the Real ABC Standard and in terms of how many programs handles this... [C4EG] is the format which was required by the earliest versions of abc2ps. and produced a chord with all notes of length 4. Some programs allow notes in chords to have different lengths, so this will produce different results in different programs. [C4G4E4] should work everywhere. [CGE]4 has been suggested as a shortcut form, but I don't know how many programs support it (BarFly doesn't). Phil Taylor To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
[abcusers] BarFly v1.52 available
There's a new version of BarFly available. No new features this time, just a maintenance release with bug fixes. The Carbon version also catches up with some of the newer Mac OS features (proxy window icons, the dot in the close button which indicates that there are changes to be saved etc.). Please see the New in this Version file for details. Get it as always from http://www.barfly.dial.pipex.com Phil Taylor To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] Keyboard layout
I've played around with keyboard mappings too, but eventually concluded that nothing else is going to be faster than the conventional layout. One thing I have found useful though is to use the ctrl and alt modifier keys to get octave shifts. An option in BarFly causes ctrl-A to give a' and alt-A a''. With the shift key down as well you get the lower octaves, so shift-ctrl-A gives A, and shift-alt-A gives A,,. (The ctrl key is not used for menu equivalents on the Mac, we've got another key for that.) Phil Taylor To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] Drone notes
On Saturday, October 25, 2003, at 03:43 AM, Bill Taffe wrote: Hi All, Please excuse a novice question. I have some music where I'd like to put in drone notes. Putting the note in as a note in a chord for each other note is cumbersome and doesn't really represent what's being played. Does the current abc have a syntax to do this? No. You can sort of do it in the way that Frank suggested, by putting in another voice filled with tied notes, but it's a bit cumbersome, and complicates the abc unnecessarily. Some abc player programs offer you the option to play a drone while playing the abc (abcMus, BarFly and maybe others) but there's no way to write this into the abc. Perhaps there should be an official syntax for this, something like: %%drones C G or K:Hp drones A A A, Phil Taylor To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] Re: fretboard abc in G
On Tuesday, October 21, 2003, at 02:15 PM, T Barlow wrote: How does the abc fretboard layout in G? Is this close? Guitar: tunedabc Ee f g a' Bb c d GG a DD EF AA B C E E, F, G, Not sure about the other instruments, but guitar music is conventionally written an octave higher than it sounds (so it fits on a treble staff). Same goes for abc, I suppose. Try this tunedabc Ee f g a BB c d GG A DD EF AA, B, C EE, F, G, Note that the octave changes when you go from B to c, not when you go from G to A. Phil Taylor To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] Multivoice in ABC 2.0
Barry Say wrote: On 16 Oct 2003, [EMAIL PROTECTED] wrote: I do not like the unnecessary proliferation of inline fields of ABC2.0. I don't think its unnecessary. If you want to change clefs in mid line, for instance. I don't like using the K: field to indicate cleff since most of the tunes that use the V: field to date don't specify a K: for each V: (as I mentioned in the documentation of iabc). That is, most people expect voices to 'inherit' the key specified in the K: field. To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html My major objection to inline fields is encapsulated in the statement from ABC2.0 rev IV --- To avoid ambiguity, inline fields that specify music properties should be repeated in each voice. For example, ... P:C [V:1] C4|[M:3/4]CEG|Gce| [V:2] E4|[M:3/4]G3 |E3 | P:D ... - the need to align the meter change in every voice seems a great problem in parsing. What action does the program take when one voice out of eight does not align. You need to place a metre change in all of the voices (if that's what you want) since you can have voices in different metres. (It's not common, but it does happen, and not only in avant-garde music - Bach did it occasionally.) ABC 2.0 states For backward compatibility, it is still allowed to notate tune fields on a line by themselves, between the music lines: ed|cecA B2ed|cAcA E2ed|cecA B2ed|c2A2 A2:| M:2/2 K:G AB|cdec BcdB|ABAF GFE2|cdec BcdB|c2A2 A2:| If we are considering multivoice notation, this seems a far more sensible way to notate global key and meter changes than having to match inline fields in all voices. Yes, that's perfectly acceptable, but you still need to put fields in all of the voices to which they apply. There's nowhere in the tune body where you can place a single field and have it apply to all voices. Phil Taylor To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] Clarification wanted on abc draft standard 2.0 (fwd)
Stephen Kellett wrote:
In message [EMAIL PROTECTED], Phil Taylor
[EMAIL PROTECTED] writes
In message [EMAIL PROTECTED], Phil Taylor
[EMAIL PROTECTED] writes
a) Symbols can be on notes, rests and bar lines
Bad Idea. This breaks all existing programs which support aligned words,
and any existing files which include aligned words and rests.
Forgive my ignorance, why is this a bad idea? Have I misunderstood the
spec? I'm writing my parser/player/display program. I've already
implemented the above and it was not hard to achieve (I can make the
symbols attach to anything in the markup, pretty much).
Then anyone who uses your program to make abcs with aligned words will
find that their files don't work properly with any other software.
Likewise they will find that in any files they download from the net
the lyrics won't align properly.
As far as I can see this doesn't answer the second question (am I
mistaken, or are you just disagreeing with ABC2.0 and not my
interpretation of it), and only states that the proposed ABC2.0 spec is
more advanced than the programs to which you refer (but do not name) in
their current state.
The second question was Have I misunderstood the spec?. I don't think
so. In fact the spec (see below) is ambiguous, so you can be forgiven
for taking a different interpretation to everybody else, provided that
you realise the consequences.
This is no more different than putting an ABC file
with V: voicing into ABCWin - it doesn't like it. I don't think anyone
is claiming ABCWin is broken because the standard has advanced past its
capabilities.
It's very different. The introduction of the V: field represented a new
extension to abc. It did not invalidate abc2win's existing data files,
and its use could be avoided by newer programs if the user wanted to
achieve backwards compatibility with abc2win. And it was a very important
extension in that it made available whole swathes of music which could
previously not have been represented in abc. What you are proposing is
not a new extension, but a change in the interpretation of an existing
one. This means that programs which work in the way you suggest will
interpret existing files differently, and not in the way that their
authors intended. And all of this just to enable the alignment of
lyrics with rests and bar lines? That's a whole can of worms being
opened to achieve an infinitesimal extra feature.
My program will be backwards compatible. If you've aligned your words on
notes that is fine. Using my app you can align on notes/rests/barlines
as the spec dictates.
How will it be backward-compatible? These are two different and totally
incompatible sets of behaviour. You could give your users the option
of interpreting aligned lyrics one way or the other, but it would be
quite difficult to make this choice automatic.
I made a mistake in my previous posting. The ABC2.0 draft spec actually
includes note groups and doesn't specifically disallow grace notes.
Given that the spec does not define note group (or if it does I
haven't found it), I am not sure if a note group is
a) ABC
which is notes next to each other
b) [ABC]
which is chords
c) {abc}
which is grace notes - these are clearly grouped in one sense.
d) either of (a) (b) (c)
\
I don't know what abc2.0 draft you are reading but it doesn't say
anything about note groups under section 5, Lyrics:
-
5. Lyrics
The W field (uppercase W) can be used for lyrics to be printed separately
below the tune.
The w field (lowercase w) in the body, supplies a line of lyrics to be
aligned syllable by syllable below the previous line of notes. Syllables
are not aligned on grace notes and tied notes are treated as two separate
notes; slurred or beamed notes are also treated as separate notes in this
context. Note that lyrics are always aligned to the beginning of the
preceding music line.
It is possible for a music line to be followed by several w fields. This
can be used together with the part notation to create verses. The first w
field is used the first time that part is played, then the second and so
on.
The lyrics lines are treated as an ABC string. Within the lyrics, the words
should be separated by one or more spaces and to correctly align them the
following symbols may be used:
-
(hyphen) break between syllables within a word
_
(underscore) last syllable is to be held for an extra note
*
one note is skipped (i.e. * is equivalent to a blank syllable)
~
appears as a space; aligns multiple words under one note
\-
appears as hyphen; aligns multiple syllables under one note
|
advances to the next bar
Note that if '-' is preceded by a space or another hyphen, it is regarded
as a separate syllable.
When an underscore is used next to a hyphen, the hyphen must always come first.
If there are not as many syllables as notes in a measure, typing a '|'
automatically advances to the next bar; if there are enough syllables the
'|' is just ignored.
Some examples
Re: [abcusers] Clarification wanted on abc draft standard 2.0 (fwd)
In message [EMAIL PROTECTED], I. Oppenheim [EMAIL PROTECTED] writes In most cases, lyrics are NOT wanted on rests, but I have seen some files which DO use lyrics on rests. There is obviously no indication as to which is intended when reading a file. The abc standard (draft 2.0) says nothing about lyrics on rests, but the need DOES occur in some circumstances. Is it possible to state, and include in the standard, what should be done? I think it is valid. The reasoning is as follows: a) Symbols can be on notes, rests and bar lines Bad Idea. This breaks all existing programs which support aligned words, and any existing files which include aligned words and rests. If such a fundamental change from existing practice is to be contemplated we will need some way of marking files to show that they are to be interpreted in the new way. This is an awful lot of trouble to achieve something which can be achieved much more easily by restricting non-musical lyrics to percussion notation. It is not manadatory for abc to support every strange construction which anyone has ever used in staff notation. Phil Taylor To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] Clarification wanted on abc draft standard 2.0 (fwd)
In message [EMAIL PROTECTED], Phil Taylor [EMAIL PROTECTED] writes a) Symbols can be on notes, rests and bar lines Bad Idea. This breaks all existing programs which support aligned words, and any existing files which include aligned words and rests. Forgive my ignorance, why is this a bad idea? Have I misunderstood the spec? I'm writing my parser/player/display program. I've already implemented the above and it was not hard to achieve (I can make the symbols attach to anything in the markup, pretty much). Then anyone who uses your program to make abcs with aligned words will find that their files don't work properly with any other software. Likewise they will find that in any files they download from the net the lyrics won't align properly. If such a fundamental change from existing practice is to be contemplated we will need some way of marking files to show that they are to be interpreted in the new way. I couldn't see (from reading 1.7.6 and 2.0) what the difference was, except that 2.0 provided me with more information to work with (i.e. 2.0 stated it was notes/rests/bar lines, where as I don't 1.7.6 stating that (implying it was everything). As far as I can see all of the existing standards mention only lyrics aligning with notes, and while they specifically state that gracenotes are not included, make no mention of rests or bar lines. Existing software (e.g. BarFly and abcm2ps) interpret this to mean that rests and bar lines are to be skipped. Admittedly the standards are a little ambiguous here, but there is a well-established precedent, and lots of files which will be broken if you make a different interpretation. It is not manadatory for abc to support every strange construction which anyone has ever used in staff notation. I don't mind, I'm not pushing an agenda. I'll implement what other people want. My understanding was notes/rests/bar lines. If I've misunderstood, please tell me and provide clarification as to what the standard is. There are lots of examples of songs with aligned words at http://folkinfo.org/songs/. If your software displays these correctly then you're on the right lines. If not, please think again! Phil Taylor To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] Clarification wanted on abc draft standard 2.0 (fwd)
In most cases, lyrics are NOT wanted on rests, but I have seen some files which DO use lyrics on rests. There is obviously no indication as to which is intended when reading a file. The abc standard (draft 2.0) says nothing about lyrics on rests, but the need DOES occur in some circumstances. Is it possible to state, and include in the standard, what should be done? Under what circumstances would you want a word or symbol in the lyrics to align with a rest? Phil Taylor To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
[abcusers] BarFly update
I've put up a new BarFly (v1.51), which fixes a few bugs in version 1.5, including: Problems exporting pictures under OS X (Carbon version). A memory leak when displaying music (Carbon version). Use of ` or non-breaking space as a text spacer caused a problem if the symbol was before a slur parenthesis. (all versions). http://www.barfly.dial.pipex.com Phil Taylor To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] uppity typesetting
Jack Campin wrote: (BTW, is there any way to get the barline before the clef OUT of the current BarFly's staff notation, without correcting every PICT it makes with a graphics editor? - having typeset hundreds of tunes with older versions of the program using the no-initial-barline convention, I now find that I can't replace older score files without a glaring mismatch in house style, and I don't find the new way an improvement). The behaviour of BarFly hasn't changed in this respect. If you're seeing a line at the left end of the staff, I'd guess that you are putting in a V:1 field, i.e. you are choosing to write single voice abc as multivoice. You may have a good reason for doing this, as there are some features which are only obtainable in multivoice, but that's the reason for it. The line is actually the brace which groups staves together; since you've only got one staff in this case it just looks like a bar line. Phil Taylor To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] ABC as Tablature; being my entry in the Obfuscated ABC Contest
Fascinating! I always knew that somebody would come up for a use for the middle directive which involved shifting the notes by an amount different from an octave. The experimentation which produced that was not too difficult using BarFly, except for that insane numerical transpose notation; keeping the middle= and transpose directives consistent is a huge pain in the arse. Nobody but a guitarist ever thinks of intervals by counting semitones, and in this case (unlike a lute) there is no advantage to be gained by any matching with the tab formalism. Transposing by a fixed number of semitones makes sense in the normal situation, where you want to keep the tune in the same mode, but simply have it played in a different key. In this case, what you need is for the program to play the tune as it appears in the music, and there's no way of doing that using a straightforward transposition. Shifting the note pitches by means of the middle directive is like putting a capo on an Appalachian dulcimer - you change the mode as well as the pitch. You can't make your X:2 version play the same as the X:3 version, even though they produce the same staff display. The second part of the tune sounds good, but I'm not convinced by the first part. It's mainly the big interval from g to E which sounds odd. Then again, we're used to hearing tunes composed for the fiddle, where that would be a difficult interval to play. On a diatonically - fretted instrument tuned in the way you suggest it would be perfectly easy, and might have been common in tunes of the day. How many more tunes are in the MS? Does the same logic produce reasonable sounding music from the others? What you really need here is a program which would accept the original tab and convert it to abc given a set of assumptions about the tuning and fretting of the instrument. You could then experiment with different tuning and fretting schemes until you find one which produces consistently meaningful results for all the tunes in the MS. Phil Taylor To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] Re: backslashes
Wil Macauley wrote: grumble then you've got to figure out how to put the cursor in the right place after you've done all this, if the user made a mistake /grumble What I do in BarFly is to first record the text selection start and end in two variables, then extract a copy of the tune to work on (which itself involves moving the selection positions around), pass that to the preprocessor and on to the parser. Finally I put the text selection back where it was. What gets really tricky is when you need to work back from the final result to the original text (as when the user clicks on a note head to get the equivalent bit of text highlighted in the abc). The preprocessor has to keep track of all the indels it has created so that the program can calculate what position in the original text corresponds to that in the preprocessed copy that the parser works on. I haven't yet figured out how to make this work for nested indels, which is why the program won't allow graphic selection if macros are enabled for display. Phil Taylor To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
[abcusers] abcm2ps hangs
I'm seeing some problems with the Mac version of abcm2ps (v3.6.2) where it hangs up on certain tunes and has to be killed. This is an example: X:32 T:Wren's Nest, The C:Frankie Gavin R:jig D:De Dannan: Anthem. Z:id:hn-jig-32 M:6/8 K:Edor GAB ded|cAA A2c|BGE EFG|AFD AFD|GAB ded|cAA A2c|BGE AFD|1 GEE E2F:|2 GEE E2D|| |:E2e d2B|cBA B2A|GAB ~d3|cAA BAG|E2e d2B|cBA B2A|GAB cAB|GEE FED:| |:B,EE GED|B,EE E2D|B,EE GAB|AFD AFD|B,EE GED|B,EE E2F|GAB cAB|1 GEE FED:|2 GEE E2F|| (beware of line-wrap: tune consists of three lines.) abcm2ps reports line 11 as overfull and then hangs. Is this a peculiarity of this version or is it more general? Phil Taylor To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] bass clef and transposition
When using clef=bass in a V: or K: field, and use abcm2ps for typesetting, notes are automatically transposed 2 octaves down. I think abc2ps also does this. This reduces the number of commas needed to notate low notes. That's nice but I don't read anything about this in the abc2-draft document. Yaps for example does not behave like this. When using yaps you can use I:clef=bass octave=-2 to accomplish the same effect. Is there any concensus about what should be the notation standard for notes in the bass key? The abc2-draft doc only describes notation in the treble key. In abc 2 you will specify the behaviour of notation programs by means of the middle directive. middle = d (or just m=d) means the program should place the note written as d on the middle line of the staff (as the abc2ps family of programs do now if there is a bass clef). write m=D, to get the default behaviour of yaps or BarFly. You can place this directive in K: or V: fields. middle applies only to staff notation and is ignored by players. There is a similar directive transpose = n (or t=n) for player programs, which shifts the pitch as played by n semitones. Phil Taylor To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] P: and V:
Irwin Oppenheim wrote: On Thu, 7 Aug 2003, Jack Campin wrote: P:A [V:V1] C G C [V:V2] E B E P:B [V:V1] A E A [V:V2] C G C So, would it be correct to state that P: resets the music generator when encountered in the tune body, and that the above example should thus be equivalent to the following: P:A K:C [V:A1] C G C [V:A2] E B E P:B K:Am [V:B1] A E A [V:B2] C G C BarFly doesn't do this correctly yet, but in effect each part needs to be interpreted as if it were a different tune, assembled into a medley under the control of the P: header line. There will be some funnies if global properties like key are reassigned within a part. I must admit that I do not understand this description. How do other programs handle P:/V: interaction and in what aspects does BarFly differ? Current BarFly versions have a bug which makes playing of tunes with multiple voices and part-order a bit unpredictable, but this: X:1 T:test M:C P:ABAB K:C P:A [V:1] C G C [V:2] E B E P:B [V:1] A E A [V:2] C G C will display as expected, but not play properly beacuse the P:A field is not contained within any voice, while the P:B field is logically located at the end of the first line of voice 2, and not present at all in voice 1. You could write it like this: X:2 T:test 2 M:C P:ABAB K:C [V:1][P:A] C G C [V:2][P:A] E B E % [V:1][P:B] A E A [V:2][P:B] C G C Which displays the same as X:1, and _ought_ to play properly once I get around to fixing it:-) Phil Taylor To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] ABC 2.0 rc 4
Henrik Norbeck wrote: I haven't been able to follow the discussion closely, since I'm away on vacation. Forgive me if I repeat things that have already been discussed, but here are a few important things I want to point out: 3.1.13. H: - The multiline version should be deprecated, i.e. the version where every line begins with H: is preferred. Why? I don't see why fields which simply contain text should not continue until the next field identifier is reached (N: too, as long as it's in the header). 3.3.5. %%abc-include - Why use .abh as an extension? Why not .abch? Or are we still limited to 8+3 chars for file names? Why do we need to specify an extension at all? 4.3. Note lengths: There should also be an example of e.g. A3/ as shorthand for A3/2 Yes. 4.17. Chords and unisons: The possibility to use broken rhythm markers and with chords should be explicitly mentioned. Yes. 4.18. Chords symbols: To avoid confusion with [] chords, maybe these should be renamed to backing chords or something similar. Yes. 2.2. Continuation of input lines: The way it is defined for w: fields is unacceptable to me. There's been a lot of discussion of this over the last few weeks. That's not to say that the subject is closed, of course, but you'll probably want to review your back mail before starting a new discussion. Phil Taylor To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] Page break formatting
Richard Robinson wrote: On Wed, Aug 13, 2003 at 12:25:19AM -0400, Tom Keays wrote: The system Phil proposes below wouldn't work at all for me. That is to say, I know I wouldn't use it even if he went to the trouble to implement it. I think, therefore, that I can only support them if they are placed immediately adjacent to the tune to which they apply - either immediately before the X:, or at the end of the tune before the blank line which indicates its end. Umm. Somebody's already mentioned the TuneFinder here, haven't they ? And it's a point - An app that picks selections of tunes out of an abc file would treat the 2 cases differently, no ? %%newpage X:1 T:What ? K:C aaa aaa|] and the parser kicks in at the X: and the tune is extracted starting with the X:, the %%newpage isn't part of the tune. But X:1 T:What ? K:C aaa aaa|] %%newpage and the parser stops on the blank line, the %%newpage is extracted as part of the tune. I'm not sure this is desirable behaviour ? It runs into a much more general question, actually - if you re-order tunes in an ABc file, how do you handle any interposed non-ABC text, where should it go ? I don't think there's a clean answer to this. I think you are right. BarFly doesn't re-order the original file though, it just pulls the tunes out for printing in the specified order, ignoring the interstitial text. You can always read the text, and if you want you can print the contents of the file as text. Since BarFly's editor can handle embedded pictures, I could also at some point add a command which would replace the abc tunes with pictures, leaving the interstitial text between them. Printing that would be a nightmare though. On the whole though I think that forced pagebreaks and other such printing options are better handled outside of the abc in my case. Perhaps I could add a symbol to the index to indicate that this tune should start a new page. If the index was sorted differently that tune would still carry the mark, so it would be obvious to the user. Phil Taylor To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] Page break formatting
Tom Keays wrote: Originally, my problem was more complicated (as I will explain). According the BarFly manual: Most of the problems you are likely to encounter concern the placing of page breaks. BarFly will always place page breaks between tunes, between staves in a tune or between lines of words if the music has words following the tune. I asked for the %%newpage feature to solve this problem -- ie, I didn't want tunes splitting between pages. For the next version I'm going to offer the user three options when printing. Tunes may be printed: * Contiguously (as at present). or * Without splitting short tunes across pagebreaks (as abcm2ps does). or * Starting a new page with each tune (also an option in abcm2ps). (short here means less than a page in length.) Phil Taylor To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] abcm2ps hangs
On Thu, Aug 14, 2003 at 03:37:21PM +0100, Phil Taylor wrote: I'm seeing some problems with the Mac version of abcm2ps (v3.6.2) where it hangs up on certain tunes and has to be killed. Just as a data point, your example works fine for me, with 3.6.3 on Linux (and it doesn't report any overfull lines). Hmm, it couldn't be a problem of page size I suppose? That tune hangs for me when invoked without any command line switches, just abcm2ps infile.abc. About 1% of Henrik's transcriptions do it, and the postscript output ends at the previous tune. Phil Taylor To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] Page break formatting
I've been asked recently by several BarFly users to support %%newpage (or something similar) to force a page break when printing. Thinking about this I find there's a problem with implementing it (and similar directives which are placed between the tunes in a file). BarFly can print any selected subset of tunes from a file, and you also have some control over the order of printing. Under these circumstances, %% directives which are not attached to any tune (but between a pair of tunes) are ambiguous. I think, therefore, that I can only support them if they are placed immediately adjacent to the tune to which they apply - either immediately before the X:, or at the end of the tune before the blank line which indicates its end. Comments? Phil Taylor To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] Page break formatting
John Walsh wrote: I've been asked recently by several BarFly users to support %%newpage (or something similar) to force a page break when printing. Thinking about this I find there's a problem with implementing it (and similar directives which are placed between the tunes in a file). BarFly can print any selected subset of tunes from a file, and you also have some control over the order of printing. Under these circumstances, %% directives which are not attached to any tune (but between a pair of tunes) are ambiguous. I think, therefore, that I can only support them if they are placed immediately adjacent to the tune to which they apply - either immediately before the X:, or at the end of the tune before the blank line which indicates its end. Comments? Phil Taylor Two other possibilities come to mind: either only accept them if the whole file is being printed, or only if they come between two tunes which have been selected for printing. (The canny user, after all, can edit the file or copy the portion to another file. Or check the box (which you'll add) Ignore pagebreaks. Or are you worried about person A putting in the pagebreaks, and person B printing out something received from JC's tunefinder, and not having any idea why all these pagebreaks are appearing? The point is that the program treats tunes as individual entities, displaying an index of titles which can be sorted in various ways (alphabetically, numerically by ID or by position in file). When the user issues a print command, the program retrieves the selected tunes from the index in the current order, creates a picture of each, and then fits the pictures together to make printed pages. Under these circumstances, %% directives which are not attached to a particular tune are meaningless. Phil Taylor To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] Re: backslashes
Wil Macauley wrote: No, because application A might handle %%MIDI and ignore %%pagesize The way I planned to handle pseudocomments was to look for particular strings like %%MIDI and ignore anything else that starts with % - so I wouldn't even know it was a pseudocomment unless it was a specific thing I parse. That's what BarFly currently does. Not that I handle many pseudocomments, just %%midi and %%staves, and even there there are better ways of doing those things. Again, that's why you'd use pseudocomments, so that it transparently extends the language. Yep. Phil Taylor To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] man
John Chambers wrote: There has been some study of this sort of problem with the advent of computer GUIs. Any study quickly proves that most of the users use only a tiny fraction of the GUI's capabilities. The reason is that they don't know about the other semi-magical things that they could do. They don't suspect that most of the capabilities even exist, and they don't know how to ask or what to ask for. Watching someone else doesn't help much, because you usually can't see what they did with the keyboard or mouse, and you don't see any pattern in what changes on the screen. And most of it isn't documented anywhere. What documentation exists is mostly incomprehensible to users. While this is true to some extent of any computer system, it is much, much less of a problem with a GUI than it is with a command-line system. GUI-based programs have menus with meaningful words which describe the commands that they can execute. If you are looking for a way to perform some operation that you've never done before, you just pop up all the menus until something catches your eye which looks as if it might be appropriate. Then you try it, secure in the knowledge that if you are doing something dangerous the program will a) warn you, and b) give you an Undo command or c) work on a copy of the original data so you don't lose anything. With a CL interface you issue commands by typing, and typing long complicated words is a drag, so the common commands are very terse. Because they're terse they are necessarily cryptic. If I didn't know how to rename a file in Unix, how would I ever guess that the command is mv? I might guess that that means move (which it does), but not that re-naming the file is a side effect. If I want to perform the same operation in Windows or Mac OS I just click on the file name to highlight it and type the new name. Of course, mv will allow me to do more complicated things like moving/renaming a whole bunch of files at once, but that's a sufficiently uncommon operation that I'd have to go and read the blasted man page to remind myself of how to do it:-) If anyone comes up with a good solution to this problem, it will be a major advance in documentation. My wife, who used to be computer-phobic, recently got a copy of Photoshop 7. This is a professional image editing system of enormous power and complexity. She hasn't asked me how to use it, and the manuals are still in their clingwrap. Nevertheless, she's showing me pictures where she's changed the colour balance, added captions, removed objects that spoil the composition etc. How long would it have taken her to achieve the same results if it had been a CL driven program? Phil Taylor To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] man
Bob Smithers wrote: On Tue, 5 Aug 2003, Jack Campin wrote: :The paper editions of the Unix manuals used to have a keyword-in-context :index of all the commands - usually browsing that would give me an idea. :I presume there is an electronic copy of the same thing somewhere on all :Unix systems. Try: $ apropos keyword Tried that earlier. $ apropos backspace Nothing found $ apropos back space Thousands of lines of hits containing either string. There probably is a keyword that will get it, but I couldn't find one. Phil Taylor To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] Re: backslashes
Jack Campin wrote: 1. continued lines cannot have a trailing comment 2. pseudocomments cannot be continued The current text of ABC 2.0 does not allow either. Ad. 1: Comments can not be included on lines that end with a backslash. That would make it impossible to comment out a block of text without editing it first, since many other kinds of line might end with backslashes. And then you'd have to remember where the backslashes used to be when undoing the commenting-out. I hadn't thought of that. Commenting out part of an abc tune by placing % at the beginning of each line is a useful debugging technique. Anyway, I think we've moved on from that position, and the developing standard now allows 1. (or am I confused?) Commenting-out could well introduce pseudo-pseudo-comments. I doubt we can do anything about that. :-) Phil Taylor To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] Floating voices
Wil Macauley wrote: Given Bernard's statement, and that we are proposing incompatibilities anyway, I would propose that you only use a line if you _DO_ want barlines between staves. In other words, the default is not to join staves, but you can put a line between if you want barlines. That's certainly the logical way to do it. Phil Taylor To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] (uffa) Standards vs. quality...
Guido Gonzato wrote: On Fri, 1 Aug 2003, I. Oppenheim wrote: I tested it also with: ...abcMus, abacus, muse, skink and barFly; then I gave up. none of which nears abcm2ps when it comes to printed output quality. I don't think any of those programs claim to produce publication- quality printed music. Music typesetting is not the only function of abc. It's not even the most important function of abc. While abcm2ps is a magnificent program it's not very good at playing, transposing, generating midi, automatic harmonisation etc. You can't use it for editing your abc, and it's not even very good at producing fixed-resolution pictures of music for display on a website. If abcm2ps was the only abc program abc would be much less popular than it is. Under no circumstances should we allow one (functionally limited) program to dominate the development of the standard. Of all those, Abcm2ps was the only app that had no problems with the \ business in all it's glory, ahum... it's also the only applications that gives you publication-quality scores. That's why NoteEditor uses abcm2ps as its typsetting engine. It's up to other packages' developers to catch up with abcm2ps. If I were the author of such a good program, I'd refuse to lower quality for the sake of standard compliance. Nobody's proposing a lowering of quality, as far as I can see. All of the applications are going to have to be re-written to conform with the new standard; there's no reason why abcm2ps should be an exception to this. It's now time to tell you a story. Turbo Pascal died on the Mac, because it wasn't as good as TML Pascal, a Mac-only development system which was already available. I'll repeat that to the end of my days: people's needs FIRST, then standards compliance. Yes, but whose needs are we talking about? You seem to think that it's the minority of abc users who want to produce professionally printed music who should take precedence over everybody else. It should be clear that the two of us have different goals, but I don't think what we're doing is incompatible. Nor me. Phil Taylor To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] w: stuff \
John Chambers wrote: Yeah; jcabc2ps implements the simple-minded continued on next line scheme from the new proposed standard. Here's how it would work: X:1 T:TEST:Shenei Zeitim M:4/4 K:C G|G2G2A4|(FEF) D (A2G) G|\ [M:4/4] [K:C] c2c2(B2c2)|(f2e2)e2d G| w:She-nei zei-tim nich-__ra-tim_ \ be-gan na-'ul_ yats-_hi-ru. Le- G|G2G2A4|(FEF) D (A2G) G|\ [M:4/4]\ [K:C ]\ c2c2(B2c2)|(f2e2)e2d G| w:She-nei zei-tim nich-__ra-tim_ be-\ gan na-'ul_ yats-_hi-ru. Le- Yes, that works in BarFly too. One problem with this scheme, of course, is that \ at the end of a comment appends the next line to the comment. This is easy to understand, but it does mean that it's difficult to have embedded comments as was done above. This is one of the reasons why a lot of languages have bracketing comment delimiters, often in addition to the to end of line comments like abc's % comments. I've several times felt the need for comments which could be embedded in a line. Perhaps the !..! (or whatever symbol is currently favourite) could be used - !%This is a comment! Also, note the missing w: on the continuation lines. If you include the initial w:, it will be taken as the start of a new syllable. Same in BarFly. | In conclusion: if you don't like the \ mechanism, fine: I can't have you | change your mind. But the example you provided was wrong. I wouldn't be so hard on Irwin. When I see this sort of confusion about how a mechanism is supposed to work, I find it more useful to observe that the mechanism is too complex. It's common for people to design something far too complex for its users, and then say user error when they misuse it. This is the common excuse for lots of disasters that were actually caused by an unusable design. Rather than feeling smug about how stupid the users are, I'd much rather design something that's simple enough that they will use it right. (Don't lose heart Irwin, you're doing a great job of withstanding the flak so far:-) This isn't so much a matter of right and wrong; it's more a matter of where you want to place the blame when it doesn't work right, and how you want to fix the problem. (BTW, it would be better to have an example where the meter and key really do change. I can't tell from the output whether jcabc2ps is correctly handling the key changes, since failure produces the same output as success in this example.) Yes. BarFly puts the redundant meter and key signatures in, but of course K:C is invisible anyway. Phil Taylor To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] ABC20-draft review
Arent Storm wrote: * ~ I always thought that ~ is used for a prall-trill by default. Hardly anybody will know what an Irish-roll is (is it eatable?) I'll bet there are at least a hundred times as many abc users who know what an Irish Roll is as there are those who recognise what a prall-trill is. Actually, I think the English word for it is Pralltriller, but most people would call it an upper mordent, and in abc it's normally represented by the letter P. The meaning of ~ is context-dependent. In classical music it will mean a turn (that's what the symbol looks like), and in most places a turn symbol in the staff notation will be correct. What kind of twiddle gets played depends on the tradition that the music comes from. * clefs: Is K: Am transpose=-2 illegal where K: Am treble transpose=-2 is not No. transpose (or t=) is a directive which affects only playing and has nothing to do with clefs, so both are legal. ''clef'' starts the specication (I'd rather like to see clef=clefname than clef alone Why? The clef names treble, alto, tenor and bass are all unique identifiers which can't mean anything but a clef, so clef= is redundant. More complicated clef specifications should use the clef= syntax though. *voices state that all voices to be mentioned in the abc-body have to be declared in the header when using the [V:ID] syntax, where each ID will be referenced over and over. It's good practice, but I don't see why it should be mandatory. Phil Taylor To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
[abcusers] %%staves
I still have some problems understanding the %%staves directive,
and it still strikes me as being extremely cryptic compared with
putting the same information into V: fields in the header.
The draft standard says that:
when enclosed by curly braces `{}', the voices go on a single couple of
staves (keyboard score). There cannot be more than 4 voices between the
braces.
So what's the difference between
%%staves {1 2 3 4}
and
%%staves (1 2)(3 4)
and if I write:
%%staves {1 2 3}
which hand is voice 2 on?
It seems to me that the use of {} here is both redundant and
ambiguous.
Phil Taylor
To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] ABC Standard 2.0 revision III
John Chambers wrote: In Ryan's case, the p.37 examples do have a double bar before the repeat colon - at the end of the preceding staff. This may have been the origin of that perverse :|!: example that we saw recently. If the ! means new staff, this would exactly match what Ryan did. It's also what ABC2Win does. I was astonished to find that now it also works in BarFly when it's in its emulate ABC2Win mode. In any case, it's pretty clear that publishers' notation and people's interpretation of repeats are both far from standardized. No matter what we do or say, people will type the abc that looks like their own (mis)interpretation of any supposed standard. Printed music doesn't much work as a guideline, because it is so varied, and people can say Look, these books do it that way, so it must be standard. People writing abc players have a problem ... Not really. Just treat any of :| |] [| || or |: as a start of repeat when playing. It just means that you can't use any of those symbols within a repeated section. The only one I would want to use is the double bar, and I've never yet seen a piece of music which did that (but thousands of tunes where the above rule works correctly). Phil Taylor To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
