Re: [abcusers] Use of ! (and another source issue)
On Tue, 22 Jul 2003, Jean-Francois Moine wrote: to me it seems OK: as long as major developers add this feature (and I imagine it's very easy to implement), I can see no reason not to include ` in the standard. Yes, very easy: I had to change only 3 characters in the parser... I was sure you would add it easily... Jef, you're great :-) Ciao, Guido =8-) -- Guido Gonzato, Ph.D. guido . gonzato at univr . it - Linux System Manager Universita' di Verona (Italy), Facolta' di Scienze MM. FF. NN. Ca' Vignal II, Strada Le Grazie 15, 37134 Verona (Italy) Tel. +39 045 8027990; Fax +39 045 8027928 --- Timeas hominem unius libri To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] copyright sign
In message [EMAIL PROTECTED], Jack Campin [EMAIL PROTECTED] writes This is one thing that can easily be written in ASCII, as (c) or copyright in some appropriate field; I use the Z: field most of the time because every time I've wanted to make the point I've been the copyright-holder, but it could go in C:, A:, D: or B: as well. As long as you realise that (C) is not a copyright sign legally. That must be wrong or else source code could never be copyrighted. No, it's quite right. I've forgotten web site references but it's quoted in every document I read. ... and why not put © in a source code document if you want? (Not that copyright needs an explicit sign any more anyway - the point of the sign is to say who the copyright holder is, not to be a juju creating the legal status). Agreed. But the sign must be © or the word copyright. The documents say that (C) is not sufficient. Bernard Hill Braeburn Software Author of Music Publisher system Music Software written by musicians for musicians http://www.braeburn.co.uk Selkirk, Scotland To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] copyright sign
On Wed, 23 Jul 2003, Bernard Hill wrote: Agreed. But the sign must be © or the word copyright. The documents say that (C) is not sufficient. According to the international copyright conventions, the word copyright followed by a name, followed by a year, is enough. The copyright sign © is not required and the ASCII variant (C) has no legal status at all. Copyright Irwin Oppenheim 2003. To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
[abcusers] New draft special characters
After a week away I'm reading the draft 2.0.0. Doubtless I will have other comments which I will make but simply the special characters: (a) I presume the list is not exhaustive. ie É (Capital E acute) and the like (b) I think we need a copyright symbol. \C or \OC. Maybe also R-in-a- circle although I don't know what it means. (c) Why is £ \243? While I can of course implement it, it makes no sense. Ascii £ is 156. \L would be better. The same comment goes to the other symbols, \ is ascii 92, but how about \/ (d) Other symbols for discussion: crossed C for the cent sign? The accented Y and y? Paragraph marker §? (e) is cedilla C really to be \ c space c? Why not \c? Bernard Hill Braeburn Software Author of Music Publisher system Music Software written by musicians for musicians http://www.braeburn.co.uk Selkirk, Scotland To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] copyright sign
On Wed, 23 Jul 2003, Bernard Hill wrote: Remember there are no International Copyright Conventions. Some countries don't have *any* copyright regulations. The basis of international copyright law as we know it today is the Berne Convention from 1886, to which the US finally signed... in 1988! There were earlier copyright agreements, but Berne is really the watershed in Europe. The United Nations has an department that deals solely with international copyright legislation: the WIPO, or World Intellectual Property Organization. See www.wipo.org Groeten, Irwin Oppenheim [EMAIL PROTECTED] ~~~* Chazzanut Online: http://www.joods.nl/~chazzanut/ To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] multivoice linecontinuation
- Original Message - From: Phil Taylor [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, July 22, 2003 6:21 PM Subject: Re: [abcusers] multivoice linecontinuation Arent Storm wrote: Where it comes to to line continuation in multivoice and/or in-line lyrics things can get (unneccessarily) complicated. IMO line continuation should be allowed only for single voice. For instance, the nicely text-layed-out multivoice canzonetta.abc from the 2.0 standard would become unreadable with line continuation used. Yes, I'm inclined to agree. The only exception should be where there is some limitation on line length (e.g. the tune is going to be emailed), then continuation should only be used to continue on the following line. I'd much prefer the ! for those (rare?) cases that you'd want to override the algoritmical linebreaks, and forget about linecontinuation at all, but I'm afraid that I'll be standing on many toes... Also, when using abc to store complex scores, I think that human readablity is of very small importance, if at all; it will be uncomprehensable anyway. Not all multivoice scores are impossible to read. Jack Campin has some beautifully-constructed abcs of tunes in two or three voices. Not impossible, but in general there will be very little need for it, I guess that sight-readers of ABC will haveno need for it, so it'll be more otr less pointless to try. The 3 different approaches of writing down multivoice I dislike. I would very much prefer one approach the: voice by voice Sight readers will be thus allowed to read their part as easy as they're used to. V1: abc|abc|abc|abc def|def|def:| V2: Abc|Abc|Abc|Abc Def|Def|Def:| over [V1]:abc|abc|abc|abc| [V2]:Abc|Abc|Abc|Abc| [V1]:def|def|def:| [V2]:Def|Def|Def:| Would there be abc-sight-reading conductors? and (least) V1: abc|abc|abc|abc| V2: Abc|Abc|Abc|Abc| V1: def|def|def:| V2: Def|Def|Def:| compatible but useless IMO I'd prefer them in the order 2,3,1. The first is what MusiCAD is exporting, while importing all three. As said before - in multivoice scores - human readability won't have to be/should not be/cannot be a major issue. BarFly won't be able to display the output from MusiCAD, then. Why not give your users the option of all three? If MusiCAD prints music it must know where the line ends should come, so options 2 and 3 should be possible. Its not impossible, only requires a major rewrite of the abc-writing module I'll be (trying) to comply to the upcoming standard though, but as long as option 1 actually is in the standard I'm complying already... Arent To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] multivoice linecontinuation
From: I. Oppenheim [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, July 22, 2003 6:36 PM Subject: Re: [abcusers] multivoice linecontinuation On Tue, 22 Jul 2003, Phil Taylor wrote: Yes, I'm inclined to agree. The only exception should be where there is some limitation on line length (e.g. the tune is going to be emailed), then continuation should only be used to continue on the following line. I would prefer it STRONGLY that the end-of-line backspace would always mean: continue on the next physical line of music. YES However it seems that there is legacy code around that expects these lines: % variant A G2G2A4 | (FEF) D (A2G) G|\ M:4/4 K:C c2c2(B2c2) | to be interpreted as equivalent to: % variant B G2G2A4 | (FEF) D (A2G) G| [M:4/4] [K:C] c2c2(B2c2) | So I would like to know from you all, if any of you would have serious problems if from now on, backward compatibility with variant A would be discontinued in favour of a simpler continuation mechanism. Hmmm... Let's please forget about the headaching variant A % variant 2 [V1]:abc|abc|abc|abc| [V2]:Abc|Abc|Abc|Abc| [V1]:def|def|def:| [V2]:Def|Def|Def:| I'd prefer them in the order 2,3,1. I also prefer variant 2. Anyone who strongly disagrees? I must note, however, that it should be [V:1] and not [V1]: ! Ooops (of course) Groeten, Insgelijks ;-) Irwin Oppenheim Atent To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] multivoice linecontinuation
From: Laura Conrad [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, July 22, 2003 6:52 PM Subject: Re: [abcusers] multivoice linecontinuation Irwin == I Oppenheim [EMAIL PROTECTED] writes: Irwin % variant A Irwin G2G2A4 | (FEF) D (A2G) G|\ Irwin M:4/4 Irwin K:C Irwin c2c2(B2c2) | I think this is actually an example of a recommended syntax in some pretty widespread documentation. (Probably something that comes with abcMIDI or abc2ps.) So you can deprecate it, but you aren't going to be able to not handle it, if you want to deal with what's out there. Is it used often? Arent To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] New draft special characters
In message [EMAIL PROTECTED], Bernard Hill [EMAIL PROTECTED] writes After a week away I'm reading the draft 2.0.0. Doubtless I will have other comments which I will make but simply the special characters: (a) I presume the list is not exhaustive. ie É (Capital E acute) and the like (b) I think we need a copyright symbol. \C or \OC. Maybe also R-in-a- circle although I don't know what it means. (c) Why is £ \243? While I can of course implement it, it makes no sense. Ascii £ is 156. \L would be better. The same comment goes to the other symbols, \ is ascii 92, but how about \/ (d) Other symbols for discussion: crossed C for the cent sign? The accented Y and y? Paragraph marker §? (e) is cedilla C really to be \ c space c? Why not \c? And to add to my own post... what about circle-above-A and its lower case equivalent. Bernard Hill Braeburn Software Author of Music Publisher system Music Software written by musicians for musicians http://www.braeburn.co.uk Selkirk, Scotland To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] multivoice linecontinuation
- Original Message - From: Jack Campin [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, July 23, 2003 1:41 AM Subject: Re: [abcusers] multivoice linecontinuation As said before - in multivoice scores - human readability won't have to be/should not be/cannot be a major issue. Why bother with ABC at all, then? Look at the Atalanta Fugiens scores on my webpage. The way I have laid them out, anybody - including a blind person - can read them vertically and figure out the harmony at every point. Or this (needs a window with 96 columns, fixed-width font): X:5 T:Meine Seel' erhebt den Herren S:Bach/Riemenschneider #358 C:J.S. Bach M:C L:1/4 V:1 V:2 V:3 bass V:4 bass K:GMin V:1 d2 f2 |d d d d |e2d2 |c2c2 |HB4 | V:2 G2 F2 |F ^F G A |G F2 G |G2F2 |HF4 | V:3 B,2 C2 |D C B, A,|B, C2B,|B,2 A,2|HD4 | V:4 G,2 A,2|B, A, G,^F,|G, A, B, G,|E, C, F,2|HB,,4| % V:1 d2 f2 |c c c G |B2A2 |HG4 | V:2 F4 |F F E G |G2 ^F2 |HD4 | V:3 B,4|A, C C C |D3 C |HB,4 | V:4 B,2 D,2|F, A, G, E,|D, C, D,2 |HG,,4| % V:1 d2 f2 |d d d d |e2d2 |c2c2 |HB4 | V:2 G2 A2 |F3 ^F |G A B2- |B B B A|HF4 | V:3 B,2 C2 |D C D2|D C B, F |G2F C|HD4 | V:4 G,2 F,2|B, C B, A,|B, C F, D,|E, C, F,2|HB,,4| % V:1 d2 f2 |c c c c |c2G A|B2 A2 | G4-|G4- |G4 |H G4 |] V:2 z4 |F G A B |c2C2 |D2 D C |=B, D G F |E4- |E2 D C |H D4 |] V:3 z2 F, G,|A, B, C2- |C D =E ^F|G2=F E | D =B, C D-|D G, C2- |C2 =B, A,|H=B,4 |] V:4 B,, C, D, E,|F,3 G,|A, B, C2 |B,, C, D, E,| F,2 E, D,|C, D, E, F,|G,4 |H G,,4|] (Note, this is deliberately *not* designed for good staff notation output - I've put each line of the chorale as a separate system in the ABC source, the last one would be denser than the first three). I guess I'm to use a non proportional font to benefit optimally... ;-) If you can't make your ABC source human-readable you shouldn't be using it. If all you want is staff notation, Finale or Sibelius will do it better. At some expense... It's the other uses of ABC that make it unique, and most of those uses depend on readability. I'm just using abc as 'second language' enabling my users to use already written abc, and to provide the abc-community with the MusiCAD user groups files http://muzamus.dse.nl (dutch) Aremt To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] New draft special characters
On Wed, 23 Jul 2003, Bernard Hill wrote: (a) I presume the list is not exhaustive. ie É (Capital E acute) and the The table only gives a number of examples for each class of supported accents. (b) I think we need a copyright symbol. \C or \OC. The second revision of the 2.0 draft (soon to be released) will solve this issue. Briefly, there will be defined a field called %%abc-copyright, in which any occurrence of the string (C) is to be replaced by the copyright symbol: %%abc-copyright (C) Copyright John Smith 2003 Maybe also R-in-a- circle although I don't know what it means. It means that you registered a trademark with the government trademarks bureau. (c) Why is £ \243? While I can of course implement it, it makes no sense. Ascii £ is 156. Watch out: 156 is decimal, while the number behind the backslash should be the octal code of the character, which is 234 (and _not_ 243, which was a typo!) (d) Other symbols for discussion: crossed C for the cent sign? The accented Y and y? Paragraph marker §? The second revision will allow you to code the free text that appears inside the ABC file, in any of the standard character sets, among which iso-8859-1 (Latin-1) and UTF-8. To this end, there will be introduced an %%abc-charset field: %%abc-charset iso-8859-1 (e) is cedilla C really to be \ c space c? Why not \c? This has also been corrected. It should have been \Cc and \,C on the one hand, and \cc and \,c on the other hand. Groeten, Irwin Oppenheim [EMAIL PROTECTED] ~~~* Chazzanut Online: http://www.joods.nl/~chazzanut/ To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] About the choice of '!'
From: Jean-Francois Moine [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, July 22, 2003 10:10 PM Subject: Re: [abcusers] About the choice of '!' On Mon, 21 Jul 2003 13:08:29 +0200 (CEST), Guido Gonzato [EMAIL PROTECTED] wrote: [snip] BTW - Jean-François, how do you tell whether '!' is a line break or the start of a decoration? When encountering a '!', I scan forward. If I find any of |[:] (and soon a blank or tab), or the end of line, it is a line break. Else, if I find a '!', it is a decoration. This means that a decoration name cannot contain any of these characters (for instance, '!da Capo!' or '![rit]!' will not work, while '!crescendo(!' is OK). Does this solve all the problems? Sounds fine to me. Arent To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] linebreaks and paper sizes
From: Jack Campin [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, July 23, 2003 1:38 AM Subject: [abcusers] linebreaks and paper sizes BarFly makes ignoring linebreaks an option (except for multi-voice music where it isn't practical); what I do sometimes is first let the program have a go at doing the layout, then optimize the result by putting explicit linebreaks in better places myself. BarFly's spacing algorithm is not very sophisticated (monospace type printed on elastic), but the same approach would be handy for any program. As I see music engraving, you should care about linebreak/pagebreak just before you start printing. You never know the paper size beforehand do you? I do. It's always A4, either portrait or landscape. Which implies in fact two sizes; if it will fit on landscape it won't fit an portrait (unless you use a square portion of it)... Much of my users seem to like to have marching-band sized paper (something like 15 x 10cm) landscape. For the tunes on my CD-ROMs, the GIF scores (generated by BarFly) are intended for practical use by folk instrumentalists who operate the way I see them working in Scotland: everybody (beginners to pro ceilidh bands) uses A4 folders with clear plastic pouches. The music in them is usually portrait layout, be it printed, xeroxed or hand- written. So I design for that use; my users will print the tunes themselves as needed and arrange them in whatever categories they want. (Epicycle: I try not to use the full height of A4, so American users can fit my stuff onto their letter size without rescaling; I presume they use the plastic pouches too). For the flute CD-ROM, I did every tune in both portrait and landscape; that stuff is significantly more complex than the Embro, Embro or Aird tunes, and often landscape layout works better. Harder to use on a stand, but I was expecting people to use the scores for memorization rather than in performance. In many cases (and increasingly as LCD screens become more prevalent) people will simply learn the tunes off the computer screen (maybe aided by sound files) and never print them. There are so many advantages to this format that hopefully I've just killed the printed-and-bound tune anthology. But what I really want is singing digital paper. or even hornpiping papers (all of them slightly out of tune...) Wouldn't that be great ;-) Arent To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] Re: continuations
From: Phil Taylor [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, July 23, 2003 2:59 AM Subject: Re: [abcusers] Re: continuations John Chambers wrote: Another fringe case is what happens when a line ends with '\', a space, and a newline. It's common for many implementations to not recognize this as a continuation. This one is really baffling to a user, who usually can't see the space. The right way to handle this is to strip off the trailing spaces (and tabs), and then check for the final '\'. The input routine is now not quite as trivial (though it's still pretty trivial). BarFly does that (at least for spaces - I'm not sure about other whitespaces). Another thing that's a problem is % comments following the backslash. That's more complicated to deal with, and I'd like to see it illegal. I'd second that! Arent To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] My proposal
On Sun, 20 Jul 2003, John Chambers wrote: Tom Novelli writes: | I think I'd better rethink my proposal, since (as expected) it's been | soundly rejected by several folk-tune collectors whose support is needed. | I have ideas for a better format (IMHO) for transcribing tunes; besides | correcting some mistakes in ABC and borrowing a few things from NMD, it | would look more like a programming language... but I can convert it to ABC | for public consumption. Well, I for one would like to publicy encourage this. ABC is a fairly good notation, for what it is. But there are things that probably can't be done with it, without losing its primary role as a notation that's typable and readable by humans. Of course, if you're going to do this, you might want to take a good look at LilyPond first. You may decide that they've already done much of what you want. The practical approach may be to join that crowd. Hmm.. with western Mass. phone lines (good for 28.8 or so) it'd take me weeks to download lilypond, X, TeX, and libraries. Not worth the trouble. Besides, I can see why someone would prefer ABC -- especially for folk music. Or maybe we do want an intermediate notation that keeps as much of ABC's accessibility without worrying overly much about being very compatible. There is a lot of possibility here. This should be done in a separate discussion, however, maybe with a new mailing list. And check this list occasionally, so you can keep notifying people of the new effort. It may take some of the pressure off ABC to be all things to all musicians. That's a thought.. and with the pressure off ABC, we could rethink it a little, with compatibility in mind. Actually, the big ABC collections usually don't abuse ABC, but the format lends itself to abuse. Maybe what we need is a Guide to Writing Compatible ABC to define good ABC as a subset of what's permitted by all the various draft standards... sort of like the HTML Any browser campaign. I'm gonna sign off the mailing list for now.. it's too damn busy to keep up with :) I'll make it known when my ABC viewer is ready for the world. You could adapt it for your Tunefinder, so it just spits out a PBM without all the CPU time and pixel aliasing problems involved with Ghostscript... To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] My proposal
On Wed, 23 Jul 2003, Tom Novelli wrote: Hmm.. with western Mass. phone lines (good for 28.8 or so) it'd take me weeks to download lilypond, X, TeX, and libraries. Not worth the trouble. Bye yourself the complete set of Debian CDs, or get yourself a DSL/cable connection... Besides, I can see why someone would prefer ABC -- especially for folk music. Both ABC and Lilypond have there good and their week points. I'll make it known when my ABC viewer is ready for the world. You could adapt it for your Tunefinder, so it just spits out a PBM without all the CPU time and pixel aliasing problems involved with Ghostscript... That would be nice! Groeten, Irwin Oppenheim [EMAIL PROTECTED] ~~~* Chazzanut Online: http://www.joods.nl/~chazzanut/ To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] New standard(s)
From: Bernard Hill [EMAIL PROTECTED] not to speak of hemisemidemiquavers It's actually hemidemisemiquavers. But my Australian customers explicly told me they use hdsqs. And 1/128th notes are semihemidemisemiquavers You must be kidding! Ludicrous! Why? I admit that there is logic to the US terms, but I have to think carefully how many flags has a 1/32nd note? whereas I know a demisemiquaver has 3. Most musicians can translate though I must admit I cannot, then you have never read a British or Australian book on music I take it. I think that most books which are seeking for a large audience use quarter, eight etc. instead of the more antique semihemidemisemiquavers ore whatever. I am aware that there exists something like semihemidemisemiquavers but I'm quite sure that there are few dutch musicians who know to use them, unless you read a lot of UK-english books on that topic. I do have quite some books on the topic of music engraving but apparently non of them is using semihemidemisemiquavers. :-) nor can I make much sense of miles, fl.oz, Fahrenheit, gallons, and all those other outlandish measurements you guys have mantioned. I need a calculator most of the times, but is cannot transform semihemidemisemiquavers ;-) However personally I prefer the US terms in that area. It's not something specifically American; the fraction designations for note lengths are used and understood throughout the world, save for the United Kingdom, it seems. I can't speak for the world, but in the Netherlands: anyway. No, as I say it's also Australasia. In fact if you add up the countries or inhabitants it's probably more use the British terms. I know they do in many places in Europe, and I certainly have Dutch customers who use them when writing to me. Funny, they have been extraordinarily well been music-educated It's not something you encounter every day in the Netherlands And I didn't say we don't understand them. We are broad-minded enough to read US books and dictionaries and program notes etc. Here in continental Europe, we have Euros, kilometers, liters, celsius, and 1/128th notes, and we do not understand anything more exotic than that... Of course you do. don't be too sure... Fahrenheit isn't understood by most dutch since apart from the notion that it has something to do with temperature, and that 100F is different from 100C... You know about dollars and pounds for exchange rates. dollar=euro pound=??? (lookup somewhere) The French even have livres = pounds (weight). And I have read French technical articles on chemical engineering which refer to pouce = inch. From which century? The French started the SI system... To be honest, in Holland we used to have an ''ons'' for 100g en ''pond voor 500g but they are officially abandoned since a few decades, and fit in with the metric system. Arent To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] New draft special characters
In message [EMAIL PROTECTED], I. Oppenheim [EMAIL PROTECTED] writes On Wed, 23 Jul 2003, Bernard Hill wrote: (a) I presume the list is not exhaustive. ie É (Capital E acute) and the The table only gives a number of examples for each class of supported accents. (b) I think we need a copyright symbol. \C or \OC. The second revision of the 2.0 draft (soon to be released) will solve this issue. Briefly, there will be defined a field called %%abc-copyright, in which any occurrence of the string (C) is to be replaced by the copyright symbol: %%abc-copyright (C) Copyright John Smith 2003 Maybe also R-in-a- circle although I don't know what it means. It means that you registered a trademark with the government trademarks bureau. (c) Why is £ \243? While I can of course implement it, it makes no sense. Ascii £ is 156. Watch out: 156 is decimal, while the number behind the backslash should be the octal code of the character, which is 234 (and _not_ 243, which was a typo!) Octal! I've not used that for 30 years, I would never have considered it in a PC environment. ... but maybe 243 was not a typo: it's the Latin-1 coding (decimal 163) for £. Bernard Hill Braeburn Software Author of Music Publisher system Music Software written by musicians for musicians http://www.braeburn.co.uk Selkirk, Scotland To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] New draft special characters
On Wed, 23 Jul 2003, Bernard Hill wrote: Octal! I've not used that for 30 years, And I'm only 24 years old... I would never have considered it in a PC environment. It reveals the background of the ABC language, I guess... ... but maybe 243 was not a typo: it's the Latin-1 coding (decimal 163) for £. Now I double checked it, and you are correct! It should be octal codes according to the specified charset, which by default is Latin-1 Groeten, Irwin Oppenheim [EMAIL PROTECTED] ~~~* Chazzanut Online: http://www.joods.nl/~chazzanut/ To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] New standard(s)
In message [EMAIL PROTECTED], Arent Storm [EMAIL PROTECTED] writes From: Bernard Hill [EMAIL PROTECTED] not to speak of hemisemidemiquavers It's actually hemidemisemiquavers. But my Australian customers explicly told me they use hdsqs. And 1/128th notes are semihemidemisemiquavers You must be kidding! Ludicrous! Why? I admit that there is logic to the US terms, but I have to think carefully how many flags has a 1/32nd note? whereas I know a demisemiquaver has 3. Most musicians can translate though I must admit I cannot, then you have never read a British or Australian book on music I take it. I think that most books which are seeking for a large audience use quarter, eight etc. instead of the more antique semihemidemisemiquavers ore whatever. I suggest you consult Grove dictionary, or Oxford companion. I assure you that quarter notes are unknown by all except the professionals here in the UK etc: we learn quavers and minims from our first lessons. I expect the French do blanche and noire in the same way. It's nothing to do with antique: these are current, active names and professional musicians speak both English and American, if not French and German etc. Programme notes over here may refer to a cascade of quavers or whatever. The names are different in many languages: My Oxford Companion to Music gives a table which contains: English Italian French German American breve breve carrée doppeltakt-note double whole-note or breve ... minim minimablanche Halbe Half-note or bianca ... quavercroma crocheachtel eighth-note ... I am aware that there exists something like semihemidemisemiquavers but I'm quite sure that there are few dutch musicians who know to use them, unless you read a lot of UK-english books on that topic. I do have quite some books on the topic of music engraving but apparently non of them is using semihemidemisemiquavers. :-) nor can I make much sense of miles, fl.oz, Fahrenheit, gallons, and all those other outlandish measurements you guys have mantioned. I need a calculator most of the times, but is cannot transform semihemidemisemiquavers ;-) However personally I prefer the US terms in that area. It's not something specifically American; the fraction designations for note lengths are used and understood throughout the world, save for the United Kingdom, it seems. I can't speak for the world, but in the Netherlands: anyway. No, as I say it's also Australasia. In fact if you add up the countries or inhabitants it's probably more use the British terms. I know they do in many places in Europe, and I certainly have Dutch customers who use them when writing to me. Funny, they have been extraordinarily well been music-educated Not really: as I say, most musicians are bi-lingual in this respect. It's not something you encounter every day in the Netherlands And I didn't say we don't understand them. We are broad-minded enough to read US books and dictionaries and program notes etc. Here in continental Europe, we have Euros, kilometers, liters, celsius, and 1/128th notes, and we do not understand anything more exotic than that... Of course you do. don't be too sure... Fahrenheit isn't understood by most dutch since apart from the notion that it has something to do with temperature, and that 100F is different from 100C... I didn't say you understand Fahrenheit. I said you do understand something more exotic than Euros, kilometers [our spelling is ...metres], celsius and 1/128th notes, and gave you some examples. You know about dollars and pounds for exchange rates. dollar=euro nearly... pound=??? (lookup somewhere) The French even have livres = pounds (weight). And I have read French technical articles on chemical engineering which refer to pouce = inch. From which century? 20th. 1940s IIRC. Although I think it was spelled pousse :-( The French started the SI system... No, they started the metric system. SI was an international agreement in the 1950s and formalised in the 1960s. Metric previously included the cgs (Centimetre-gram-second), MKS (metre-kilogramme-second) and MTS (metre-tonne-second) systems. We were taught cgs for physics in the early 1960s at school in the UK, but SI was a slightly later acceptance. To be honest, in Holland we used to have an ''ons'' for 100g en ''pond voor 500g but they are officially abandoned since a few decades, and fit in with the metric system. Bernard Hill Braeburn Software Author of Music Publisher system Music Software written by musicians for musicians http://www.braeburn.co.uk Selkirk, Scotland To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
[abcusers] Readability of abc
Jack Campin wrote: If you can't make your ABC source human-readable you shouldn't be using it. If all you want is staff notation, Finale or Sibelius will do it better. It's the other uses of ABC that make it unique, and most of those uses depend on readability. As a user of abc I have to disagree. I use abc because it's easier to write out than most other methods, and is completely adequate for my uses (melody line with chord names for traditional music) so I don't need most of the extra complication of other software. I use abc to write out tunes to aid my memory and to communicate them to others through e-mail or printed notation. I use it for proofreading (or prooflistening I suppose) what I write. I use it to learn new tunes that others have written out - but I do that through listening or viewing written notation from Barfly. I never try to read music directly from raw abc files - I find even sloppily hand-written notation easier to read; and if I have the abc file I can see neat musical notation on screen (and print it if desirable) and I can listen to the tune as well. I won't say there's no reason to read abc notation at all, but I can say that I know a substantial community of traditional musicians in New Hampshire who use abc, and all use it to display musical notation, to listen to the tune in question and to exchange tunes; none use it to read directly. I suspect our usage pattern is pretty typical of the traditional music community in general. Peter To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] New draft special characters
Bernard Hill wrote: In message [EMAIL PROTECTED], I. Oppenheim [EMAIL PROTECTED] writes Watch out: 156 is decimal, while the number behind the backslash should be the octal code of the character, which is 234 (and _not_ 243, which was a typo!) Octal! I've not used that for 30 years, I would never have considered it in a PC environment. Yes that's always astonished me too. I guess it's something we've inherited from abc2mtext. I suppose TeX itself was probably started back in the 70s, on Digital machines which used a 12-bit word length. Octal made sense then, since four octal digits = 12 bits. Now we use 8-bit bytes, and multiples thereof, so we use hexadecimal as a shorthand for binary (two hex digits = 8 bits). The use of octal is laughably archaic today. Kind of like the unix man command. (Sorry guys, not wanting to start a platform-specific flame war, but I'm having to learn to love unix, and man in particular is driving me crazy.) Phil Taylor To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] multivoice linecontinuation
Arent == Arent Storm [EMAIL PROTECTED] writes: Also, when using abc to store complex scores, I think that human readablity is of very small importance, if at all; it will be uncomprehensable anyway. Not all multivoice scores are impossible to read. Jack Campin has some beautifully-constructed abcs of tunes in two or three voices. Arent Not impossible, but in general there will be very little Arent need for it, I guess that sight-readers of ABC will haveno Arent need for it, so it'll be more otr less pointless to try. Maybe there aren't that many people who sight-read ABC to perform, but presumably everybody (who isn't using some kind of GUI interface) reads their own ABC to correct errors. So making it unreadable is a way of making it unusable, because you'll have to get everything right the first time you type it, and I never do. I started using ABC instead of musixtex because I got eyestrain whenever I tried to read the musixtex input, and I continue to use it for data entry instead of lilypond because I find it faster to both type and read. If this advantage goes away, I'll figure out how to type lilypond and use templates for the untypeable stuff. -- Laura (mailto:[EMAIL PROTECTED] , http://www.laymusic.org/ ) (617) 661-8097 fax: (801) 365-6574 233 Broadway, Cambridge, MA 02139 To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] multivoice linecontinuation
Arent == Arent Storm [EMAIL PROTECTED] writes: Irwin % variant A Irwin G2G2A4 | (FEF) D (A2G) G|\ Irwin M:4/4 Irwin K:C Irwin c2c2(B2c2) | I think this is actually an example of a recommended syntax in some pretty widespread documentation. (Probably something that comes with abcMIDI or abc2ps.) So you can deprecate it, but you aren't going to be able to not handle it, if you want to deal with what's out there. Arent Is it used often? I used to use it and stopped because I always let the software determine the line breaks for me. But if I were still expecting to determine my own line breaks, I might still be doing it that way. -- Laura (mailto:[EMAIL PROTECTED] , http://www.laymusic.org/ ) (617) 661-8097 fax: (801) 365-6574 233 Broadway, Cambridge, MA 02139 To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] multivoice linecontinuation
On Wed, Jul 23, 2003 at 10:52:38AM -0400, Laura Conrad wrote: Arent == Arent Storm [EMAIL PROTECTED] writes: Also, when using abc to store complex scores, I think that human readablity is of very small importance, if at all; it will be uncomprehensable anyway. Not all multivoice scores are impossible to read. Jack Campin has some beautifully-constructed abcs of tunes in two or three voices. Arent Not impossible, but in general there will be very little Arent need for it, I guess that sight-readers of ABC will haveno Arent need for it, so it'll be more otr less pointless to try. Maybe there aren't that many people who sight-read ABC to perform, but presumably everybody (who isn't using some kind of GUI interface) reads their own ABC to correct errors. So making it unreadable is a way of making it unusable, because you'll have to get everything right the first time you type it, and I never do. That's a good point. Me too. Finding my way to a typoed note (I tend to make out-by-an-octave errors) is one of the, er, big minor irritations, and time-wasters, of typing tunes up. It helps a lot to have the ABC laid out in a comprehensible way. This is why I may well find myself gravitating towards the ! staffbreak, now it's available in abcm2ps. -- Richard Robinson The whole plan hinged upon the natural curiosity of potatoes - S. Lem To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] multivoice linecontinuation
On Wed, Jul 23, 2003 at 10:56:15AM -0400, Laura Conrad wrote: Arent == Arent Storm [EMAIL PROTECTED] writes: Irwin % variant A Irwin G2G2A4 | (FEF) D (A2G) G|\ Irwin M:4/4 Irwin K:C Irwin c2c2(B2c2) | I think this is actually an example of a recommended syntax in some pretty widespread documentation. (Probably something that comes with abcMIDI or abc2ps.) So you can deprecate it, but you aren't going to be able to not handle it, if you want to deal with what's out there. Arent Is it used often? I used to use it and stopped because I always let the software determine the line breaks for me. But if I were still expecting to determine my own line breaks, I might still be doing it that way. It was the original syntax, wasn't it ? It worked before the inline field [M:...] syntax was introduced, so there may be a lot of older tunes out there that have it. -- Richard Robinson The whole plan hinged upon the natural curiosity of potatoes - S. Lem To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] New draft special characters
On Wed, Jul 23, 2003 at 03:53:41PM +0100, Phil Taylor wrote: Bernard Hill wrote: In message [EMAIL PROTECTED], I. Oppenheim [EMAIL PROTECTED] writes Watch out: 156 is decimal, while the number behind the backslash should be the octal code of the character, which is 234 (and _not_ 243, which was a typo!) Octal! I've not used that for 30 years, I would never have considered it in a PC environment. Yes that's always astonished me too. I guess it's something we've inherited from abc2mtext. (abcmtext ?? abcmtex, I guess) I don't think so. Because abc2mtex used the TeX escape sequences, \a etc, for anything that isn't 7-bit ASCII; that's where those character sequences came from. As I remember it, I think the obscure-numbers stuff started coming in when people started using 8-bit well-it-works-on-my-character-set codes directly in preference to the TeX sequences. (Sorry guys, not wanting to start a platform-specific flame war, but I'm having to learn to love unix, and man in particular is driving me crazy.) Have a look in uk.comp.os.linux - there's an argument going on with lots of people saying how much nicer man is, compared with info :-) (I confess, I agree). -- Richard Robinson The whole plan hinged upon the natural curiosity of potatoes - S. Lem To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] multivoice linecontinuation
On Wed, Jul 23, 2003 at 04:03:36PM +0100, Richard Robinson wrote: On Wed, Jul 23, 2003 at 10:52:38AM -0400, Laura Conrad wrote: Arent == Arent Storm [EMAIL PROTECTED] writes: Also, when using abc to store complex scores, I think that human readablity is of very small importance, if at all; it will be uncomprehensable anyway. Not all multivoice scores are impossible to read. Jack Campin has some beautifully-constructed abcs of tunes in two or three voices. Arent Not impossible, but in general there will be very little Arent need for it, I guess that sight-readers of ABC will haveno Arent need for it, so it'll be more otr less pointless to try. Maybe there aren't that many people who sight-read ABC to perform, but presumably everybody (who isn't using some kind of GUI interface) reads their own ABC to correct errors. So making it unreadable is a way of making it unusable, because you'll have to get everything right the first time you type it, and I never do. That's a good point. Me too. Finding my way to a typoed note (I tend to make out-by-an-octave errors) is one of the, er, big minor irritations, and time-wasters, of typing tunes up. It helps a lot to have the ABC laid out in a comprehensible way. This is why I may well find myself gravitating towards the ! staffbreak, now it's available in abcm2ps. Which makes me think ... there was a bit of chat about various sorts of abc users, what distinctions are meaningful, etc. Maybe one way to break this down is that, people who type up lots of tunes, or big material, tend to notice things like this, because cumulatively they add up to a lot of aggravation, whereas people who type up one or two tunes once in a while would hardly notice it. -- Richard Robinson The whole plan hinged upon the natural curiosity of potatoes - S. Lem To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] New draft special characters
I. Oppenheim writes: | | (c) Why is £ \243? While I can of course implement it, it makes no | sense. Ascii £ is 156. | From the iso_8859-1 man page: Oct Dec Hex Char Description ... 243 163 A3 £ POUND SIGN ... 251 169 A9 © COPYRIGHT SIGN One problem we seem to have is that people use \ followed by digits to mean octal, decimal, or hexadecimal. This is an ongoing point of confusion. There is, of course, a totally standard way that mathematicians indicate the numeric base, but since we can't do subscripting in plain text, we can't use it. There's a long tradition of software packages and programming languages using similar notation for all three bases, but interchanging their meanings. We could establish a standard abc way of indicating the base, and in fact a fair amount of abc software uses \243 to mean octal 243. But most of our users are not programmers, and they are using all sorts of software on all sorts of systems. So they will always be using whatever notation is standard with the software they're familiar with, and we will always be fighting this problem. (Depressing, ain't it? ;-) To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] About the choice of '!'
Arent Storm writes: | From: Jean-Francois Moine [EMAIL PROTECTED] | | When encountering a '!', I scan forward. If I find any of |[:] | (and soon a blank or tab), or the end of line, it is a line break. | Else, if I find a '!', it is a decoration. This means that a | decoration name cannot contain any of these characters (for instance, | '!da Capo!' or '![rit]!' will not work, while '!crescendo(!' is OK). | | Does this solve all the problems? | | Sounds fine to me. Let's see; if I read this correctly, then in the line: ...|!dead!trill!beef|... the !dead! would be the decoration, and the staff break would come in the middle of the bar. Right? A couple of other people have given examples like this recently. Of course, with existing abc, it's somewhat of a moot point, since the two uses of ! come from different software. But if we include both in the standard, we can assume that people and programs will soon start using both, and we'll have to parse things like this. Maybe we should just quietly look the other way ... To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] copyright sign
Arent Storm writes: | If © were to be mandatory to enable copyright at all, the convention would | have to define the codingsystem also... But very few, if any legislators in any country are going to understand what a codingsystem is. They mostly (except for Al Gore ;-) have no clues whatsoever about what goes on inside a computer. Computers are what the secretaries use. Legislators know what a copyright sign is. It's that little 'c' inside a circle. That's all they need to know, and it's all they ever will know. One of the reasons that governments have standards bureaus is to handle problems like this after the fact. Hmmm, the idiots that we elected to Parliament just passed a law defining the value of pi; how can we phrase the official standards doc so this doesn't cause all our bridges to come tumbling down when the first seagull lands on them? To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Solfa (Was: [abcusers] a very peculiar use of word alignment
My apologies for being just a bit off topic, but I think I sense some potential help at hand here on my next upcoming project. At 04:48 AM 7/23/2003, Jack Campin wrote: Just for laughs, I tried to see if I could do parallel solfa lines in BarFly using the w: construct, with the solfa symbols being treated as words. The problem with it was that in solfa, the :, . and , characters are used as barlines and beat separators; they align between notes. So I tried to align them to y non-printing spaces. I couldn't get it to work right, but I cannot figure out if it should have worked at all, if I needed a different syntax to do it than the one I was using, or if the failure was a bug. Can it be done? (I did figure out that I needed to escape the - signs, used in solfa to add duration to the previous note). I haven't figured out what on earth to use for a lower-octave sign: solfa uses a sort of kerned subscripted apostrophe, easily distinguishable from the fat comma used for marking quarter- or eighth-beats. There's nothing in the standard Mac character set that looks like it so I can't even do high-bit cheating. I have recently come by a small book Songs of the Gael, by A. P. Breathnach, 1922. This book appears to use precisely the notation system described by Jack. I am about ready to transcribe the music to a familiar (to me) form of notation. I have searched the Internet for some reference on this system of notation, but have thus far had no luck in finding *anything* that defines usage of the various characters and marks. The letter characters obviously represent the solfege notes, but the meaning of the other characters is not so clear. Can you, Jack, or anyone, point me to a reference, either printed or online, that defines this notation system? I would appreciate any help, as some published guideline would sure help shorten the learning curve. Regards, Don To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] About the choice of '!'
On Wed, 23 Jul 2003, John Chambers wrote: Let's see; if I read this correctly, then in the line: ...|!dead!trill!beef|... the !dead! would be the decoration, and the staff break would come in the middle of the bar. Right? Right! But if we include both in the standard, we can assume that people and programs will soon start using both, and we'll have to parse things like this. I've added the abc2win usage of ! to the deprecated section of the draft standard, together with the algorithm proposed by Jef. In the main section of the standard, I have (re)introduced the *, which can now be used exactly in the same way as ! could in abc2win, without causing any problems. So |!pp!abc*def| will do the job. Groeten, Irwin Oppenheim [EMAIL PROTECTED] ~~~* Chazzanut Online: http://www.joods.nl/~chazzanut/ To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] Re: continuations
Arent Storm writes: | From: John Chambers [EMAIL PROTECTED] | | Another fringe case is what happens when a line ends with '\', a | space, and a newline. It's common for many implementations to not | recognize this as a continuation. This one is really baffling to a | user, who usually can't see the space. The right way to handle this | is to strip off the trailing spaces (and tabs), and then check for | the final '\'. The input routine is now not quite as trivial (though | it's still pretty trivial). | is not so straightforward Actually, it's fairly easy. What I did with my (jcabc2ps) clone was to put code in the getline() routine that does this: First, replace all trailing whitespace chars with NULs. Trailing whitespace chars are never significant in abc. Wiping them out during input slightly simplifies later parsing. Next, if there's a '\' at the end of the line, read another line, overwriting the '\' with the first input char. Repeat until there isn't a '\' at the end (or realloc() fails). I did have to change the input buffer from a fixed-size buffer to one that could be realloc'd, plus a variable saying how big it is. This was fairly easy. I did check all the references to see if there was anything that would break. I didn't find anything. This wasn't surprising, since the program obviously shouldn't keep any info about the input from one line to the next. Also, there's one bit of trickiness: abc2ps has an option to ignore final '\' and use the line breaks in the abc. If this option is set, the first step should just treat '\' as whitespace and NUL it out. The second step then never sees a '\'. To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
[abcusers] man
On Wed, 23 Jul 2003, Phil Taylor wrote: (Sorry guys, not wanting to start a platform-specific flame war, but I'm having to learn to love unix, and man in particular is driving me crazy.) Convert all man pages to html, and use you're webbrowser to read them. If you've installed a search engine like htdig on your computer, that makes it even simpler to search for information. And otherwise, you can use the info system. Groeten, Irwin Oppenheim [EMAIL PROTECTED] ~~~* Chazzanut Online: http://www.joods.nl/~chazzanut/ To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
[abcusers] Re: Solfa
Don Whitener writes: | | I have recently come by a small book Songs of the Gael, by A. P. | Breathnach, 1922. This book appears to use precisely the notation system | described by Jack. I am about ready to transcribe the music to a familiar | (to me) form of notation. I have searched the Internet for some reference | on this system of notation, but have thus far had no luck in finding | *anything* that defines usage of the various characters and marks. The | letter characters obviously represent the solfege notes, but the meaning of | the other characters is not so clear. Can you, Jack, or anyone, point me | to a reference, either printed or online, that defines this notation | system? I would appreciate any help, as some published guideline would | sure help shorten the learning curve. I looked into this a year or so ago. I found quite a lot of web sites that have music in solfa notation. I don't think I found any two that used exactly the same notation. It's pretty clear that the people using it are not developing software that uses it. It looks like they do a lot of editing of plain text, plus in some cases scanning images of music and laboriously aligning the images with the solfa and lyrics. The phrase hopeless mess comes to mind. OTOH, I suspect that if some programmer who is part of the solfa user community were to come up with some useful software, there's a good chance that it could be the start of standardization. The idea of a program that does both abc and solfa is probably good. If it were a java program that was easy to install, understood abc with both W: and w: lines, and could output a line of solfa under a line of music and above the w: lyrics, it could take the solfa world by storm. To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] Re: %%ABC 2.0 identifier
Phil Taylor wrote: (IMHO, there should be NO data in an ABC2 file which exists outside the context of the current tune -- I don't know if anyone else agrees with this, but it makes the most sense to me...) I have to disagree. One very useful feature of abc is the possibility of embedding abc tunes in other text. This makes it a fine tool for writing about music. See Jack Campin's tutorial on modes in Scottish music for a good example of this. Oops. I see I really phrased that one wrong. I've put ABC tunes embedded inside emails myself. What I meant to say is that there should be no ABC2 data outside the context of an individual tune inside a file. Each ABC2 tune should be capable of being parsed outside the context of the file it's in. Unfortunately, doing so means more or less doing away with the file header support, or at least disallowing any field that's affects how the tune is processed. (ie. M:, m:, R:, T:, U:) But I expect there would be quite a bit of resistance to that idea, which is why it's just an opinion, and not something I was suggesting we actually do. I *do* think the %%ABC2 tag on each compliant tune, or something similar, is needed. And given we have the file header anyway, I could accept a compromise that the %%ABC2 tag could be placed in the header and thus apply to all tunes in the file. The header has to be copied out anyway whenever you break a tune out of a file, so that's not a big deal. (Which reminds me -- is there ANY other open source parser out there other than the several dozen variants of the ones in ABC2PS and ABCM2PS? I'd like to look at one, especially an object oriented one if one exists...) There's the parser used in abc2midi and yaps, but it's ansi C not C++. Thanks, I'll look at them. C++ isn't necessary - I used to be a big C++ advocate but now I *much* prefer Objective-C. --Steve Bennett To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
[abcusers] Unicode and UTF8?
Has anyone given any thought to supporting Unicode and/or UTF8 files in the new standard? Much of my text editing nowadays (I work on Mac OS X...) produces Unicode encoded text files by default, and I think this is going to become more commonplace over the next few years. Also, supporting Unicode would open ABC up to more foreign languages. To accomplish this in a parser, I would actually convert the file to Unicode (if not already) at the very beginning and parse the whole thing in Unicode. One minor change to the spec would be how we deal with special character and continuation processing with the backslash -- I'd do that immediately after everything is converted to Unicode, before any other processing of the file. This results in some subtle changes in interpretation, which means a line like: \101: Steve Bennett ...would now be interpreted the same as: A: Steve Bennett ...which I think is a behavioral change for existing programs, but shouldn't have much of a side effect otherwise. (I'm not sure how to deal with the \-, which inserts a hard hyphen in a W: or w: field -- maybe it's the only thing not translated, or maybe it gets converted to a Unicode 00AD, which is a Soft Hyphen, although that's kind of reversed in meaning. Or maybe Unicode 2011, which is a Non-Breaking Hyphen, but again that's not *quite* the meaning...) I also suggest adding a Unicode escape to allow just about any Unicode character in an ASCII encoded file. Something like: \U262F ...where 262F is the hexadecimal value for the Unicode character to insert, in this case a Peace symbol. Of course, an ABC file already in Unicode form could allow any Unicode character to be included in any text field, such as the Word fields, etc. Any comments? --Steve Bennett To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] Unicode and UTF8?
On Wed, 23 Jul 2003, Steven Bennett wrote:
Steve,
The issues you discussed are specificly addressed in
the new revision of the standard, shortly to be
released.
I quote from the working document:
The basic ABC notation is done with the following
characters:
!#$%'()*+,-./0123456789:;=?@
ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`
abcdefghijklmnopqrstuvwxyz{|}~
However, the contents of the information fields, ...
annotations and free text sections may be written using
any character set. The default ABC character set is
Latin-1, which is also the default used in webpages.
If you would like to use a different character set, you
may find more information in section Charset field.
snip
Charset field
Example:
%%abc-charset iso-8859-1
This field documents according to which character set a
tune or a tunebook is coded. When no charset is
specified, iso-8859-1 (a.k.a. Latin-1) is assumed. This
is also the default charset for webpages.
Legal values for the charset field are:
iso-8859-1, iso-8859-2, iso-8859-3, iso-8859-4,
iso-8859-5, iso-8859-6, iso-8859-7, iso-8859-8,
iso-8859-9, iso-8859-10, us-ascii, utf-8.
Software that exports ABC tunes conforming to this
standard, must include a charset field.
All ABC software must be able to handle tunes coded in
iso-8859-1 and us-ascii. Support for the other charsets
is optional. Extensive information about these
charsets, can be found here:
http://czyborra.com/charsets/iso8859.html
Later occurrences of the charset field, override
earlier ones.
So the standard allows you to code stuff like lyrics,
titles, decorations, and other strings in utf-8, if you
so desire.
At the same time the basic ABC notation (anything
that's not a free text string) is guaranteed to be
coded always in plain old ASCII (TAB, LF, CR, Space,
!--~ being the only characters allowed) which
ensures that non utf-8 aware software can still
succesfully parse the music itself, even though the
lyrics may be coded in Chinese!
Since in utf-8, as you will know, ASCII characters are
coded as-is, there is no need to change anything in the
parser. The only thing that needs to be changed are the
routines that print strings, after they have been
parsed.
Let me know if you need further clarification.
Groeten,
Irwin Oppenheim
[EMAIL PROTECTED]
~~~*
Chazzanut Online:
http://www.joods.nl/~chazzanut/
To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] Re: %%ABC 2.0 identifier
On Wed, 23 Jul 2003, Steven Bennett wrote: What I meant to say is that there should be no ABC2 data outside the context of an individual tune inside a file. Each ABC2 tune should be capable of being parsed outside the context of the file it's in. This is also dealt with in the upcomming standard. I quote: The file may optionally start with a file header, which is a block of consecutive field lines, finished by a blank line. The file header may be used to set default values for the tunes in the file. Such a file header may only appear at the beginning of a file, not between tunes. Of course, tunes may override the file header settings. However, when the end of a tune is reached, the defaults set by the file header are restored. Applications which extract separate tunes from a file, must insert the fields of the original file header, into the header of the extracted tune. It is legal to write free text between the tunes of a tunebook. The free text should be separated from the surrounding tunes by blank lines. Programs that are able to print tunebooks, will print the text between the tunes. The free text may be interspersed with directives (see section ABC Stylesheet specification) or with Extended information fields; however, the scope of these settings is limited to the text that appears up to the beginning of the next tune. At that point, the defaults set by the file header are restored. Each line in the file may begin or end with blank space which will be ignored. For the purpose of this standard, ASCII Tab and ASCII Space characters are equivalent and are both designated with the term `space.' Applications must be able to interpret end-of-line markers in Unix (^J), PC (^M^J), and Macintosh style (^M) correctly. I *do* think the %%ABC2 tag on each compliant tune, or something similar, is needed. Also dealt with. I quote: Version field Example: %%abc-version 2.0 Software that exports ABC tunes conforming to this standard, must include a version field. Later occurrences of the version field, override earlier ones. and what about this one: Creator field Example: %%abc-creator xml2abc 2.7 The creator field contains the name of the program that created the ABC file, followed by the version number of the program. Software that exports ABC tunes conforming to this standard, must include a creator field. Later occurrences of the creator field, override earlier ones. Groeten, Irwin Oppenheim [EMAIL PROTECTED] ~~~* Chazzanut Online: http://www.joods.nl/~chazzanut/ To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] man
I. Oppenheim wrote: On Wed, 23 Jul 2003, Phil Taylor wrote: (Sorry guys, not wanting to start a platform-specific flame war, but I'm having to learn to love unix, and man in particular is driving me crazy.) Convert all man pages to html, and use you're webbrowser to read them. er, how do I do that? Actually I'd rather have them as plain text, since I have any number of seraching and indexing programs I can use with that. Just as an experiment I tried man vi vimanual.txt and was pleased to get a text file out of it. When I opened the resulting text file in a text editor, however, the resulting file had all the bold text in DDOOUUBBLLEE LLEETTEERRS, and all the underlined text spaced out with _a_s_c_i_i _u_n_d_r_l_i_n_e characters. This stuff is actually formatted to be printed out on a teletype, where the only way you can get a bold character is to backspace and print it again! Phil Taylor To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
[abcusers] Installing abcm2ps on OS X
A little light entertainment... I thought it was time I installed abcm2ps on my Macs. I already have it on a PC, but I don't often use that machine, and it would be much nicer to have it where I work. Downloaded it and double-clicked the .pkg file, went through the installer without any trouble. Started up Terminal and typed abcm2ps -h and got Command not found. OK. So where has the installer put it? Did a search with the Finder's Find command. Not found. Did the search again, this time allowing it to search invisible folders. OK. There it is, in /usr/local/bin Try typing /usr/local/bin/abcm2ps -h and lo and behold it works. So far so good. I don't want to type all that every time I use it, so I need to change the search path to include that location. Can't remember how to do that, so I dig out the unix book. Unix for the Impatient by Abrahams and Larson. Well, not very impatient as it's 824 pages long. Also quite battered now from having been thrown against the wall in blind fury several times (well, it's better than throwing the computer). After about half an hour with the book I remember that there's a variable called PATH (or is that $PATH - the book seems to use them interchangeably). And there's another one called path, which is not the same. All this somewhat complicated by the fact that the book covers four different unix shells, including csh, but not tcsh, which is what I have. They can't be that different can they? After all I'm not trying to do anything complicated or difficult here. Following the book I type echo $PATH and get /bin:/sbin:/usr/bin:/usr/sbin: So it's looking in four different places, none of which is where the program is located, and I need to change that to /bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin The book says You can set PATH to any search sequence you wish using the facilities in your shell for assigning values to variables; see for example section 6.15.6. Section 6.15.6 says You can assign values to one or more variables with an assignment (single or multiple) of the form: variable=value[variable=value...] and gives as examples: CAT=tabby GOAT='the chomper' Couldn't be easier. So I type PATH=/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin echo $PATH and it says /bin:/sbin:/usr/bin:/usr/sbin: No good. So I try: PATH='/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin' $PATH=/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin $PATH='/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin' with no more luck. Then in desperation I try the same things with path, even though I've figured out by now that that's a shell variable and changing it will only affect the current session. Still no good. Go make a cup of coffee and think for a bit out of punching range of the computer. Remember that there's a command called setenv (oh yes, I've been here before you know, it's just that it's been a while and you forget these things). Back at the computer I type man setenv to see what comes up. What comes up is the entire manual for the tcsh shell, hundreds of little 24-line pages, and after hitting the space bar enough times to risk RSI without seeing anything about setenv I give up. The book says just enter setenv name val without any equals sign, so I try it. And try it again in all the combinations I tried before. No go. OK. I admit defeat I cannot change the search path, but I've had another idea. Why dont I alias abcm2ps to /usr/local/bin/abcm2ps to save the typing? Ought to work. To cut a long story short, that didn't work either. No error messages; just didn't work. Finally (I'll give you one more chance, you silicon moron!) I try plan C. If the program doesn't work in it's present location I'll move it to one of the directories which _is_ on the search path. I can't move it using the Finder, because the top level folder of the file path is invisible. So I type mv /usr/local/bin/abcm2ps /usr/bin/abcm2ps muttering Do as your F** told or I'll reboot you in OS 9! and it says Permission Denied. Now what do I do? I can't log in as root because Apple in their infinite wisdom have disabled that. I could try screwing around with chmod, but it would take me another hour to figure out the magical incantation necessary to make that work (I've been there before too). So I reboot in OS 9, use ResEdit to make the usr folder visible and move the file using the Finder. Takes about 20 seconds max. Reboot in OS X and now typing abcm2ps in the Terminal works fine. So, you guys who choose to work in unix, what do you do when faced with a task where you know exactly what you are trying to do, but nothing works, over and over? Apart from reboot in a different operating system, that is? (And newer Macs can't even do that for God's sake.) Phil Taylor To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] Installing abcm2ps on OS X
On Wed, 23 Jul 2003, Phil Taylor wrote: So, you guys who choose to work in unix, what do you do when faced with a task where you know exactly what you are trying to do, but nothing works, over and over? Then you ask one of your friends on the internet for a little guidance! So hear it comes. 1/ Go to your home directory (type cd enter) 2/ open the file .tchrc in your favourite editor, create it if it does not yet exist. 3/ Add to the END of this file one of the following lines: set path = ( $path /usr/local/bin )# to extend your path alias abcm2ps '/usr/local/bin/abcm2ps' # to create an alias 4/ save the file 5/ open a NEW terminal window. This will make sure that the new settings are actually loaded. 6/ everything should now be fine... Groeten, Irwin Oppenheim [EMAIL PROTECTED] ~~~* Chazzanut Online: http://www.joods.nl/~chazzanut/ To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] multivoice linecontinuation
- Original Message - From: Richard Robinson [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, July 23, 2003 5:05 PM Subject: Re: [abcusers] multivoice linecontinuation On Wed, Jul 23, 2003 at 10:56:15AM -0400, Laura Conrad wrote: Arent == Arent Storm [EMAIL PROTECTED] writes: Irwin % variant A Irwin G2G2A4 | (FEF) D (A2G) G|\ Irwin M:4/4 Irwin K:C Irwin c2c2(B2c2) | I think this is actually an example of a recommended syntax in some pretty widespread documentation. (Probably something that comes with abcMIDI or abc2ps.) So you can deprecate it, but you aren't going to be able to not handle it, if you want to deal with what's out there. Arent Is it used often? I used to use it and stopped because I always let the software determine the line breaks for me. But if I were still expecting to determine my own line breaks, I might still be doing it that way. It was the original syntax, wasn't it ? It worked before the inline field [M:...] syntax was introduced, so there may be a lot of older tunes out there that have it. -- Richard Robinson The whole plan hinged upon the natural curiosity of potatoes - S. Lem To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
[abcusers] Re: %%ABC 2.0 identifier
Irwin Oppenheim wrote - Applications which extract separate tunes from a file, must insert the fields of the original file header, into the header of the extracted tune. Software that exports ABC tunes conforming to this standard, must include a version field. Software that exports ABC tunes conforming to this standard, must include a creator field. Must? What are you going to do if they don't? What about the existing abc files? One of the strengths of abc is that you don't need any specialist software at all; you can write it using a simple text editor (or pen and paper for that matter). How are you going to get Microsoft Notepad to conform to this standard? If I Copy and Paste a tune from an abc file into an email how is the operating system supposed to extract data from the file header? Surely an abc standard shouldn't be about software, it should be about abc. It should define what abc is. What software does is up to the developer under pressure from their users. As Guido said a while ago - That said, programs don't necessarily have to comply to 1.7.6 or 2.0.0 or 3.1415. Many users are happy with single-voice ABC, so programs targeting these users may be left untouched. But what about we classical musicians, who need more? What's more important, so-called standards or people's needs? No application is likely to be a complete implementation of any version of the standard. It is up to the developer to make it clear what subset of the standard they do implement then the user can make their choice and pester for the things they want. Bryan Creer
Re: [abcusers] multivoice linecontinuation
Arent Storm writes: | Someone else wrote: | I used to use it and stopped because I always let the software | determine the line breaks for me. But if I were still expecting to | determine my own line breaks, I might still be doing it that way. | | It was the original syntax, wasn't it ? It worked before the inline | field [M:...] syntax was introduced, so there may be a lot of older | tunes out there that have it. | There *may* be, but are there? | I haven't seen any... It's hard to find. I searched around through my collection, including a lot of abc taken from assorted mailing lists, and I had trouble finding more that a handful of files with M: or K: inside the music, either in the clumsy old form or bracketed. Even in classical music, such changes aren't common. It's much more common to just keep the same meter or key, and draw bar lines or accidentals as you need them. People seem to dislike changing such settings unless the change is for a big chunk of the music. So we're talking about what is a somewhat rare usage. Not much abc will have to change if we change the software's behavior for continuation lines in this case. Of course, if you're one of the very few people who do this sort of thing a lot, you might be a bit annoyed ... To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] multivoice linecontinuation
It was the original syntax, wasn't it ? It worked before the inline field [M:...] syntax was introduced, so there may be a lot of older tunes out there that have it. There *may* be, but are there? I haven't seen any... Yes, there are. Cheers, John Walsh To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] man
On Wed, 23 Jul 2003, Phil Taylor wrote:
Actually I'd rather have them as plain text, since I
have any number of seraching and indexing programs I
can use with that.
If that's all you want, it's trivial. Open a text
file, call it man2txt.c and give it the following
contents:
#include stdio.h
int main (void) {
char prev = 0, cur = 0 ;
cur = getchar () ;
while (!feof (stdin)) {
if (cur == 8) {
cur = 0 ;
} else if (prev != 0) {
putchar (prev) ;
}
prev = cur ;
cur = getchar () ;
}
return 0 ;
}
save it. Then compile it as follows:
gcc -o man2txt man2txt.c
Now all you need to do is the following:
man vi | ./man2txt vi.txt
Enjoy!
Groeten,
Irwin Oppenheim
[EMAIL PROTECTED]
~~~*
Chazzanut Online:
http://www.joods.nl/~chazzanut/
To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: Solfa (Was: [abcusers] a very peculiar use of word alignment
I have recently come by a small book Songs of the Gael, by A. P. Breathnach, 1922. It's still widely used by Gaelic singers. This book appears to use precisely the notation system described by Jack. I am about ready to transcribe the music to a familiar (to me) form of notation. I have searched the Internet for some reference on this system of notation, but have thus far had no luck in finding *anything* that defines usage of the various characters and marks. The letter characters obviously represent the solfege notes, but the meaning of the other characters is not so clear. Can you, Jack, or anyone, point me to a reference, either printed or online, that defines this notation system? The standard reference is John Curwen, Standard Course on the Tonic Sol-Fa Method, reprinted in umpteen editions from 1858 onwards (I have the 1901 edition). It goes far beyond simply being a notation manual; it's a complete course in the theory and practice of music. The example I was trying to do was the one in the New Grove Notation article, from the hymnbook of a syncretistic Nigerian church of the 1950s with a familiar Protestant hymn set to the most bizarre-looking text ever seen outside a Gnostic incantation. It wouldn't be hard to generate it from ABC but you would need to find the right fonts from somewhere. - Jack Campin: 11 Third Street, Newtongrange, Midlothian EH22 4PU; 0131 6604760 http://www.purr.demon.co.uk/jack * food intolerance data recipes, Mac logic fonts, Scots traditional music files, and my CD-ROM Embro, Embro. -- off-list mail to j-c rather than abc at this site, please -- To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] Installing abcm2ps on OS X
I. Oppenheim wrote: On Wed, 23 Jul 2003, Phil Taylor wrote: So, you guys who choose to work in unix, what do you do when faced with a task where you know exactly what you are trying to do, but nothing works, over and over? Then you ask one of your friends on the internet for a little guidance! So hear it comes. snip Thank you, Irwin. I'm feeling a little calmer now. Phil Taylor To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] multivoice linecontinuation
On Wed, Jul 23, 2003 at 04:17:53PM -0700, John Walsh wrote: It was the original syntax, wasn't it ? It worked before the inline field [M:...] syntax was introduced, so there may be a lot of older tunes out there that have it. There *may* be, but are there? I haven't seen any... Yes, there are. :-) Richard Robinson The whole plan hinged upon the natural curiosity of potatoes - S. Lem To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: Solfa (Was: [abcusers] a very peculiar use of word alignment
Thank you Jack, I'll try to locate a copy of the John Curwen reference through Inter-Library Loan. The local library does not have it, but it should be obtainable, now that I know exactly what to look for. The local library does have a copy of the 20-volume version of New Grove Dictionary of Music; I'll check it tomorrow and see what it has to offer. Regards, Don At 07:00 PM 7/23/2003, Jack Campin wrote: I have recently come by a small book Songs of the Gael, by A. P. Breathnach, 1922. It's still widely used by Gaelic singers. This book appears to use precisely the notation system described by Jack. I am about ready to transcribe the music to a familiar (to me) form of notation. I have searched the Internet for some reference on this system of notation, but have thus far had no luck in finding *anything* that defines usage of the various characters and marks. The letter characters obviously represent the solfege notes, but the meaning of the other characters is not so clear. Can you, Jack, or anyone, point me to a reference, either printed or online, that defines this notation system? The standard reference is John Curwen, Standard Course on the Tonic Sol-Fa Method, reprinted in umpteen editions from 1858 onwards (I have the 1901 edition). It goes far beyond simply being a notation manual; it's a complete course in the theory and practice of music. To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
[abcusers] Chord length
Yet another topic that my email archive has several messages about: We've had the suggestion a few times in the past that there be a way to give a length for bracketed chords, instead of repeating the length for each note. Thus [Ace]4 could be used for [A4c4e4]. In one discussion, we even had the suggestion of multiplying lengths if they are present in both places, so [A4ce]2 would be [A8c2e2]. This is something that's obviously not logically necessary. But it makes sense, fits in with the overall abc syntax, and would simplify typing for a lot of people. I don't have a strong opinion on this one, though I'd certainly use it if it were available. But I've had a few messages recently asking what ever became of the idea. So what became of the idea? Is it a nonstarter? Is there a flood of demand that it be in the standard? Inquiring minds (and fingers) want to know ... To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
