[abcusers] 1.7 standard
What the abc 'movement' needs is someone who takes responsibility over the standard. Personally, I would propose Jef Moine and Guido Gonzato: Jef because he's the developer of the (TMHO) leading abc package, Guido Gonzato because of his vision and his dedication. What package(s) does Guido use? At present, we have: * four mature systems representing three different sorts of software (ABCMus for playback, abcm2ps for staff notation, BarFly/Muse for both) - of these all but abcm2ps are broadly compatible; * several systems in various stages of development (Skink, PalmOS implementations, Bryan Creer's Noteworthy translator, perhaps half a dozen more) which implement most of 1.6 and whichever other ideas float the developer's boat and they manage to find time to work on; * four moribund systems which are still widely used (ABC2WIN, abcps, abcmidi, and abc2mtex). The kicker is Muse. At some point somebody else is going to revive it, and the job shouldn't be made gratuitously difficult by insisting that it should be another abcm2ps when it was designed with entirely different and very well-thought-out goals. It's a major implementation with years of work behind it and mustn't be wasted. Insisting that all of abcm2ps's features have to go in the standard makes it unimplementable for anybody whose goals include generating actual sound in some form and making every ABC construct correspond to a sonic entity. A standards commitee will have to say NO to most of those new features - da capo, say - until they are defined in such a way as to make them implementable on other platforms. - 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] My point of view on the abc standard
I suspect that the only things the abc standard has to worry about, as far as applications on different platforms go, is to do with specification of text fonts and definition of (accented etc) characters in text. And instrumental sounds. BarFly does this via the numerical codes from the instrument set provided with QuickTime - I think these numbers are in fact the same for other distributions of the same sounds, but it certainly isn't the most readable way to do it, and it isn't obvious that MIDI is the only way to specify such sounds that might ever be used (do soundfonts use the same scheme?) A human-readable standard namespace for sounds used by ABC applications would be helpful. Presumably there are other applications besides BarFly that let you control what timbre is played by typing something into the ABC source? - 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] About BarFly m: macros
I think that m: is a wonderful and very useful extension to the standard, but AFAIK BarFly is the only program that supports it. In my view, macros shouldn't be part of the notation, and should be implemented using external tools like preprocessors. But that's just an opinion. I think I'll extend abcpp to add m: support. Anselm Lingnau (I think) did a Perl implementation and posted it here a few months ago. I am not totally happy with macros as they are in BarFly at present; perhaps if somebody took Anselm's implementation and stuck it into another implementation, user input evolve something better. (The particular problem I have is that by far my commonest use for macros is to abbreviate chords in triadic keyboard bass parts, and the present setup means I have to write a new macro for every duration I use. The mechanism understands the pitch modifiers _=^', as part of the note, but not the duration modifiers like numerals and /). - 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] A bit of history
There are lots of abc2win files on the net which use the exclamation mark for a different purpose Can you be specific there? As a developer I'd like to know! It's a line terminator. In ABC2Win, it's the only way to start a new line of staff notation at a user-defined point, which is unfortunately non-standard. But having a line terminator is a great help in resolving the conflict between making ABC source- readable and having it generate readable staff notation. [warning, if you are not using a fixed-width font, what follows will be incomprehensible] Consider this, from the Aird volume 1 transcription on my website, laid out for optimal source readbility: X:34 T:Thro' the Lang Muir. T:Wandering Willie M:6/8 L:1/8 K:EMin % dorian/minor/phrygian pentatonic Bee Te2d |ege dBG|Bee Te2d |BAG E3:| BGG GAG|BAG ABd|BAG GAG|ABG E3 | BAG GAG |BAG ABd|Bee e2d |BAG E3|] As it stands, four bars to a staff line is too little. What I'd like is to put the tune on two six-bar lines. BarFly unfortunately doesn't use ! the way ABC2Win does, so I have to write this: X:34 T:Thro' the Lang Muir. T:Wandering Willie M:6/8 L:1/8 K:EMin % dorian/minor/phrygian pentatonic Bee Te2d |ege dBG|Bee Te2d |BAG E3:|\ BGG GAG|BAG ABd| BAG GAG|ABG E3 |\ BAG GAG |BAG ABd|Bee e2d |BAG E3|] Even though I've managed to keep parallel phrases vertically aligned so beats fall in the same column, the extraneous, musically meaningless line breaks destroy the visual flow, and are a serious impediment to readability of the source in a large score. What I would like to write is this: X:34 T:Thro' the Lang Muir. T:Wandering Willie M:6/8 L:1/8 K:EMin % dorian/minor/phrygian pentatonic Bee Te2d |ege dBG| Bee Te2d |BAG E3:|\ BGG GAG|BAG ABd|!BAG GAG|ABG E3 |\ BAG GAG |BAG ABd| Bee e2d |BAG E3:| which resolves the conflict in the simplest way I can imagine. : It seems to me that in some cases, having the !...! in the : abc is better than defining a single-char symbol. [the reason offered for this being] : Now, people who think that abc should always be translated : to staff notation might wonder who would ever read abc : directly. But there are, in fact, people who do this. In practice ABCs intended for processing by abcm2ps are among the least source-readable on the net, and the proliferation of long words enclosed by !...! is one the main contributing factors. It makes formatting to show structural parallelisms in the music (as I've done above) impossible. - 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
[abcusers] bloody ! again
would allow people to go beyond the standard in a way in which other apps could ignore. (Or pick up.) The rule would simply have to be that if such elements are omitted, the remaining music has to obey the standard and make sense. For this kind of in-line stuff, maybe you could use the established !! notation: !appname:info! Far from being established, this is peculiar to abcm2ps and will completely screw up ABC2WIN (which uses ! as a line terminator). I think what it will do is generate an interpolated line with the contents of appname:info interpreted as ABC notes, insofar as the program can manage to do so. - 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] bloody ! again
[!...!] is peculiar to abcm2ps It's in the new standard 1.6 and will completely screw up ABC2WIN (which uses ! as a line terminator). Strikes me that it's abc2win which is up the gum tree for this one. And I find very strange stuff in abc2win: a) +..+ for chords b) the writing of grace notes as 1/16th notes rather than 1/8th as below c) doesn't allow change of metre/key in the middle The second has nothing to do with ABC, it's a display issue. The first is no longer an issue; ABC2WIN users stopped doing it years ago (it was in a very old ABC standard). The last is a limitation of the sort many implementations have; in this case it doesn't matter because (if it's still there) ABC2WIN can't process *any* ABC representation of the music, whatever syntax we were to choose to represent key/metre change. It isn't the syntax that's boggling the program, it's the music itself. But there are thousands of tunes out there using ! as a line terminator; like it or not, that is one feature of ABC2WIN's syntax that caught on. They matter more than any one application. - 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] A bit of history
I argued already in another e-mail why ABC software should NOT assume that a bare newline indicates the end of a music line. The software should do the line formatting itself, and if the user should wish to override the default behaviour, he could use the !-newline notation to force a linebreak. !-newline is exactly what I DON'T want. The point of ! is to get a break in the staff display WITHOUT having a newline in the source. : As a programmer I'm very concerned about ! as a line terminator. : Consider this abc fragment: : abc abc|!trill! abc abc|! abc abc |! abc abc| : how does a program distinguish between the !trill! command and a command : ! abc abc|! which may be a command for a feature which it knows nothing : about? By making the !...! syntax for commands illegal so that the program will never encounter it. You get one or the other. There is no reasonable alternative providing what ABC2WIN does for line termination; there are plenty of alternatives (and better ones) for user-definable stuff. + having a line terminator is a great help in resolving the conflict + between making ABC source-readable and having it generate readable + staff notation. [my suggestion] + Bee Te2d |ege dBG| Bee Te2d |BAG E3:|\ + BGG GAG|BAG ABd|!BAG GAG|ABG E3 |\ + BAG GAG |BAG ABd| Bee e2d |BAG E3|] + Um. I must be missing something. Isn't + Bee Te2d |ege dBG|Bee Te2d |BAG E3:|BGG GAG|BAG ABd| + BAG GAG|ABG E3 |BAG GAG |BAG ABd|Bee e2d |BAG E3|] + the simplest??? It obscures the visual parallelism between bars 3 and 4 and bars 11 and 12, and the identity between bars 8 and 10, so it simply doesn't meet the constraints I was setting. This tune is in four-bar phrases and my ABC represents that. *All* yours does is generate the final staff notation in the format needed - not a great deal of use if the software has pushed you into a way of working that made you get the source wrong in the first place. This sort of parallelism is VERY important if you are trying to transcribe accurately from printed sources. My error rate would go up by a factor of 100 if I couldn't lay source out like that, and I wouldn't even have contemplated the Aird project I'm currently working on if I only had staff notation as a check on my accuracy. I have copies of attempted transcriptions of the same tunes by other people, using free-format ABC aimed only at getting staff notation output. EVERY SINGLE TUNE I'VE LOOKED AT has multiple errors, and there are 1200 of them in the collection. I'm redoing it all from scratch. (Many of the errors are because the other people were working from xeroxes, but even there a parallelized layout can make you think hmm, that can't be right and go back to see if what you thought was a staccato mark might actually be a durational dot or a fly turd). I am trying to use ABC to make something people will want to buy. If there's any chance it has a significant error rate they won't buy it. I have no interest in using software that encourages sloppy scholarship. - 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] bloody ! again
According to the BNF definition http://www.norbeck.nu/abc/abcbnfx.htm The bang is NOT a line terminator Which was a booboo on the part of whoever let that through. Supporting the existing corpus of tunes is *alone* more important than allowing an inessential idiosyncratic extension in one application. I don't understand what you are saying at all. According to a previous writer, abc abc|!bcd bcd| is equivalent to abc abc| bcd bcd| IOW the ! simulates a line break. It does in ABC2WIN, but as far as I know it doesn't yet in any other application. Which is a pain in the bum because it's a really good idea and far more useful in the long term than the !...! constructs. - 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] bloody ! again
As far as I know, only abc2win has so far used ! as a line terminator, and the !...! extensions already exist in the 1.7.6 draft standard, Which is not much more than a renamed absm2ps manual. which most people on this list seem to agree should be the starting point for the new 2.0.0 standard. If some bits of it are thrown out first. If this happens, I see several options for abc2win: This is the wrong way to look at it. abc2win is barely being maintained, but tunes created with its aid are the largest single corpus on the web. It's the tunes you need to care about, not the software. 1) Keep ! as a line terminator and don't implement the !...! extensions. This would make abc2win a nonstandard implementation. It already is in many respects. The problem is mainly a pragmatic one (though as I have been arguing, having ! as a line terminator allows important things you can't do any other way). 3) Use another character for either the escape character for either extensions (e.g., +...+ instead of !...!) or as a line terminator. This would also make abc2win a nonstandard implementation, and would definitely break some (possibly many) existing ABC files. There are very few existing files using the abcm2ps !...! construct compared with the number that use ! as a terminator. And since the uses of this construct are finitely enumerable, there is no reason why abcm2ps (or some utility supporting it) can't auto-edit them into something else. Since any ABC can occur between two terminators, it would be much harder for abc2win to change its behaviour, or for a utility to transform them automatically, even if the implementor wanted to do such a thing (not likely). I think having a unique forced line break character may well be useful enough to warrant using one of them. What would folks think of using for this purpose? Look at the example I just gave. The reason ! worked so well for it was because it's visually unobtrusive. isn't. Better to let abcm2ps have for whatever it wants to do with a new character, since source readability doesn't seem to be an issue for people who use it. - 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] The abc standard
Over the past year or so, this group has become dominated by discussion of abcm2ps; Probably because it is the best and least limited ABC implementation around: it implements an extensive set of features, is actively developed, runs on all computer platforms that we use and gives excellent ouput quality! Its sound output wasn't that good last I heard, and I haven't got a computer that can run it. Nor is it much good at transposing tunes, cataloguing tune files or importing MIDI. Have you ever tried ABCMus, BarFly or Muse? [a standard developer] is going to be familiar with programs which do fast onscreen display of abc music, programs which play abc, programs which do musical analysis or use abc for archival or database purposes etc. Phil, this are all implementation specific issues which a standard should not address. As you indicated yourself, ABC is just an *abstract* computer representation of a computer score; It IS a score. Any staff notation you generate from it is a transformation of a notation which represents *music*, not marks on paper. Musical analysis is just as good a way to use it as making printable files from it. all that the standard should do is to define this representation in an abstract way. Whether the *concrete* ABC files are to be played, displayed, printed or analyzed is up to the end user. It won't be if the notation has been designed to be unplayable and unanalyzable, which is where the !...! stuff is heading. - 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
[abcusers] The abc standard and ~ / turns / rolls
| Is ~ a roll or a turn? | According to ABC 1.7.6, it's a roll: One more disaster with that standard. The 1.6 standard said: : Alternatively, the tilde symbol ~ represents the general gracing : of a note which, in the context of traditional music, can mean : different things for different instruments, for example a roll, : cran or staccato triplet which is exactly what you want a new symbol for, having just dumped an already agreed one: Any Baroque musician is familiar with the convention that a '+' above a note means Ornament this note somehow. It's a generic, unspecific ornament symbol. I personally would like it to mean this in abc ~ has been around so long with its 1.6 meaning that almost every file on the web that uses it can be assumed to have the nonspecific semantics (which is not accidental, that's what Breathnach used it for in Ceol Rince na hEireann and where Chris got the idea). And in this situation you have no syntactic clue to tell you if the author might have had the redefined sense in mind. At this point it is WAY too late to think of imposing a new meaning on it. In fact + doesn't always have that generic sense in Baroque music. In English recorder music of the early 18th century it always means a trill starting on the note above. I brought that up a few years ago and the situation hasn't changed: BarFly can give me the semantics I want but not the original sign, abcm2ps's syntax can give me the graphical sign but can't represent its meaning in a way any player program could ever interpret. A full solution would need to allow new graphical elements to be introduced (in a platform-independent way, say as GIFs; in the worst case they might have to be taken from a scan of a manuscript) and allow their meaning to be redefinable, in case new scholarship finds that for some particular piece, a different set of conventions were really in force than those the transcriber had in mind. - 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
[abcusers] abc2midi and other MIDI-supporting software
four moribund systems which are still widely used (ABC2WIN, abcps, abcmidi, and abc2mtex). abcmidi ? moribund ? It handles well all of my abc. I like AbcMus, but I'm forced to use abcmidi because it handles better the %%midi commands (for different octaves in different voices for ex.) It isn't being actively supported any more, though. We discussed its bug with broken-rhythms constructs what, two years ago? getting the nearest I've ever seen us get to total consensus, and even though fixing it was a matter of altering one numeric constant in the source, it hasn't been done. What alternate syntaxes for MIDI voices are there at present? Neither %%midi nor BarFly's preferred option seems ideal. - 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
[abcusers] inaudible spaces
| I think it'd be difficult to avoid notation such as the x for the | invisible rests... I don't think it would be used in folk tune for | ex. so only tunes with heavy needs would need this, that mean | they would include also V: and other unsupported features in old | app. One place you could use it for simple one-line tunes is in transcriptions of the many editions that screw up upbeats. Inserting an invisible rest could make things add up for player programs without forcing staff-notation generators to print anything different from what was in the original. Actually, I find the y invisible, unplayed rest more useful. For example, if you want the somewhat conventional comma-like phrasing/breath mark above the staff, abc2ps produces a fine result if you write ,y This positions the symbol properly between two notes, and adds a bit of extra space. There are a number of abc thingies that can only be produced above/below a note. Rests are quite sensibly counted as notes by most progams, so you can gedt those thingies isolated by attaching them to a rest. A rest that is otherwise ignored is a very good tool for this. One place this is indispensable in in Russian songs. Almost all of them have v written as a separate word; as sung, it's assimilated to the following word, but never printed that way, it just floats in the space between the notes. For other uses, chances are that no two programs (or even two successive releases of the same program) will have the same spacing algorithm, so we have the interesting position that while this is a feature which all programs that generate staff notation ought to have, nobody could put a piece of ABC that uses it on the web and expect anybody else to see it the same way they did. For my new flute CD-ROM, I made very heavy use of it in getting the GIF scores to look right, but there is not one y space in the ABC I released on the disk. - 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] abc2win and ! line breaks.
The standard can be set to say that !...! is a special symbol, and developers can programs to read files on that basis UNLESS the header contains abc2win in which case it is a line break! Someone tell me that life really could be that simple! It isn't. I really want mid-line ! linebreaks (they're far more important to me than anything I could achieve with !...! constructs) and I have been lobbying Phil for years to add them to BarFly, which doesn't put any creator info in its headers by default. This isn't a matter of supporting legacy tunes, it's about doing something mostly new (insofar as abc2win users don't seem to have yet exploited this possibility in their program the way I want to use it) AND IT CANNOT BE ACHIEVED BY ANY OTHER MEANS. Let's hope there are a lot more programs that can use them in future. Perhaps it might make it clearer why I'm being so insistent about this if I explain what most of my time using ABC is spent doing. I spend about a full day a week in the National Library of Scotland researching things, mostly tunes, which are copied in ABC using a geriatric Mac laptop that runs BarFly and pair of cheap walkman headphones. For the time I'm transcribing tunes, I'm working with rare sources that I can't afford to have photocopied; the process required by the library for old and delicate material involves intermediate microfilm, and usually leads to a fairly bad result anyway, where things like articulation marks often get lost. (The NLS's charges, which are among the lowest in Scotland for rare materials, are still high enough that if I wanted everything I transcribed to be on xerox first, I could easily incur a photocopy bill for a day's direct transcribing that was more than I paid for my laptop). So I've got no alternative but to get the most accurate transcription possible on the spot. The way BarFly works gives me a three-way check on accuracy: - does the structure make sense? - does it sound right? - does the score on the screen look exactly like what's on the page of the original in front of me? The first is dealt with by the columnar layout I use; I'm mostly doing things in four- and eight-bar phrases, and if something can't be laid out to look like that in ABC source form, chances are that something's gone wrong somewhere, either 250 years ago or in the previous five minutes. (BarFly also has error checking utilities which on average picks up one miskeying every eight bars; I'd find these manually anyway, but BarFly finds them quicker). The second is handled by BarFly's playback (helped by the ability to highlight the note being played - this means you can move instantly from a general feeling of something's not quite right in that phrase to typo on that note). The third is supported by BarFly's instant preview (no batch processing or invoking of GhostScript involved - GhostScript would be unusably big and slow on that laptop anyway). In this situation I don't have time to process the layout optimized to show the structure of the tune into some other form before showing it on the screen - and since I need to identify where any errors are in my source, what's on the screen has to be directly derived from it. So I *cannot* afford to have unnecessary built-in conflicts between source readability and screen readability. If I want a print-optimized version by adding graphical tweaks, I'll do it at home; the laptop is a lousy machine to use for them anyway. What it is *very* good for is interactivity, and it's the speed of switching between structure, sound, and score modes of perception that makes for accuracy. But supporting this is a rather fragile characteristic of a language, which many syntactic misfeatures could break, and people who haven't used it in such an interactive environment won't easily spot the important issues. - 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] Solution for ! notation?
| I play a lot of folk dance music which consist of phrases of 8 bars.
| When linebreaks are every 4 or 8 bars, this makes the score more
| readable.
I think that dance musicians usually really like having the phrases
aligned this way, but most other musicians don't see the benefit
(and some vehemently dislike it).
Another class of people who use it a lot is highland pipers. For
their scores, there are usually about as many gracenotes as melody
notes, and it can get visually difficult to figure out what's going
on (particularly in the setting where most pipers use tunebooks,
with the music on a table some distance away while working with a
practice chanter). So they line up the beat notes vertically; it's
a bit like the way columns of decimal numbers are usually laid out -
gracenotes to the left of the invisible beat line and melody notes
to the right of it. I do the same with ABCs of Highland pipe music,
since the {...} notation creates the same sort of visual jitter that
pipe gracenotes do.
Look at the G.S. MacLennan tune collection on my site for some
samples; GS was one of the main creators of the modern gracenote-
heavy piping style. (The typesetting of the collection he edited
himself didn't do it, though - it came later, presumably after some
army piping instructor realized that GS-induced eyestrain was an
avoidable occupational hazard).
I've occasionally wondered whether Jack Campin gets similar flames.
His abc is very nicely aligned vertically, making the structure of
the music really obvious. This just has to offend some people ...
Most are along the lines of why didn't you tell me Windows Notepad
could do that?, which induces a feeling like an author must get when
told their novel has been adopted as a sacred text by a cult devoted
to child sacrifice.
-
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] Solution for ! notation?
[abcm2ps's !...! construct] So, why not pick a symbol other than ! for the latter usage? * seems ideal, and quite logical, too: in emails, IRC, etc., it is commonly used to boldface or emote something. My first reaction is that ! is better, since in !ppp! it is used as a delimiter, and delimiters are tall and skinny, while * is short and fat. It's tall and skinny shape is exactly why I want ! to stay as the linebreak character. Look at the examples I posted; the reason it works so well to aid readability there is that it's so easy to ignore it when reading the score directly in ABC. Since it has nothing whatever to do with the musical content, direct reading is precisely when it's most important to have an almost invisible symbol. Again: show me a score written for processing by abcm2ps that was written with any attention whatever to source readability. If you simply don't care how headache-inducing your source is, why should you insist on any specific lexicon? - 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] Solution for ! notation?
Usually, I want the program to just decide where to put the line breaks, with a few rare exceptions. The solution I'm coming up with on the next release of Music Publisher is to provide an editing screen where changes can be made to abc file before use. And including a reflow command for bars so that it will fit on whatever page and stave size you have defined. Could I suggest that if you do this, you keep the original? Maybe as a commented-out appendix to the tune. If the auther (me for example) cares about the source layout, they're not going to appreciate having to set it all out again after your program has clobbered it. BarFly has something like that, but makes a new copy of the tune as it does it. I wouldn't use the feature if it didn't do something equivalent in practice to that. You need to separate the two layers of ABC intended to represent the music itself and ABC intended to represent staff notation for the music somehow. Changing a note or a chord is in the first layer; using a y to make the two halves of a bar more visually separate than the program wants them to be is in the second. - 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
[abcusers] digitizing old scores
| For the time I'm transcribing tunes, I'm working with rare sources | that I can't afford to have photocopied; the process required by the | library for old and delicate material involves intermediate microfilm, | and usually leads to a fairly bad result anyway, where things like | articulation marks often get lost. (The NLS's charges, which are | among the lowest in Scotland for rare materials, are still high enough | that if I wanted everything I transcribed to be on xerox first, I could | easily incur a photocopy bill for a day's direct transcribing that was | more than I paid for my laptop). So have you (or they) considered using a digital camera instead? This is rapidly becoming a much more practical approach than microfilm. They have signs all over the entrance hallways saying no cameras beyond this point and no way would they let a reader do any photography. I don't know what they use in their reprographic department. They will do scans up to fairly high quality and put them on CDR for you, but it costs way too much be an option except for occasional items. The ultimate pig to deal with digitally is Victorian steel engravings, as used on the covers of many music collections. These create texture and shade by masses of parallel curved lines at variable sub-millimetre spacing, which is guaranteed to produce weird moire effects at any reasonably high resolution. Lower the resolution and you get a dull grey blur that completely loses the visual impact. Even lithographic reproduction mediated by a high-quality process camera degrades the image to a glaringly obvious extent. We don't have a technology to deal with this yet, short of getting out a set of burins and doing what the original engraver did. Music doesn't usually have that much detail, and the stuff I'm working with is usually a bit earlier, hence copper-engraved (coarser lines). In the best case that can be quite easy to scan, but the problem is that only the poshest editions used paper and ink to match the plate quality (and those are usually sources sufficiently well known that I don't need to bother with them). Often the ink has blotted or partly rubbed off. Some music printers took a more sensible approach and used fatter signs for budget publications (e.g. big bold single-quote signs for staccato) but most didn't. (Perhaps it was more readable when first off the press; the fibres of the paper have sometimes fluffed up over the years). One unique problem is with the Macfarlan Manuscript (the most important of all Scottish tune MSS). It's beautifully written and for the most part works just fine in photocopy or scan. But there are some places where it's got wet, and the ink has gone through from one side to the other. The only way you can work out which dot belongs to which tune is by transilluminating it and reading both sides at once. - 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] ABC examples with bang?
I've been unable to find ABC files with the much-talked-about bang (!) for breaking lines. Could any good soul send me some examples? It's for extending abcpp to deal with this beast. Here's another one using it the way I want to. The point of reproducing the original linebreaks isn't just for historical documentation; it's a lot easier to see if your transcription is right if the line breaks are in the same places on the screen staff display as on the page. Linebreaks in mid-bar are common in this period, both in MS and print. It's an interesting tune too. As far as I know it has only been published once before in a form anything like this, and that was in the 1790s. It's a Scotticized version of a northern English hornpipe from the 17th century, Three Sharp Knives. X:1 T:Old Age and Young S:Drummond Castle/Duke of Perth MS (David Young, 1734) B:NLS Acc.7722/MS.21715 N:pseudo-type-facsimile, showing original staff linebreaks by ! signs Z:Jack Campin 2003 M:3/2 L:1/8 Q:1/2=120 K:G Minor G4 B3 c d2(cB)|A2 F4cB A2 (G^F)|G4B3 c d2(cB)|A2 G2g2 G2 TA2(G^F)::! DG^FA G2G,2 B,4 |D2 F4B2 TA2 (G^F)|DG^FA G2G,2 B,4 |D2 G4 B2 TA2(G^F)::\ GABG ABcA! BcdB |A2 F2c2 F2 ABcA |GABG ABcA BcdB |A2 G2g2 G2 ABcA ::\ Gg^fa! g2G2 TA4|F2 f4F2 ABcA |Gg^fa g2G2 TA4|G2 g4 G2 ABcA H:: Notice how easy it is to ignore the linebreaks when reading the source if you aren't interested. That's the point - most of the time you *will* ignore them. I regard the last three characters as optional. The two-sided repeat at the end doesn't mean anything special, and the fermata simply means that's where the tune stops (as opposed to Fine somewhere else), so :| would convey the same meaning. (The fiddler would probably have ended with a big fat three-string G minor chord). - 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] (..) means?
M:4/4 |e2(G2 G2)Bc| Parentheses without a number are used to slur notes. But the notes are the same! If you sight-read music in 4/4, it's easier to follow the music if the note that falls on the third beat is always notated separately. The above example should really have been notated as G2-G2 [tied] though, and not as (G2 G2) [slurred]. Maybe and maybe not. In some contexts slurring two notes of the same pitch means don't change bow direction to a fiddler, rather than continuous bow movement - there are still two perceptibly successive notes. Some staff notation makes a distinction with different curve shapes for slur and tie, but you may need to read a lot of fine print to find it. - 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] K:Hp anyone?
| I've never seen the K:HP or K:Hp implemented. Has anyone else? | (That's Highland Bagpipe: HP=no key sig but an implied key of 2 sharps, | Hp=key sig of 2 sharps + 1 natural and both force stems downwards for | the tune). Yeah; abc2ps (and probably any clone) implements it fully. K:Hp has always been one of my favorite examples of the usefulness of advisory accidentals in a key signature. Without the =g in the signature, there's a very real risk that musicians will quickly figure out that a tune is in A, and will correct the obvious typo in the key signature to three sharps. Adding the =g in the keysig makes it clear even to classical musicians that it's not a typo. BarFly does it that way too and I'm pretty sure ABCMus does. But unfortunately it's not quite orthogonal enough to the rest of ABC for a few examples of pipe music: (1) some of the very earliest pipe music was written with the six- finger note being D rather than A and the key signature having one sharp (if written at all). This transposing scheme is eminently sensible if your intended readership is fluteplayers, as it was at the time. Breton pipe music is sometimes written in two flats with Highland-pipe-style typesetting conventions: i.e. at pitch, which is also a good idea if you expect players of other instruments to jam along. But ABC doesn't have any way to generate the pipe-style stemming (melody note stems down, gracenote stems up) while retaining a free choice of signature. (2) David Glen's collections of 1890-1910ish pull a truly neat trick. Pipers are going to ignore the key signature anyway, so he directs it at people playing the music on the piano. Some pipe tunes sound like shite if you play them in two sharps on an equally- tempered instrument, and especially if you're trying to harmonize them as well. So his key signatures range from nothing (A minor) to three sharps (A major), and by and large they work. Both of those could be handled if HP were something other than a key signature in ABC. In the first case it's a typesetting directive, in the second case it's also forcing an instrument-dependent interpretation of the key signature at playback time. Either way a signature like K:D Mixolydian HP or K:C Dorian Hp would handle it. And much more importantly (3) This goes for ordinary pipe tunes too. In the Aird examples Bruce pointed to, I used Hp signatures to signal that the pitch set of the tune (range as well as signature) was that of the pipes. But I'd have preferred to state the mode as well, like K:D Major Hp If this were available in ABC I'd use it in every pipe tune I transcribed. If there were two separate ways to indicate bagpipeness - one saying what the pitch set was, another indicating the typesetting convention to use - some new possibilities would open up. A header line saying typeset this as for the pipes is not the only kind of idiomatic typesetting you might want: for example, vocal music usually has a separate flag for each individual syllable, which looks unreadable to a fluteplayer, so a flute typesetting style might beam these regardless of what beaming the ABC source implied, and a vocal style might break beams according to what the w: lines implied. And there are books of tunes for the bellows pipes which only differ from fiddle tunebooks in the stem direction. Being able to name vocal, pipe or generic instrument typesetting styles and invoke them at a single point in the tune (or file) header would make it quicker to create custom scores to keep specific classes of musician happy. (I guess this is like CSS, which is something I haven't really tried to learn yet). - 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
[abcusers] reproducing archaic notation
But why would you want to put :: at the end of the tune when :| is correct notation? Do you really want to see a repeat-both-ways barline at the end? I don't, but just about everybody in the mid-18th century did - you never see a single-sided repeat sign at the end of a tune. If you want to get the exact look of what they wrote, what else could you do? (As I wrote before, I would prefer to use :| and relegate H:: to the notes in the header). And a fermata over the final bar has no meaning either. It does, but not the modern meaning of fermata; it means here's the stopping point when you're repeating this (and I suspect implies an everybody-bow chord). Really it's a different symbol that happens to look the same. All of Young's dance tunes include it. Sometimes it's in the middle, if you're meant to stop after the A part. You can work out what it means from the dance instructions. - 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] ABC examples with bang?
John Norvell wrote: All of the tunes (hundreds) in my private collection use |!(newline) as the line terminator. Attached are a few examples. Which all look a bit odd, as if you'd formatted them carefully for source-readability and then some gremlin intervened to insert random amounts of leading whitespace in each line. How did it get there? (Open them with a text editor to see it, I assume abc2win is hiding it from you). Could you post a screenshot of how this source looks to you when you're editing it? I've never heard of using ! in the middle of a line as a terminator and think that we should deprecate that usage. Why? Lots of abc2win users do it and as I've been arguing, a lot more people ought to, whatever the software they have. If the ! is only used on the end of a line it adds no new expressive feature to the language. In this line BBe2A4 e2 :| Z ||! what does the Z mean? - 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] Re: End of 2nd time bar
Surely a performer wants to know what the writer meant? And lack of repeat starts means there is no information as to how the tune was to be played, eg whether the whole tune repeated or just to the previous double or repeat bar. imo notation which is incorrect should be flagged by software and a clarification requested from a human being. How do you propose to interrogate Captain O'Neill? I never use repeat-start signs unless they'll appear in mid-staff-line (the convention used by O'Neill and mostly by Kerr). This is pretty normal in the folk world, and probably 99.9% of all the ABC ever typed in would fit the assumption that the previous repeat or double bar, if it's located at the end of a line, marks the start of the repeat. There are undoubtedly cases where you want to do it differently, but it would be nuts to make such an alternative the default interpretation an ABC player made, even if it is the official one in the textbooks. - 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
[abcusers] parts and multi-voice playback
We've been over this before, but back when BarFly was the only application to support both parts and multi-voice playback. So maybe other implementations have moved on enough to merit a re-run. The following is my way of representing a piece in book 6 of Aird's collection. Aird used a da capo, but ABC doesn't have that (printing the words does not a control construct make), so I used the standard P: construct to represent it. BarFly displays this nearly how I want it: each part gets a label in a sensible place, though the playing order is not printed. X:1 T:Drink to me only. T:2 Flutes. M:6/8 L:1/8 Q:3/8=60 P:ABA K:A P:A [V:1] ccc d2d|(ed)c (Bc)d|(eA)d c2B | HA6:| [V:2] AAA B2B|(cB)A (GA)B|(Ac)B A2[EG]|[HC6HA6]:| % P:B [V:1] e|ece a2e|(ec)e e2e | f2e d2c | (c3 B2):| [V:2] c|cAc c2c|(cA)c c2c | d2c B2A | (A3 G2):| The intuition behind the P: construct, to me, is that you are splicing separate chunks of music together to form a larger piece. So this is not really a playback issue at all. The semantics of P: is given by a source-to-source operation (which a staff notation program could also implement), and the above must be equivalent to this: X:2 T:Drink to me only. T:2 Flutes. M:6/8 L:1/8 Q:3/8=60 K:A [V:1] ccc d2d|(ed)c (Bc)d|(eA)d c2B | HA6:| [V:2] AAA B2B|(cB)A (GA)B|(Ac)B A2[EG]|[HC6HA6]:| % [V:1] e|ece a2e|(ec)e e2e | f2e d2c | (c3 B2):| [V:2] c|cAc c2c|(cA)c c2c | d2c B2A | (A3 G2):| % [V:1] ccc d2d|(ed)c (Bc)d|(eA)d c2B | HA6:| [V:2] AAA B2B|(cB)A (GA)B|(Ac)B A2[EG]|[HC6HA6]:| Now, BarFly isn't having the syntax of ex.1 at playback time, you get silence. Its syntax requires that I write more verbosely, like this: X:3 T:Drink to me only. T:2 Flutes. M:6/8 L:1/8 Q:3/8=60 P:ABA K:A [V:1] [P:A] ccc d2d|(ed)c (Bc)d|(eA)d c2B | HA6:| [V:2] [P:A] AAA B2B|(cB)A (GA)B|(Ac)B A2[EG]|[HC6HA6]:| % [V:1] [P:B] e|ece a2e|(ec)e e2e | f2e d2c | (c3 B2):| [V:2] [P:B] c|cAc c2c|(cA)c c2c | d2c B2A | (A3 G2):| which plays as written (the glitch in the anacrusis is Aird's responsibility, his da capo isn't meant literally), but doesn't display right: each voice gets a separate part label. The implication appears to be that part boundaries don't have to coincide across voices: you only get one P: line in the header so the sequence has to be the same, but if you are *not* going to syntactically enforce coincidence of part boundaries across voices, they ought to be allowed to drift, yes? So let's try it, even though I can think of no conceivable reason why you'd want to write something like this: X:4 T:test P:ABAB V:1 V:2 M:none L:1/4 K:C [V:1] [P:A] GG [P:B] || [V:2] [P:A] [P:B] GG|| What BarFly displays gives no indication of where the part boundaries in each voice are, and it doesn't play any sound. So it doesn't look like this extra flexibility has been implemented. Nor do I want it to be. Please can we have the simpler option as in my first example, where parts are played as complete chunks of music, no matter how many voices they've got, and without me having to do Simon says the viola starts playing the coda here too with redundant in-line fields? - 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] random-access-like...
Given that ABC is text-line-based, *can* a program go straight to a tune, random-access-like, without having read all the intervening lines? random-access-like... yes, it's possible. My JedABC has an index mode that does what you want; so does BarFly in Split Screen Mode. But BarFly will have read the entire file before it goes into split- screen mode, and I suspect JedABC will have done too. You would need something like ISAM to do what Richard is talking about, and I don't think anybody is implementing ABC software in MVS Cobol or in S3 on ICL VME. Richard's tunebook is the only ABC file I've got on this machine that requires me to increase BarFly's memory allocation above the default (and it's very slow to load). But with a modern machine you'd need to have getting on for a gigabyte of ABC in one file before random access mattered. I don't believe the entire world typing together can create ABC source fast enough to out-scale the computer industry. BarFly currently has an interesting bug (which probably nobody but me has ever encountered) in which certain kinds of text at the end of a file can screw up the processing of a tune near the start, even with hundreds of intervening tunes. So it's not even behaving like a one- pass compiler in which only preceding text affects the context. Phil probably has the underlying architectural support to add a COME FROM control construct if he wanted, like an inverse da capo (has anybody ever used such a thing in musical notation?). - 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
[abcusers] global accidentals
| I've also found the phrase explicit key signature more useful than | global accidentals, though I don't suppose that's a real big deal. | These seem to me to be two separate things. Whem converted to | conventional notation, an explicit key signature is the collection | of sharps, naturals and flats you find at the start of the staff; | global accidentals are accidentals applied to notes throughout the | music. (Does anybody ever use these?) What makes them hard to use is that you'd only do this if you had (a) figured out what the correct mode of the tune was, having gone right through it to see what pitches occurred, and (b) decided not to write it that way. There aren't many places where that happens. One Scottish tune that almost always seems to have been notated like that is Tullochgorum, but I have no idea why it got singled out for this treatment. Something like it also happens in modal-magical- mystery-tour tunes where there's a gap in the scale for the earlier parts of the tune which is filled in later on with a different pitch than the one you might have expected - Flowers of the Forest is an example. For that it does make sense. | I would like to propose the addition of two new optional parameters | to the K: command; tonic= and mode=. Using these, John's K:Amix=g | could become - | K:^f^c=g tonic=A mode=mixolydian |which seems much clearer to me. If we were designing abc from scratch, I'd agree. As it is now, I'd guess that few if any users would ever use this, mostly because it's so much wordier. So I'd think that such clear but wordy notation would be appropriate for the more complete notations like MusicML or LilyPond, while ABC's K:Amix=g is more in keeping with ABC's compact style. I have recently come to avoid abbreviations wherever possible, writing modes out with the full names. The reason I'm doing that is that on my CD-ROMs, most of the editorial documentation of the tunes is in the ABC headers; I don't repeat much of it in the explanatory text. Readers are going to have to bite the bullet and read the ABC directly if they want to know how I've changed key signatures or where I've inserted missing accidentals. So I can't be too cryptic. If Bryan's verbose alternative were available I'd use it every time. ABC is compact and cryptic, but easy to type. Just about anything is easy to type if your editing environment has macros, auto-completion or cut paste. Most people have some way to create chunks of stereotyped text faster than one-key-at-a-time. - 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
[abcusers] global accidentals
What makes them hard to use is that you'd only do this if you had (a) figured out what the correct mode of the tune was, having gone right through it to see what pitches occurred, and (b) decided not to write it that way. Jack, that's not true. There are a lot of tunes that cannot be notated with standard key signatures, e.g. because they are build on a scale with flattened and sharpened notes at the same time. Consider the D-Ahavoh Rabboh mode, common in Klezmer. [...] You're missing the point. John was talking about the difference between writing such scales as an explicit key signature at the start (as is usually done these days for Turkish music) and taking some major or minor key signature as the base and then writing an accidental beside every note that deviates from it. We seem to be agreed that the latter is not generally a good idea; I was pointing out occasions when it has in fact been done in print. - 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] Re: %%ABC 2.0 identifier
with that data has been melted down - no conversion of any kind is permitted, it's up to software to implement complete bit-level compat- ibility with the very earliest file systems and numeric formats. - 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] Re: ABC sects
If it had been agreed that ! could be used as a line break and that had been documented in the abc standard, I doubt that the ! would have been considered as the symbols for the macros. History: abc2mtex (and its documentation) came first, then abc2win (and its documentation), then the 1.6 standard - which was more or less a minor rewrite of the abc2mtex documentation, with features no other program has ever implemented or is ever likely to, and ignoring what Jim had done. Which kinda explains why Jim never bothered arguing for his ideas on this list afterwards. That is, the 1.6 standard already made the same kind of mistake that the 1.7 one did (with 1.7 using abcm2ps instead of abc2mtex). One reason this might have happened is if, as Bryan seemed to imply, the abc2win documentation was only in the form of Windows help files - that format seems to be so obscure that nobody's written a converter from it to anything platform-independent, and maybe Chris didn't have any means of reading it. Is the abc2win documentation now available in some public format? As far as I'm concerned, abc2win is obsolete and I only really care about programs that are being actively developed and can move on when there is a need but there are perhaps far too many files written in this program warrant supporting ! as a line break... More to the point, that feature does something so useful it would need to be reinvented anyway, even if abc2win had never existed. - 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] Use of ! (and another source issue)
consider '!' a newline if not followed by 0-9A-Za-z; a flag otherwise.
Can I just repeat the first of the two examples I gave for why I want
to use ! as a staff newline?
X:34
T:Thro' the Lang Muir.
T:Wandering Willie
M:6/8
L:1/8
K:EMin % dorian/minor/phrygian pentatonic
Bee Te2d |ege dBG| Bee Te2d |BAG E3:|\
BGG GAG|BAG ABd|!BAG GAG|ABG E3 |\
BAG GAG |BAG ABd| Bee e2d |BAG E3:|
The idea is to simultaneously satisfy the requirement for the most
comprehensible ABC source I can get while also achieving a specific
staff-notation layout (either because it looks best on my screen or
paper, or because I'm trying to replicate a paper source warts and
all). Breaking the thing up with extra columns of whitespace would
violate that - I want the *minimal* addition to the source that it'll
take to get that break in the right place. Which means ! and not
one character more.
There is another place where I want a near-invisible character; to
resolve the conflict between source and staff readability caused by
the way ABC does beaming. Look at the first bar in lines 3,4 and 5
of this tune:
X:1
T:If e'er ye do well it's a wonder
S:Dow MS, fiddle part
M:3/4
L:1/8
K:D
(FE)|D2 F2 AB| A4 (3(Bcd)|(A2 B2) d2| e4 \
(de)|f2 D2 F2 | A3 BAG | F6 | d4||
(de)|f2{a}gf{f}ed |Te4 (3(def)|(A2 B2) d2|Te4 \
de |fdgfed | A3 BAG | F6 | d4
de |fdgfed | e4 (3(def)|(A2 B2) d2|Te4 \
de |f2 D2 F2 | A3 BAG | F6 | D4|]
Almost the same, but the fact that one is decorated with gracenotes,
combined with the fact that I'm trying to reproduce the original
beaming, obscures that. MacOS has a non-breaking space (looks like
an ASCII space but isn't) which in theory should solve this within
the BarFly environment; in practice it doesn't, since it will generate
error messages that get in the way, and most of the time it confuses
the slur drawing algorithm somehow so your score looks like a disaster
in an eyebrow factory. But the code for that character is different
for every OS that has such a thing, so it'd be unusable for anything
that anyone else might see, even if it worked right.
Now, there is one ASCII character that is nearly invisible and hasn't
been used for anything else in ABC yet. So I propose that ` should
be completely ignored by both player and formatter programs, with its
sole function being to help ABC source look better by allowing the
writer to visually separate notes that are to be beamed together.
The above tune would then look like this:
X:2
T:If e'er ye do well it's a wonder
S:Dow MS, fiddle part
M:3/4
L:1/8
K:D
(FE)|D2 F2 AB| A4 (3(Bcd)|(A2 B2) d2| e4 \
(de)|f2 D2 F2 | A3 BAG | F6 | d4||
(de)|f2{a}gf{f}ed |Te4 (3(def)|(A2 B2) d2|Te4 \
de |fd```gf```ed | A3 BAG | F6 | d4
de |fd```gf```ed | e4 (3(def)|(A2 B2) d2|Te4 \
de |f2 D2 F2 | A3 BAG | F6 | D4|]
This actually does generate the right staff notation in BarFly, but
the tune title is all too appropriate. I can't predict when it'll
work. And the error reporting module looks annoyed at me.
This is a simple example - there are much hairier-looking ones where
it matters more. Minuets could often be notated far better using it.
This *should* be the easiest-to-implement ABC feature ever proposed.
The other JC could probably include it in jcabc2ps in less time than
it took me to describe it.
-
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
[abcusers] header fields
[header fields A-G] are too widely used to be thrown away, though some are too vaguely specified to be given a reliable semantics. Vagueness is a good reason to throw them away. It would have to be 2.0 and not 1.8, since it breaks compatibility. All the older Abc files would still work, more or less, just like they do today, but the stricter 2.0 format would work a lot more reliably. N:notes/narrative, I:indexing info, and % comments would suffice for anything not essential to rendering sheet music. And where does that leave all the uses that have nothing to do with sheet music? Look at my G.S. MacLennan tune file and see what I'm doing in the second half of it - try typesetting that! One of ABC's neatest features is that you can transcribe stuff in a two-stage process; first create headers to act as bibliographic entries, and add the bodies later when you get time (or in the case of that GS stuff, when I get permission). You still have a useful tunography even if you never get round to doing the bodies; in fact ABC could be useful to DJs for exactly that purpose - they need to know the discographic reference data, BPM, duration and key of the stuff they'll be mixing, but they'll never need a score (though a MIDI might help). Where does your I: come from? Nobody's discussed that here. Anyway, here's an example: T:title W:music by ... W:words by ... N:sources, discography, books, history, transcription notes, etc. % From http://... L:1/8 M:2/4 Q:1/4=120 K:G dorian That breaks existing conventions for W: - it's for lyrics that aren't to be printed aligned with the tune. And it makes searching for the information you've dumped in the N: field insanely difficult. If I want to know which tunes I've taken from a particular book, I will launch a search for the B: line and nothing else. N: fields are a grab-bag that can contain absolutely anything; some kinds of searching need structure. You also MUST have a way to identify the transcriber - that's what the Z: line is for. E: is surely up for grabs now. I've previously suggested re-using it for a universal identifier that would encode the transcriber's identity and provide a dated checksum for the tune, to make ABCs traceable and verifiable far into the future as they get copied and migrate. This would be a doddle for an editor like JedABC to implement, or do with a standalone Perl utility script, but since it has very long-term implications it has to be done in a way that suits all imaginable platforms and implementors. That might be nice, but it's hopeless. One little tweak, and the checksum is gone. That's the point. It identifies when you've got something identical to the original, so that if you suspect there have been some tweaks you'd rather do without, but the E: field is intact, you can go find an untweaked version, even if the originating site is long gone and all the copies are in mirrors or recompilations. And it gives you a quick way to avoid storing exact duplicates of stuff you've already got (unedited duplicates account for a sizable proportion of the ABC on the web). Besides, you can't expect musicians to use Jed or Perl. Any program that can compute the signature and stick it in the tune or file header will do the job. What I had in mind is a utility that adds the digital signature before you upload stuff to the web or pass it on in some other way. It could be nearly as seamless as the way MS Word adds identifying info to its documents. If you care about where your stuff is going to end up (as anybody doing it for commercial reasons will) you'll use it. The only bit that has to involve significant effort is getting registered as an originator in some public way; this need not involve a central registry but it does need a public, agreed protocol and it needs you to put the same data into your local configuration that you've told the world about (much like registering with a search engine). After that's been done, it's trivial to use the mechanism. Tune comparison software is the best bet, and it's still basically hopeless :) Tune comparison does nothing to tell you what the original is or help you find it. It serves entirely different purposes. - 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
[abcusers] copyright sign
[copyright sign] We could pick one of the unused single-letter headers, if we don't want to make the jump to full-word headers. Of course, the best would be just: : 1998 Joe Smith ... which via your mail client and mine emerged as a colon here. But some people might have problems figuring out how to type this. On many linux and *BSD systems, you can get the copyright symbol with the ALT-) (or ALT-SHIFT-0) combination, but I don't think this will work on Windoze or Mac systems. On Windows it's alt+0169 Which is also where it is on a (UK-English-language-system) Mac, but can we count on it not being used for something entirely different on some other platform? 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. - 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] New standard(s)
Particularly, I'm getting unhappy about Jack's (??I think) mention of A: as Author (of words). Or, more particularly, I use A: heavily as Area, and am not comfortable, about 1) conflicting with other meanings (it's not the first time A: == Author has been mentioned) and 2) the issues that get raised by hierarchical data fields. In practice there's no problem to it (that I can see) that a little commonsense can't deal with, but it's not quite comfortable all the same. I could (maybe) invent something like %%A:Sweden:J\amtland, %%A:England:Northwest, but these things are more useful if software understands them ... We already have another field that is used for geographical info, O:. The way some people have used these assumes that a tune will only be assigned one location (as with a field transcriber's notes), and hence every Area will be contained in a unique country of Origin. Your own files don't work that way: you take one transcription of a tune and list all the countries that lay claim to something like it. So if you find a tune in both Yorkshire and Nova Scotia you have a teensy weensy problemette working out what A:Halifax means. Better to use the O: field hierarchically: O:Halifax, Nova Scotia, Canada O:Bradford and Bingley, Yorkshire, England which is less ambiguous, frees up A: for a very important function we don't yet have a standardized field for, and is not much harder to search on. - 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] New standard(s)
I'd also suggest that we strongly encourage a URL or email address [...] so that people can easily find the owner and ask for permission to use the music. we should note that any email addresses they contain may be a spam risk, while (if) encouraging people to use them. URLs much better; unless they contain email links ... Or even better, a unique string that any search engine can find, as URLs have a finite life. If spundlegroft doesn't turn out to be a googlewhack try 99thMothTongueOfLavenderToothpaste and so on. (Make a shorter link services perform a similar function). - 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] expected abc audience
When trying to fit abcusers in a few groups having [1] abc-sightreaders (without much need for software) [2] abc-collectors [3] abc-software-only-users (1st language) [4] abc-as- interchange-file-format-users (2nd language) Two questions arise - is this a meaningful division? - if so, how large do we expect the groups to be? My answer to the first question is -of course- yes ;-) The second is the hard one my first (wild)guess would be: 1: 200 (1%) 2: 500 (3%) 3: 1000, 1 (30%) 4: 1 (66%) the remainder Any thoughts? I don't know what the second category means. The third seems a wild overestimate - surely the only program that does interchange to any other general-purpose score format in a meaningful way is Bryan's Noteworthy convertor? He probably has figures for how many people use that but I doubt if it's as much as 5% of the ABC community. Or do you mean people who convert to ABC from other formats? - I don't think that really happens any more, everything from the NMD or BGP formats that is ever likely to be converted already has been, and there never were more than three or four people doing either. - 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] copyright sign
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. (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). - 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] About the choice of '!'
The idea of multiple tunes within one file I personally do not like much (I'd rather zip them when transferring) Interesting. It's always struck me as one of the useful points about ABC, when dealing with several thousand tunes, that you don't have to have them all in separate files. When it comes to downloading/distributing: YES When it comes to handeling: definately NO I use three different editors for handling ABC on the Mac (BarFly, BBEdit and Nisus Writer). With all of them it's much quicker to search a few large files than a zillion small ones; Nisus Writer makes it painfully difficult to search large numbers of files, though the kinds of pattern matching and replacement it can do are way more sophisticated than any other editor I know of. Surely the same is true on any OS? - there's a much larger hit opening a small file than reading a comparable-sized chunk of a large one that's already open. I think ABCMus uses a similar user interface to BarFly (selecting tunes from an index on a file, which can be large) so this doesn't seem to be a problem on Windows either. - 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
[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. 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. - 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] New standard(s)
Funny thing is that in recent years, they have abandoned any such calibrated units for most measurements. Units of time, length, voltage, etc. are now defined in terms such as the wavelength of a specific spectral line in a specific isotope. So you don't have to depend on a physical copy of a physical object halfway around the world; you can determine the units in the privacy of your own lab. In most of the world, this is now the situation. [...] I can't think of a way to make a funny tie-in to music for this now. Maybe someone else can. Something along the lines of how we no longer need to calibrate our instruments to any mundane physical objects in this world; we can align our music with the very basic phenomena of the cosmos. But there's gotta be a better (i.e., funnier) way to express the idea ... I heard somewhere that there was an ancient Chinese term for a month in the spring that translated as something like in-tune flute time. The reasoning behind it was that at that time of year, the base joint of the local bamboo had grown to be just the right length to make a standardly pitched flute out of. Musical pitch gets to define the calendar. - 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] BarFly 1.4 available
There are now three versions of BarFly, called Carbon, Classic and Old. All three versions have been updated, and all carry version number 1.40. Use the Carbon version on MacOS X, and on MacOS 8.5 - 9.2. Use the Classic version almost anywhere (System 7 on). Use the Old version on Macs with 68030 or 68040 processors and on PC emulators which emulate this kind of processor. Can the Classic version run on 68040s - i.e. is it an old-style fat binary? I'd rather not have to manage two separate versions. (Most of my stuff is on an external disk which is usually mounted on an LC475 but sometimes on a PPC machine). - 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: 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] Chord length
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].
I think it got lost within the discussion about having notes of
differing lengths within chords. [Ace]4 doesn't have anything
like the same semantical problems as [A4ce] so it might be
better to discuss it separately.
There shouldn't be any problem with any durational modifier being
applied to a chord made up of same-length notes, should there?
{[DGB][EAc]}(3:2:4[EGB]2[DFA]/{[EGB]}[EGc]/
for example.
-
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: Solfa (Was: [abcusers] a very peculiar use of word alignment
[solfa] 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. You are quite likely to find one second-hand someday. I got an extra copy a year or so ago (for only 50p) and passed it on to somebody on the Scots-L list. They can fetch silly prices on EBay but there shouldn't be any need to use that. 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. It gives a comparative description of textual musical notations but doesn't have a full tutorial on any one of them. Probably not what you want. - 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] multivoice linecontinuation
I searched around through my collection, [...] 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. I was guessing so too, especially where most abc-tunes seem to be rather simple short (as by nature history of abc) It's pretty common for even the simplest English folk-songs to vary in metre. I am not quite sure why this one needed to be transcribed that way but it was. Incidentally demonstrating a use of ` I hadn't thought of until I started this: simultaneously aligning ABC notes with the text while doing beaming in the modern way Bernard described here. X:1 T:Scarborough Fair O:Yorkshire C:Collected and arranged by Cecil Sharp %%Copyright: 1916, Oliver Ditson Company S:A Selection of Some Less Well Known Folk-Songs vol. 2 S:compiled by Cyril Winn S:London: Novello and Company, Limited Z:Jack Campin 2003 http://www.purr.demon.co.uk/jack/ M:6/8 L:1/8 Q:3/8=60 Andante P:ABABABC K:G Dorian P:A G`A```G F``GA |Bc`B A2 w:1.Where are you go-ing? To Scar- bor- ough Fair? w:3.Tell her to wash it in yon-* der well, w:5.Tell her to plough it with one*ram's horn, % z|G2 A (BA)G |G``B``c d2 w:Pars-ley, sage,* rose-ma-ry and thyme, w:Pars-ley, sage,* rose-ma-ry and thyme, w:Pars-ley, sage,* rose-ma-ry and thyme, % G|d2 d=e``d```c |dG```G (FG) w:Re- mem- ber me to abonn-y lass there,* w:Where water ne'er sprung nor adrop of rain fell,* w:And sow~it all o- ver with one pep-per corn,* % A |(Bc)```B A```A`G |[M:3/8]D``=E`^F |[M:6/8]G2z z3|| w:For once* she was a true lov-er ofmine. w:And she* shall be a true lov-er ofmine. w:And she* shall be a true lov-er ofmine. % P:B GA```G F``G``A|(Bc)`BA`A w:2.Tell her to make me a cam-* bric shirt,* w:4.Tell her to plough me an ac- re of land,* w:6.Tell her to reap it with~a sick-le of leath-er, % z|G2 A (BA)G |G``B``c d2 w:Pars-ley, sage,* rose-ma-ry and thyme, w:Pars-ley, sage,* rose-ma-ry and thyme, w:Pars-ley, sage,* rose-ma-ry and thyme, % G |d`d``d =edc |d2 G F`G w:With-out an-y need-le or thread work'd init, w:Be- tween* the sea and the salt seastrand,* w:And tie it all up with a tom- tit's feath-er, % A |(Bc) B A``A`G |[M:3/8]D``=E`^F |[M:6/8]G2z z3|| w:And she* shall be a truelov-er ofmine. w:And she* shall be a truelov-er ofmine. w:And she* shall be a truelov-er ofmine. % P:C GA```G FG``A |B```c``B A3| w:7.Tell her to gath-er it all in a sack, % G2 A (BA)G |G``B``c d2 w:Pars-ley, sage,* rose-ma-ry and thyme, % G |d```d``d =ed``c|d```G```G(FG) w:And car-ry it home on a but-ter-fly's back, % A |Bc```B A``A`G |[M:3/8]D``=E`^F |[M:6/8]G3-G2z|| w:And then she shall be a true lov-er ofmine. BarFly doesn't do too badly with that - its most serious problem is that it doesn't put the playing order anywhere in the staff notation display. It would look better in landscape format, but I can't tell BarFly to open up the staff spacing enough to stop the text colliding with the staves (5 per page is the minimum). The line numbers are an icky hack. There ought to be some way to integrate that with the P: playing order specification. - 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] Chord length
But uses like [A4ce]2 would seem to be fairly clear to understand, convenient to type, and consistent with the rest of the language; it's a thing I'd try if I needed to express such a thing. Mixed lengths in the same chord are *not* clear to understand if you are trying to implement a player or barlength checker, or even a staff notation generator where absolute duration influences horizontal space allocation. Some other time, PLEASE. - 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] About the choice of '!'
This is what the new standard-in-development has to say about it: line breaking To force a line break at all times, a star (*) can be used. Who wrote that, why and after what discussion? (That is not what the abc2mtex * means). For me it would be a pain in the arse. If you want to use * for anything, use it for the bracketed things (which I won't write anyway so I don't care how ugly they are). Deprecated line breaking The abc2win program used a `!' character to force line breaks, as is currently supported with the * operator (see section Line breaking). Deprecate !text! instead. Users should avoid using ! line breaks together with !...! symbols. Easy enough, I have no intention of ever using those symbols. - 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] About the choice of '!'
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? Good point, but generally people who are using one system (who belong to the abc2win sect for ex., or in the opposite to the abcm2ps sect) won't use the other one. It might be useful to some to have the functionality provided by both. By far the best way to do that would be for abcm2ps to change the character(s) it uses round those !text! things to something else, like + or * (both of which are both legacy syntax and rarely used back when they were supported). - 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] Version 2.0.0 voice overlay and lyrics
Voice overlay The operator may be used to temporarily overlay several voices within one measure. The operator separates these voices from each other. My take on it is that the operator sets the time point of the music back to the previous bar line, and the notes which follow it form a temporary voice in parallel with the preceding one. I suspect that this should only be used to add one complete bar's worth of music for each . Assuming you would only ever want to do this in music with barlines? Really? Surely there are monophonic chants where voices split for a brief imitative Alleuia or Amen, for example? Or unmeasured guitar music? - I'd expect guitar and lute pieces to see the largest use of this feature. Why not some explicit start point? - paralleling the not-anchored-to- a-barline repeat syntax, use [ maybe? And perhaps a terminator to help sanity-checker utilities work out that the same duration had been provided for each voice, maybe ] ? I don't see why it needs to be unreadable; just overlap the voices vertically. Using the example given, removing barlines and adding a bit on the end: A2 E2 G2 A2 [[ A B c d e f g a \ A A A A A A A A \ A G F E D C B, A, ] D2 E2 A2 ... (I'm assuming each needs a separate matching explicitly stated start point - it also allows for a bit more generality as they needn't coincide). - 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] Readability of abc
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. You know you've got it right when somebody turns up at a session with a tune on paper as a prompt - and it's your ABC on a slip the size of a bus ticket. I've had that happen to me. - 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
[attempting to housetrain a Unix system] 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. Try PATH=/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin export PATH You might also want to change your shell to something less squirmily haveanicedayish than tcsh. chsh is the command to do the change; bash is pretty reasonable though my fave back when I was using Unix a lot was ksh (which just does what you tell it without trying to get creative). - 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
[abcusers] the two uses of !
What seems to have happened is that I and a few others pointed out that we don't really have a serious problem with the two uses of ! right now, because a simple heuristic can tell which meaning was used in a tune. But some people misinterpreted this to mean that both could be legal in the standard language. But using both in a single tune is a parsing disaster. Which could be avoided simply by having the !symbol! things (or such of them as we want to retain) use a different bracketing character. I want to be able to use ! as a linebreak in the very same pieces I want to process with abcm2ps (which is the only ABC application that can handle some of the stuff I've got). If !symbol! stays the only way I could do that would be by hacking the source and recompiling a version that used +symbol+ instead, creating a new dialect. The fraction of the ABC corpus that would need to be changed to fit a change of delimiter by abcm2ps is peanuts. abc2win is still in heavy use, and whatever other maintenance Jim does on it, he's hardly likely to allow it to become incompatible with new Windows releases, and it's not going to suddenly become incapable of handling the sort of basic melodies most ABC users still want to process, so !-linebreak tunes are going to keep coming for years. - 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
[abcusers] expandable information field
I'd like to catch the use the the Y: field for future extensions like Y:someinfofield=some info field value This way we've maintained compitiblity with existing abc files while having the possibilty of future expansion. Perhaps Phil (as the person whose program has the strangest parser) is probably in the best position to answer this, but it occurred to me a while ago that maybe we don't need a whole new letter for such uses. Would it be feasible to allow multi-character header fields so long as they were introduced by a leading :? X:1 T:Thingummy's Reel M:C| :DanceInstructions: RSCDS Book 137, 2042 K:A ... That only needs one-character lookahead, which I think was what Phil was concerned about? (I'm going to be away for a week, OS 1:5 sheet 48 302241, a mile off the nearest road with no modem). - 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
[abcusers] explicit signatures
They are non standard in Western music, but you will find something like [K:D _b _e ^f] often in e.g. Klezmer (Ahavoh Rabboh) or Arabic music (Maqam Hedjaz). My first thing will always be to remove any non standard explicit accidentals, replacing them with inline accidentals and inform the player textwise that he/she is playing an unusual mode/key. [...] The mode/key/accidental stuff is way too complicated for the average folk player Okay, so imagine you're playing a harp-family instrument like the hammered dulcimer or Turkish kanun. What you want to know *first* is what pitches occur in the piece; you do the appropriate tuning or lever-flipping, and unless the piece has some chromatic bits in it (which it probably won't if it's standard repertoire for those instruments) you never want to see an accidental, it would just be notational noise. You will do something phenomenologically similar with a microtonally fretted instrument like the tanbur, or even when beginning a vocal piece in a microtonal mode; most pieces in the repertoire begin with a tuning-up section in which the fingers or vocal chords settle in to the set of pitches that will be used in the main body of the composition. The explicit signature, without accidentals-that-aren't-really, models exactly what operations the performer does, in the order in which they do them. Which is why it's been standard practice in Turkish music for a hundred years. - 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
[abcusers] octave-sensitive key signatures
In most cases, musicians will be following the rule that accidentals apply in all octaves, so for them it doesn't matter where the key-sig accidentals are drawn. You seem to forget that ABC players also should be able to make sense of the notation. I suggest the following: 1) [K:D exp _b _e ^f] will accept only lowercase accidentals that apply in all octaves. 2) [K:D oct _B,,, _e'' ^F] will accept octave sensitive key signature definitions. Only (1) will be adopted in the standard. Programs that have need for octave sensitive key sigs may implement (2) as a private extension. That seems sensible. Here's a toughie, though. In some of the folk idioms of Georgia, there is no octave-based scale: the music uses stacked major tetrachords instead - C D E F F G A _B _B c d _e and so on (since this is vocal music, probably not much further, but Georgian art-music composers have extrapolated it). Anybody seen anything like that notated? If so, how's it done in practice? (I could just phone Marina Adamia and ask, but hey, that would take all the fun of guessing away). - 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] expandable information field
(I'm going to be away for a week, OS 1:5 sheet 48 302241, a mile off the nearest road with no modem). Take plenty of Jungle Formula. I hear the midgies are especially ferocious this year! Hardly saw a midge the first couple of days. Then I tried playing the flute outside at the end of the house around midnight, looking across to the lights of Iona. Within a minute or two I was in the middle of a cloud of them and had to beat it back indoors. My host suggested I should have kept playing until they were *all* gathered round and then marched off over the hill taking them with me. - 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
[abcusers] chords accidental semantics
Below I will outline the most recent changes that I incorporated in the ABC draft standard, based on your input. - Changed Accomp. Chords to Chord Symbols - Added: programs should treat chord symbols quite liberately Some player programs interpret these. They aren't generating symbols, they're generating chords. So the original is better. %%propagate-accidentals 0 | 1 When set to 0, accidentals apply only to the note they're attached to. When set to 1, accidentals also apply to all the notes of the same pitch in the same octave that appear after the note that they're attached to, up to the end of the bar. Please can we have yes and no instead of numbers that have to be looked up in a manual? I am not too happy about something this semantically basic being dumped in a comment field. Just about any ABC program other than a staff-notation formatter will need to have the information. %%writeout-accidentals 0 | 1 | 2 When set to 0, modifying or explicit accidentals that appear in the key signature field (K:) are printed in the key signature. When set to 1, only the accidentals belonging to the mode indicated in the K: field, are printed in the key signature. Modifying or explicit accidentals are printed in front of the notes to which they apply. When set to 2, both the accidentals belonging to the mode and possible modifying or explicit accidentals are printed in front of the notes to which they apply; no key signature will be printed. The default value is 0. Again, please not numbers. And it's a bit confusing to call these accidentals when they are in fact systematic (I'm not sure what the correct term is and don't have a reference handy to locate it, but I'm sure there is one). Both of these, especially the first, would be better specified as part of the K: field. Perhaps one way for the second would be to put information about which pitches were to be printed as scattered-through-the-tune accidentals within some sort of bracket? K:A Mixolydian % type 0 above K:A Mixolydian [=g] % type 1 K:A [Mixolydian]% type 2 K:A [Major =g] % same effect as previous line K:A Major =g% same effect on keysig as K:Hp And for the first, perhaps K:A accidentals = to-end-of-bar % the default K:A accidentals = per-note-only % the early-music case K:A accidentals = until-cancelled % indefinite persistence K:A accidentals = all-octaves % allows any accidental to apply to % all octaves of the same pitch class K:serial accidentals = required % see almost any 2nd Vienna School score Both put the information where no comment-stripping utility could lose it. There may be other policies than the ones I've identified - if so, the advantage of giving them their own keywords is that a program will know to stop and ask a human if it hits one it doesn't know about. In this case it isn't helpful either to guess or ignore it, except in the trivial staff-notation-generator case (where you can just print a score with no hint of its real meaning). - 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] mensurstriche
I haven't read the new standard about multiple staves, but does it allow specification of bar's *between* the staves but *not* on them? This is something a lot of people (not me) like for early music that was originally published as unbarred parts. It's usually easier for modern players to sightread from a score which has the indication of where the barlines might be, but doesn't need to screw up representation of the note lengths. That is, a note length that straddles a bar can still be represented as one note, and not two tied notes. We have invisible barline [|] and we can specify draw barlines between staves. This will of course screw up representation of the note lengths unless there is rule saying draw two notes tied over an invisible barline as one note. You don't need a general rule to do this if you use a construct I suggested a while back - I called it an absorptive tie. The idea would be that it's notated much like a tie but has the effect of adding length to the previous note rather than being drawn as an explicit tie. The original point of it was for placing multiple chords on one long note, as needed in some of Atte's jazz ballads. I suggested simply doubling the - sign to represent it; so A--A/ would print the same as A3/. For the barline case you might use A-- | A/ and you would then be free to write an explicit cross-bar tie somewhere else in the same score if you wanted (which a rule-based approach would forbid). What other mechanism could there be to tell the program where to draw the barlines between staves? Tell the program where to start drawing barlines and how much time there is in a bar. This would also have the great advantage, for a pure staff notation generator like abcm2ps, of giving the writer some feedback about where they'd made a mistake - transcribing barlineless music is not easy and it helps if a nonsensical score can be made to *look* nonsensical. It could also be done by having a separate part containing nothing but invisible rests and between-stave barlines but that would make for ugly, bloated source. BTW, how well do existing ABC applications handle pieces where the voices are not all barred the same? - 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] man
To get rid of the backspaces from the man command, use the col command: man vi | col -b vi.txt More's the point, how could I have discovered the existence of col for myself? The biggest problem with getting things done in Unix seems to be that you keep hitting these barriers where you can't figure out the solution and you just have to go and ask someone who knows. 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. - 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] abcm2ps and 'extras'
I asked a while ago about drum notation [...] The one thing I'm missing is putting the slashes on the stems of the notes. Obviously, an extension to the code is necessary, and I'm even willing to gasp step outside the bounds of the emerging abc standard to accomplish my goal, since my real intention is only in creating pretty postscript output, suitable for a tunebook of printed notation. BarFly can do everything *except* typeset the slashed stems, using its macro mechanism. You can define how many strokes you want for a particular trick applied to a note of a particular length, and the program can be configured to interpret that (or not) for either playback or score generation. But what it prints will be fully explicit, like an 18th century army drum score. A notation I propose for my usage (might others find it useful as well?) is to put slashes // _before_ the note on which I want the slashes to occur, since, in my first estimation, they should be unambiguous symbols (please correct if I am wrong). I suggested something slightly different a long time ago - a postfix * to indicate that the previous note or chord was to be split into two repeated notes or chords, allowing stacking of *'s to get arbitrarily many power-of-2 repetitions. Since this would be in the ABC syntax rather than in the macro system, a typesetter could interpret it with the slash notation. This would save a lot of typing for Beethovenish drum-with-your-left-hand piano chords - your screen fills up fast when you've got repeated semiquaver four-finger chords in the bass. Prefix slashes for this will cause ambiguity. What does a//b mean? - 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] Re: backslashes
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. Commenting-out could well introduce pseudo-pseudo-comments. I doubt we can do anything about that. - 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] P: and V:
[Irwin Oppenheim] 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 No - there's no need to rename the voices. The main point of P: is if you *also* have a P: line in the header, which you've omitted in your example. The way BarFly does multiple voices, you can't do what you just did with the K: line. This does make some sort of sense - there's no presupposition that all voices will change key at the same time. What do other applications do here, in cases where there's a visible change in the signature? [Phil Taylor] 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:-) It doesn't display the same - you get a part label on each voice, which looks weird. There should only be one for all voices. (Part label placement in BarFly is strange even for single-voice tunes). This way of doing things makes manipulation of parts more work than it needs to be. It should be like cut-and-paste of paragraphs in a word-processing document; you don't need to type something at the start of each line to say what paragraph it belongs in. [John Chambers] : I recently typed up a transcription of the following, for which : I've stripped out all but the first bar of music in each section. : Note that the P: lines are just used to give the conventional : classical tempo terms. Don't all ABC applications support words for tempi in some way or other by now? So why do this? - 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] P: and V:
What should be the meaning of the following fragment: P:A [V:V1] C G C [V:V2] E B E P:B [V:V1] A E A [V:V2] C G C Or differently put: How, according to you, should P: and V: interact? In itself that doesn't say enough as there is no header given. If there a line in the header saying P:ABAB then that will be played as if written %A [V:V1] C G C [V:V2] E B E %B [V:V1] A E A [V:V2] C G C %A [V:V1] C G C [V:V2] E B E %B [V:V1] A E A [V:V2] C G C (and perhaps staff notation programs might implement such unrolling as an option, it isn't purely a playback issue). 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. - 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] MAXSTAFF = 16
Ok! But let me ask you something: When was this setted to 16? What was the speed of the top machines then? The older abcm2ps I have, version 0.12.9, in date March 28, 1999, already had a max of 16 staves. The speed at this time was the same as now: I develop on a PC 486 DX 100 with 32 Mb of memory :). The value 16 was choosen because it is the number of staves that fits a page with the default scale (0.75). I was tidying up a friend's flat this week and found she had a full score of Thomas Tallis's Spem in Alium lying about (40 voices, set out as eight 5-part choirs). I was tempted to try it as another test-case-for-bizarre-ABC; there's nothing very complicated about it except for the sheer scale. The score (OUP edition) was something close to folded-A1 paper size, but the staves are still small enough that a conductor would need good eyesight to see all the details. - 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
[abcusers] ABC as Tablature; being my entry in the Obfuscated ABC Contest
I have been trying to transcribe a rather obscure, and as far as I know never-before-transcribed, piece of tablature from a Scottish manuscript of about 1680. The MS gives no clue as to what instrument it's for or what the tuning is, except that it had four strings - the tab is written on four of the five lines of ordinary music paper. Here's the tablature from the MS. This tune only uses the top three strings so that's all I've written. The parens represent a bracket drawn over a group of notes. I don't think occasional bits of horizontal space mean anything, but I've included them anyway. Line break as in the MS. For lute-type tab, a is an open string, then b, c, d,... move down the frets. Not all lute-family instruments use semitone frets: the Skene MS, one of the best-known early Scottish tune manuscripts, is for the mandour, a ukelele-like instrument (usually tuned A,DAda) which was fretted in major pentachords (or at least that's what the tablature describes) and I'm assuming such a system here. Cowgate gigue 2 ---ba---cb--e--|c|-dcbb:||:b dcb--d-|dcb--|c:||:cde--bb(cbabc) -dd|-|-:||:- --b--bcabbbcde--b-|]] a--cde-bbcde--bb-c(abc)a--de--dcbb|]] -cc-cc---c|]] Step one in interpreting this: replace - by x, replace a by A and b by B, make each string a separate voice, and make a plausible guess as to where the midpoint of the second part is: X:1 T:Cowgate gigue M:none L:1/4 V:1 V:2 merge V:3 merge K:none [V:1] xxxBAxxxcBxxexx|c|xdcBB:| [V:2] dcBxxdx|dcBxx|c:| [V:3] xdd|x|x:| % [V:1] xxxBxBxxBcAB [V:2] cdexBBcBABcAxxcdexBB [V:3] ccxx % [V:1] xxxBxBcdexxBx|] [V:2] cdexBBcABcAxxdexxdcBB|] [V:3] xxxccxxxc|] Now we just have to make a guess at the rhythm and the tuning. Without altering any pitch names: X:2 T:Cowgate gigue M:6/4 L:1/4 Q:3/4=100 V:1 middle=G transpose +4 % c string V:2 middle=d merge transpose -3 % F string V:3 middle=a merge transpose -10 % Bb string K:G Minor [V:1] xxx BAx|c2B exx|xxx xx c|xdc B2B:| [V:2] dcB xxd|xxx xxx|d2c B2 x|cxx xxx:| [V:3] xxx xxx|xxx xdd|xxx xx x|xxx xxx:| % [V:1] xxx Bxx|xx xxxx|xxx Bx x|BcA B3 | [V:2] cde xBB|cB/A/B/c/ Axx|cde xB B|xxx xxx | [V:3] xxx xxx|xx xxcc|xxx xx x|xxx xxx | % [V:1] xxx Bxx|xx x xxx|Bcd ex B|xxx xxx|] [V:2] cde xBB|cA/B/cAxx|xxx xd/e/x|xdc B2B|] [V:3] xxx xxx|xx x xcc|xxx xx x|cxx xxx|] which translates as: X:3 T:Cowgate gigue M:6/4 L:1/4 Q:3/4=100 K:G Minor BAG dcB|e2d gEE|B2A G2e |Afe d2d:| ABc dGG|AG/F/G/A/ FDD|ABc dGG |dec d3 | ABc dGG|AF/G/AFDD|def gB/c/d|DBA G2G|] 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. The title is the thing about the tune that caught my attention - it's the oldest tune to be named after an Edinburgh street by about thirty years. - 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] ABC 2.0 avoiding line breaks
Taking a section of canzonetta as a example and stripping out the words to avoid confusion, I was wondering how I would encode the following in accordance with 2.0 to avoid any linebreaks. % 1 - 4 [V: 1] |:z4 |z4 |f2ec |_ddcc| [V: 2] |:c2BG|AAGc|(F/G/A/B/)c=A|B2AA | [V: 3] |:z4 |f2ec|_ddcf|(B/c/_d/e/)ff| % 5 - 9 [V: 1] cAB2 |cAAA |c3B|G2!fermata!Gz ::e4| [V: 2] AAG2 |AFFF |A3F|=E2!fermata!Ez::c4| [V: 3] (ag/f/e2)|A_ddd|A3B|c2!fermata!cz ::A4| % 10 - 15 [V: 1] f_dec |B2c2|zAGF |=EFG2 |1F2z2:|2F8|] [V: 2] ABGA |G2AA|GF=EF |(GF3/2=E//D//E)|1F2z2:|2F8|] [V: 3] _dBcd|e2AF|=EFc_d|c4 |1F2z2:|2F8|] This works in BarFly, though it doesn't look pretty (might be acceptable in A4-portrait format with the insertion of a lot of y's to change the default spacing). X:1 T:canzonetta M:none % had to do that to stop error messages on the last note L:1/4 Q:1/2=120 K:F Dorian V:1 z4| z4 | f2e c|_dd c c | \ c AB2 | c A A A| c3 B| G2HG z:: \ e4| f_d e c| B2c2 | zA G F |=EF G2 |[1 F2 z2:|\ [2 F8 |] V:2 c2 BG | A A G c|(F/G/A/B/) c=A| B2 A A | \ A AG2 | A F F F| A3 F|=E2HE z:: \ c4| A B G A| G2A A| GF=E F |(G F3/=E//D// E)|[1 F2 z2:|\ [2 F8 |] V:3 z4| f2 e c|_d d c f|(B/c/_d/e/) f f | \ (a g/f/ e2)| A_d d d| A3 B| c2Hc z:: \ A4|_d B cd| e2A F|=EF c_d | c4 |[1 F2 z2:|\ [2 F8 |] I got rid of the !fermata! thing (I presume it means a fermata? if so use a standard construct for it) and also got rid of the ugly superfluous left-repeat signs and the []s round the V:n constructs (any decent parser ought to be able to handle the original, more readable, syntax for this). This, with some added y's, could be made to look okay in BarFly on portrait A4 and is a lot easier to read as ABC: X:2 T:canzonetta M:none L:1/4 Q:1/2=120 K:F Dorian V:1 z4 |z4 | f2e c|_dd cc|cA B2 |c A AA|c3 B| V:2 c2 BG|AA Gc|(F/G/A/B/) c=A| B2 AA|AA G2 |A F FF|A3 F| V:3 z4 |f2 ec|_d d c f|(B/c/_d/e/) ff|(ag/f/ e2)|A_d dd|A3 B| % V:1 G2 HGz::e4| f_d e c|B2 c2| zA G F|=EF G2 |[1 F2 z2:|[2 F8|] V:2 =E2 HEz::c4| A B G A|G2 AA| GF =E F|(G F3/=E//D// E)|[1 F2 z2:|[2 F8|] V:3 c2 Hcz::A4|_d B cd|e2 AF|=EF c_d| c4 |[1 F2 z2:|[2 F8|] What is the piece anyway? - 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] ABC as Tablature
Do abcusers know also about Wayne Cripps' tab program ? it's similar to abc and can produce good tablature for lute, converting the ascii source into postscript : As other people have pointed out, this is a somewhat theoretical possibility for some (like me; the only C compiler I've actually used on the Macs I have is first-edition-KR, and while GhostScript does sort of work it's a real pain). More significantly, tab needs a sound previewer even more than ABC does. A PostScript generator alone is just going to lead to lots of beautifully typeset nonsense. - 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
[abcusers] uppity typesetting
What I'm getting at is that I don't think an abc typesetting program should be making corrections like this. There is a fairly direct correspondance between the notational symbols in the abc file and what shows up on the rendered page. If a user *wants* a double bar they can write it in the abc file, and if they want something else they can specify that, and the typesetter should typeset it as specified. This seems to make sense. Well, to me, anyway ... couldn't these symbols just be treated literally. ie print dots where you see a :, a normal barline where you see | and a thick bar line where you see ], in any combination ? Would this cause any issues. maybe for player programs, if people started writing free-form combinations of these ? In many situations you want to be able to error-check your ABC. If you allow any old combination of barlines it can be impossible for an error- checker to tell whether you've created an empty bar by mistake or are intentionally doing Barnett Newman artwork in miniature. So it would make sense for this to be somewhat flexible; have some switch in the error checker to tell it whether to check for this or not. For the original behaviour that started this, it would surely be better for abcm2ps to have insertion of these not-written-in-the-source double bars as a run-time option. Barlines at the start of staff lines are in the same category; they're a display style matter, not something that has any business being in the ABC. (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). After working with all the different conventions James Aird used for repeats and double bars in his tunebooks of the late 18th century - sometimes borrowed from his sources, sometimes changed from one edition to the next as his tastes altered, sometimes changed by the engraver, with hardly a page where the conventions are the same throughout - I'm coming to see double bars less as a code for human communication than as a sort of rapidly mutating parasitic organism that lives at the end of tune sections in books. - 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] ABC to HTML viewer
Please note that http://www.normanschmidt.net/abassc.php is a very simple abc program at an early stage of developement. Rendering figured bass lines will be the next priority. Using what syntax? I don't recall this being discussed in detail. Nor has the semantics been discussed. It's not at all obvious how far a player program should be required to go in emulating what a knowledgeable performer would want to do with these. For starters, what source(s) are you using as a dictionary? Good idea to do this, but a bit of preliminary clarification is needed. - 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] Multivoice in ABC 2.0
There's nowhere in the tune body where you can place a single field and have it apply to all voices. There is nowhere in any ABC spec that explicitly allows that yet, but it is common for medleys to be made up of tunes by different composers or from different sources, so the informational fields should be permitted within a tune body as applying to all voices. (Having different voices by different composers is possible, as in some mediaeval music, but much less common). And of course P: needs to be like this, so that the playing order for multi-voice music can be controlled in an intuitively obvious way. It's hard to see how %%Bfly directives could be done any differently if more than one per tune were allowed - these have to start a line. And I don't see any other way you could get some effects, e.g. varying the slur curvature within a single piece (I spend more time faking that with a graphics editor than in compensating for any other missing feature in BarFly). - 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] Keyboard layout
Meanwhile, for most tunes I can type abc nearly as fast as I can play it. It's seems unlikely that any clever keyboard mapping could do much better. Having the notes all on the left hand is probably much of this. I'd never thought about that. For me that makes it more difficult - while I'm right-handed, I use the mouse left-handed, as many people do who started using mice before the IBM PC versions came along. My first was the bitpad on the ICL/Three Rivers Perq; all of us in the project had our bitpads on the left except for the left-hander, and nobody wanted to borrow his machine. And the early publicity material for the Mac always showed the mouse being used left-handed. What would help for me would be mapping the numeric keypad (at the right) to note letters. I never use the keypad otherwise, and it would free up my left hand to stay on the mouse. - 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] abcm2ps questions
I admittedly haven't thought about this, but offhand, it seems to me that it would be useful to identify country-dependendent parameters. Clearly, paper size is one---A4 seems standard in Western Europe, letter size in US and Canada (but what about former Eastern-block countries, and what about Mexico and South and Central America?) Minuscule sample: I am currently using a school notebook from Georgia (the real one) which I bought at a street market in north-east Turkey in 1991. It's 28cm x 20.5cm, i.e. narrower than US Letter and shorter than A4. I am an old-stationery freak. If anyone needs to know the format of a Bermuda Police notebook from the 1960s (handy as a travel notebook) or a Hill, Norman and Beard organ-tuner's logbook (actually I've only got the plastic cover now) or a University of Pittsburgh exam script book from the 1970s (ideal for torrential stream-of-consciousness love letters) just ask away, but I wouldn't really recommend printing music on any of them. - 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
[abcusers] *portable* representation of a very simple 3-part piece?
A recent discussion of mediaeval harmony on rec.music.early involved Margo Schulter posting a few examples in a roll-your-own ASCII notation, which led to some confused responses about proportional fonts. So, it seemed to me that ABC ought to fix that; fixed-width fonts are useful for ABC but not essential if you have software to turn it into something else. This is one of Margo's examples as she posted it: Readings of the rhythmic fine points in this rondeau, _He, Diex! quant verrai_, can vary, so that this version is only one possible solution, with each of the indicated semibreves dividing a breve taken as having equal duration (e.g. triplets at the end of the second unit): Musical Form: AB AAAB AB A | B 1 2 3 + | 1 + 2 3 + + | 1 2 3 + | 1 + 2 + 3 | 123 || C4F4 G4 A4G4 F4 E4 D4 E4 F4 G4 F4 E4 D4 B3 C4 F4F4 E4 D4 E4 E4 D4 C4 B3 C4 D4 C4 D4E4 F4 F3F3 A3 G3 A3 G3 G3 F3 My guess of what she meant, but with the part playing order commented out because of BarFly's bugs in interpreting it: X:1 T:He, Diex! quant verrai C:Adam de la Halle M:3/1 L:1/1 Q:1/1=80 % P:AB AAAB AB K:F Lydian % P:A [V:1] C2F/ G/ |A2 (3G/F/E/|D2 || [V:2] F2F/ F/ |E/D/ E (3E/D/C/|B,2|| [V:3] F,2 F,/ F,/|A,3|G,2|| % P:B [V:1] E/ F/| G/F/ E/D/ B,|C3 || [V:2] C| D/C/ DE |F3 || [V:3] A, | G,2 G,|F,3|| Margo replied as follows: --- begin quote --- Hello, there, and I'm using abc2ps, which gave curious results with the above file, but does part of what I'm going after with %%scale .92 %%maxshrink .8 X:2 T: He Diex! quant verrai T: Adam de la Halle M:3/4 L:1/8 P:ABAAABAB K:F Lydian -8va V:1 name=Tr P:A c4 fg | a4(3gfe | d4 \ V:2 name=Du f4 f2 | ed e2 (3edc | B4 \ V:3 name=Te F4 F2 | A4A2| G4 \ V:1 name=Tr P:B ef | gf ed B2 | c6|] V:2 name=Du c2 | dc d2 e2 | f6|] V:3 name=Te A2 | G4G2 | F6|] The problem is that I really don't want a line break between the two parts or sections of the piece, and it still happens, despite my using the \ characters at the end of the coded line. Maybe I should look for some other way to put an indication of the A and B sections into the score; if necessary, I could code it myself in PostScript by modifying the output from abc2ps. Of course, that isn't exactly portable abc code for exactly what I want. --- end quote --- But BarFly can neither play nor display her version. It doesn't even try to give an error report. 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. And if there's another application which can process that piece in some recognizable way, let's see what modifications you need to make for it too. - 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
[abcusers] is BarFly going to interwork with GarageBand?
I read about this on the latest TidBITS Digest. Some interesting possibilities here? http://www.apple.com/ilife/garageband/ - 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] quarter tones (non-12 tone music)
I'm a newcomer here. Has the issue of non-12 tone music come up here before? Yes, I've posted two or three fairly detailed proposals over the years, covering both playback and printing. A lot of middle eastern (Turkish, Arabic, Persian, etc...) music is based on a quarter-tone (24 division) system; or in the case of some Turkish music up to 48 (or even more) divisions of the octave. No they aren't. Quarter-tones are sometimes used in modern texts (particularly Arabic ones) as an approximation to the real thing, but the underlying model of Middle Eastern and Indian-subcontinent music is much more sophisticated. What all these genres use is the idea of a mode created by selection from a large microtonal pitch set. In Indian music this is the 22 shrutis (whose pitches are not necessarily equally tempered and probably vary between regions and idioms); in Turkish or Iranian music the basic unit is the Pythagorean comma (with a secondary measurement scheme derived from it forming a namelessly implicit 24-note non-equally-tempered pitch set which functions like the shrutis and is represented by the fretting of the tanbur). From this you derive the modes - ragas, makams, dastgahs - by selecting from that large set: 1. a rising pitch set 2. a falling pitch set 3. a few optional accidentals 4. a bunch of standard melodic cadences The rising and falling sets are not usually very different and don't have more than 7 notes, the accidentals tend to be used sparingly, and the cadences can't be represented in a key signature. So what happens is that people reduce each mode, for purposes of printing, to one key signature (the rising scale) and indicate the variations used for falling passages or cadences by accidentals. That system makes a suitable target for an ABC representation. The elements that need to be incorporated are: 1. the underlying pitch-measurement scheme (shrutis, commas, cents, harmonic ratios, rational fractions of a tone and probably others I haven't thought of) 2. selections from that to (reusably) define 7-note modes, mapping these onto ABC note names (Indian music uses modes with fewer notes, but these are considered as derived from 7-note modes) 3. a means of representing accidentals in ABC source 4. a library of graphical signs to represent the microtones in either the key signature or in accidentals within the tune body when creating staff notation (there are only a few of these, see any text on Middle Eastern music). What that would give you is a representational scheme which extends ABC in exactly the right way to match the model of microtonal-modal music already in use by its practitioners. A scheme which requires people to use MIDI and fractions is so alien to the way anybody actually thinks about this stuff that it would be utterly unusable. You MUST have a way of defining named modes so you can refer to notes by single letters, the way you find them named in Indian music texts. Karl Signell's _Makam: Modal Practice in Turkish Art Music_ is a good place to start in identifying the issues (he makes a clear distinction what what happens notationally and what actually goes on in practice, something Turkish sources tend not to do - there are situations where you want to notate theoretical rather than actual intonation, just as there are in Western diatonic music). - 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] Ties over alternate endings
With abcm2ps, how do I do ties over alternate endings? If I have the following: Â X:1 M:4/4 L:1/4 K:C CDEF|1FGAB:|2FGAA |] How do I tie the first F with both the second (|1F) AND the third (|2F) F? I don't think there is any way to specify that in ABC. But you don't need to in this case: restructure the tune as CDEF-|FGA[1B:|[2A |] It would be better if we allowed the tie to act as a prefix operator on the second note: CDEF|[1 -FGAB:|[2 -FGAA |] though it would be an adventure either parsing that or deciding what to print for it in staff notation. - 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
[abcusers] Macintosh juju for a mailing list tunebook
Do the following:
1. Get Casey Fleser's FKEY ClipFiler (I used version 1.3).
2. Open one of the supplied FKEYs (I used number 7) with ResEdit.
3. Open the kinf resource and change the string ttxt to Bfly.
4. Open the FKEY resource and change the string
clip
to
% -- clip
5. In the same resource, change the string Clippings to ABC Clips.
6. Drop it into your Fonts folder.
What this gives you is the ability to select an ABC tune from a mailing
list like this one, hit apple-shift-7, and get the tune appended to a
text file belonging to BarFly on your desktop called ABC Clips, with
an ABC-comment separator line after it. Which is about the easiest way
imaginable to maintain a commonplace book of tunes.
I've been using this FKEY for years to keep a BBEdit scrapbook named as
per the default, Clippings (for historical reasons, number 8). It only
just occurred to me that I could easily maintain two commonplace books,
separating the tunes out as I saw them.
Works on versions of MacOS from 7.1 to 9.1. God knows what happens on
OS X, I don't have it. I suspect it will work on systems as far back
as 3.2, since FKEYs appeared around then (though I doubt if you could
run either a mail application or BarFly on a Mac that old...).
I can send a preconfigured FKEY to anyone who likes the idea better
than they like the prospect of ResEdit hacking. (Do not change the
lengths of the strings when editing them or your Mac will explode into
droplets of green slime).
-
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] ABC and MusicXML
as far as our site is concerned, abc's importance lies more in a simple storage method and having nice programs to produce graphics and MIDI than in human readability of abc. (perhaps John Chambers for example to confirm or deny this... Do most casual visitors to a site want a MIDI to play back or a GIF or to download the abc itself for a tune?).. Most people want GIFs. But if they're going to do it on their own machines, rather than via the TuneFinder interface, the ABC better be straightforward and easily editable, since the usual reason for wanting a different score than the way it comes off the Web is if you want to change the notes themselves in some way. If there were abc2MusicXML and MusicXML2abc converters, would it possible to produce abc that always conformed to the same set of abc rules? It would be, but it would throw away many of the distinctive things ABC can express. For eample, look at the pibroch example in my modes tutorial. I put the canntaireachd form of the music at the right margin as an ABC comment (it would be messy to include it as if it were a song text). Unless your ABC - XML translator retained the original ABC source, there'd be no way to recover that information after a round-trip translation. What I've done there is perfectly standard and works in any reasonable ABC implementation, but it's not invariant under translation to anything else whatever. One problem I have that has been commented on by Jack Campin for one is that our abc is not always as clear to read as it could be. I agree with that but on the otherhand, on a site stuggling to get any contributers, the last thing I want to do is stipulate rules as to how the abc should be written (especially given our main aims above - that it works on abcm2ps and abc2midi is the priority... but it would be nice to improve in our abc for those who want to read it) or even what software should be used (e.g. our main contributer uses Harmony Assistant) as the tougher I make it, the fewer will be willing to try. The answer to that one is a human editor. How much is there on your site? Maybe I could help if it isn't going to mean hours of connect time link-hopping. A big problem with abc for me is the multiple ways abc has of doing the same thing, e.g. broken notation vs explicit note lengths, the ability to write 3/2 or 3/, etc. particularly when not everyone [and that pretty much includes me because of music reading difficulties] can use abc directly.) It needs to be like that to handle different kinds of music. Default note length is the one that makes the largest difference - for songs, you usually get the most readable source by making it 1/4, whereas for 2/4 pipe marches it's usually 1/16, and the default is in between. No way round that, there really are different numbers of notes per bar in each, and if you pick the wrong one you will reduce readability by introducing superfluous numerals or /'s. (Bruce Olson made a very bad decision of this type; his default length is twice what it should be, so nearly every note on his site has a /2 associated with it). Also, if other programs can export XML directly, I guess that will help to if we can produce abc from that? Only given a *very* sophisticated translator. Why use ABC as an intermediate format if you aren't using its distinctive advantages? As a base for computer-translation-to-anything, XML is surely going to outdo ABC as its toolbase grows. ABC only wins out when you need to tinker with the music yourself, and that needs readability. - 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
[abcusers] somebody on this list has a virus
I just got a virus bounce message from Freeserve; their virus checker was under the impression that [EMAIL PROTECTED] had sent one of their users an infected message. This list was not itself involved: they quoted some of the headers back to me and they show that the virus used my address as the putative sender. That address is only used for this list, and it's unlikely that messages containing it will have propagated far beyond it. So, there must be a list reader using Windows and Outlook Express with a virus. Among the readers of this list that is *not* a common setup, most of us know better - so if that's what you've got, check what your system is doing. - 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] Exporting to Midi.
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. Just what has been going wrong with the QuickTime development process that they've shipped such buggy products for so long? - 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] Exporting to Midi.
there is a bug in Quicktime 6 which causes long notes to be truncated (played staccato) when generating a midi file. [...] 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. 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. Could BarFly not do the same thing for you, postprocessing the MIDI files in the same way a human editor would? (I don't know of a cheap or freeware MIDI editor for the Mac, is there one?) - 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] ABC and MusicXML
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. Yes, better to put them in a separate voice if possible. 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 | No. Barlines are far less obtrusive if you align your source properly, and taking three characters to express each one can soon run you out of columns in attempting to align a complicated piece. Any readability problem with this? X:1 T:The Rose Tree M:C| L:1/8 Q:1/2=112 K:D fe|d2B2 A2F2|A4 A2AB|d4 e2de|f2e2 egfe| d2B2 A2F2|A4 A2AB|d4 e2de|f2d2 d2 :| de|f2e2 f2g2|a2ba g2f2|e2b2 b2a2|b2e2 egfe| d2B2 A2F2|A4 A2AB|d4 e2de|f2d2 d2 :| and if you want repeats, this is more readable than your way, as the [1 notation says clearly what the numeral is for and you only use one way of expressing the repeat boundary rather than two depending on where in the bar the repeat starts: X:2 T:The Rose Tree M:C| L:1/8 Q:1/2=112 K:D fe|d2B2 A2F2| A4 A2AB|d4 e2de|f2e2 egfe| d2B2 A2F2| A4 A2AB|d4 e2de|f2d2 d2 :| de|f2e2 f2g2| a2ba g2f2|e2b2 b2a2|b2e2 egfe| d2B2 A2F2|[1 A4 A2AB|d4 e2de|f2d2 d2 :| [2 ABAF A2AB|d4 e2de|f2d2 d2 |] Though usually you'd write this instead, making the repeat unit a more meaningful piece of musical structure: X:3 T:The Rose Tree M:C| L:1/8 Q:1/2=112 K:D fe|d2B2 A2F2|A4 A2AB|d4 e2de|f2e2 egfe| d2B2 A2F2|A4 A2AB|d4 e2de|f2d2 d2 :| de|f2e2 f2g2|a2ba g2f2|e2b2 b2a2|b2e2 egfe| [1 d2B2 A2F2|A4 A2AB|d4 e2de|f2d2 d2 :| [2 d2B2 A2F2|ABAF A2AB|d4 e2de|f2d2 d2 |] And it's usually easier to find a reasonable staff notation layout for 20 bars than is for 19, e.g,. for five bars to a line: X:4 T:The Rose Tree M:C| L:1/8 Q:1/2=112 K:D fe|d2B2 A2F2| A4 A2AB| d4 e2de| f2e2 egfe|\ d2B2 A2F2|!A4 A2AB| d4 e2de| f2d2 d2 :|\ de|f2e2 f2g2| a2ba g2f2|!e2b2 b2a2| b2e2 egfe|\ [1 d2B2 A2F2| A4 A2AB| d4 e2de|!f2d2 d2 :|\ [2 d2B2 A2F2| ABAF A2AB| d4 e2de| f2d2 d2 |] - 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] ABC and MusicXML
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. - 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
[abcusers] something that ought to work...
Warning, message is this wide
-|
I sometimes find I'd like to either transcribe the melody notes from
a bagpipe score before adding the gracenotes, or extract a version of
the tune with the gracenotes removed. One way to do that would be to
put the melody and gracenotes in different voices and merge them for
playback or printing. Like this (with the added oddity that I've
assigned the melody and gracenotes to dfferent instruments, neither
of them the bagpipe):
X:1
T:The Little Cascade
S:MacLennan's collection
C:G.S. MacLennan
V:1 midi program 1 11 transpose -12
V:2 merge midi program 1 46
M:C|
L:1/8
Q:1/2=104
K:E Hp
V:1 Be```eg ge```Bg | gf`eBgB```eg |[1 Be```eg
ge```Bg | fd```Ad fagf :|
V:2 {d}xx{A}xx {a}xx{g}xx | {a}xx{gef}xx {a}xx{g}xx |[1 {a}xx{A}xx
{a}xx{g}xx |{afg}xx{e}xx {g} :|
%
V:1 [2 Be```eg
ge```Bg | fagf f2e3/|:\
g/| fB```gf eg```Bg | fBag g2fg |
V:2 [2 {a}xx{A}xx
{a}xx{g}xx | {a}{gfg}x2{eA}x3/|:\
x/| {afg}xx{a}xx {g}xx{a}xx |{afg} {a}x2{fe}xx |
%
V:1 fB```gf
eg```Bg | fagf f2e3/:|\
g/|: G2 Be Be```ge | g2 fg eg```Be |
V:2 {afg}xx{a}xx
{g}xx{a}xx | {a}{gfg}x2{eA}x3/:|\
x/|:{aGd}x2{d}xx {g}xx{a}xx | {gf}x2{a}xx {a}xx{a}xx |
%
V:1 [1 G2 Be Be```ge | fd```Ad fagf :|[2 G2 Be
ge```Bg | fagf f2e3/||
V:2 [1 {gGd}x2{d}xx {g}xx{a}xx |{gfg}xx{e}xx {g} :|[2 {gGd}x2{d}xx
{a}xx{g}xx | {a}{gfg}x2{eA}x3/||
%
V:1 f/| g```efg efg```e | f```def def```d |g```efg
efg```e | fag```f f2e3/:|
V:2 x/| x{a}xxx {a}xxx{a}x | x{g}xxx {g}xxx{g}x |x{a}xxx
{a}xxx{a}x | xxx{a}x {gfg}x2{eA}x3/:|
%
V:1 g/| Be```gf e2 fd| Be```df ed```B```A| Be```gf
e2 fd| Be```df f2e3/:|
V:2 x/| {a}xx{a}xx {GdG}x2 {g}xx| {g}xx{g}xx {gef}xx{g}x{d}x|{d}xx{a}xx
{GdG}x2 {g}xx| {g}xx{g}xx {gfg}x2{eA}x3/:|
%
V:1 g/| Gd```Be df e2| gfge Bega |[1 Gd```Be
df e2|
V:2 x/| {a}xx{g}xx {g}xx{gef}x2| {a} {g} |[1 xx{g}xx
{g}xx{gef}x2|
%
V:1
Be```df f2e3/:|\
[2 gfge fd```ed | Be```df f2e2 |]
V:2
{g}xx{g}xx {gfg}x2{eA}x3/:|\
[2 {ga} {g}xx{g}xx | {g}xx{g}xx {gfg}x2{eA}x2 |]
In practice, BarFly can play that okay, but display hits one of the
spots where there's a red warning triangle on the roadway and Phil
can be seen standing by it with a shovel. Does any program get it
right?
-
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] something that ought to work...
Just a thought - are the text spacers supposed to have any effect on the score, or just space the abc listing? They only affect the source - intended to aid readability by letting you align notes in the ABC without breaking beams in the staff notation. In this case they fill the gap where the gracenotes go. (There's a poem by the Scottish poet Edwin Morgan that works the same way - the text has random holes in it and there is a companion poem of verbal Polyfilla with the missing text in the right places to plug the blanks). I've used them in almost every tune I've transcribed since BarFly began to support them. 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. - 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] something that ought to work...
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... That's got to be a stopgap. - 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] something that ought to work...
Phil faster than a speeding bullet Taylor wrote: Jack Campin wrote: [ what BarFly drops when in !-line-end mode ] 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? 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. [...] (Other BarFly users please note that this may not work for you - Jack has a pre-release copy of the next version.) Good grief. If you were made of silicon I think we'd call this branch prediction. 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. 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. - 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] !Current specification!
I was under the understanding that since Jim Vint introduced the ! token in Abc2Win and that it was only valid as a final character (excluding whitespace characters) before EOL. No, you can find it anywhere in ABC2WIN-created files. What I should have added: particularly in those files created by experienced users. Newcomers to a formal notation often invent syntactic restrictions that aren't really there. As the adoption was grudging, I thought it was insistent that it NOT be inline, but only at the end of a line where it does not really affect reading. That's completely backwards. The point of having ! in the middle of a line is that that's the ONLY place where it can have a positive effect on readability. Having it at the end of a line is the ONLY place where it has a consistently negative effect on it (since it's redundant there). I argued that ! should coexist with newline-as-staffbreak, just to avoid cluttering the ends of lines up with unnecessary ! signs - BarFly hasn't implemented that, but in practice the number of \ escapes you'd need if you had both would be not far short of the number of end-of-line !s you need with its present setup, so it's no big deal. - 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
[abcusers] reusable parser
[order fixed - please don't top-post] Stephen Kellett wrote: Christian M. Cepel [EMAIL PROTECTED] writes I would assume that such a beast would be written in straight ansi c to make it available to any present or future operating system sporting a c compiler, as well as to make it as small and as resource non-intensive as possible. C++ Surely? C is very restrictive in comparison. Writing object based code in C is hard work (read: un-necessary extra code, and lack of type safety) compared to C++. Resource economy is a non-issue - it's not going to be that big and by the time it's done, any computer that will use it will be much, much bigger and faster than anything now running ABC software. Java and C# are not worthwhile alternatives. Both quite restrictive because nothing is truly passed as a reference (try modifying a string object you pass in and see if it really was changed after the method call - if it was really passed as a reference it would be). Makes things trivial in C and C++ a real pain in Java and C#. But, things relevant to this problem? Sharing by reference is a great way to make code less maintainable, and parsers don't need to do it, ever. If they were easier to compile into libraries, SML, Haskell, Lisp or Prolog would be better options - they all have a hell of a lot of accumulated experience in use for parsing refractory syntaxes. Is this a case of if the only tool you have is a hammer, every problem looks like a folk singer? - 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] abc2braille or abcm2braille
How can I convert abc to braille? [ I have Anette Stramel here as I write; she's a blind ABC user ]. Can you explain more? Do you want to print it? - that may need going through a DOS-based braille printer (allowing for a line width of 30 columns). Otherwise, you just use a Braille display as with any other text. - 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
[abcusers] name that Irish jig
Ideas anybody? X:1 T:unkent/unbekannt M:6/8 L:1/8 Q:3/8=124 Z:Anette Stramel Jack Campin May 2004 K:D AFD F3 |AFD EFE|DFA ded|BAF A3 | AFD F3 |AFD EFE|DFA ded|BAF D3:| FAA BAA|dAA BAd |FAB ded|BAF EFD| FAA BAA|dAA BAd |FAA ded|BAF D3:| - 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] AlphabetSoup output data structures
That's a standard rule of music. You can't put black and white notes on the same stem for instance. Actually, this isn't a rule at all. Music printers routinely put white and black note heads on the same stem. 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 how would you indicate a crotchet (quarter) note starting at the same time as a quaver (8th) on the same stem? Usually you don't. That wasn't what the original suggestion was. With minims and quavers there's no ambiguity. ABC has a somewhat more general representation of a chord of notes, since each note can have an arbitrary length. But it has some other limitations that aren't present in staff notation. For example, in guitar (and some keyboard) music, you'll see notes with dangling ties that don't lead to another note. This means let it ring, which can be done on those instruments. [G,-C-E-Gce] [xxxB] [G,-C-E-Gce] [zzzB] both ought to represent ringing the three lower notes across both beats. In BarFly this doesn't yet work right either on display or playback. - 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
[abcusers] thinking in the large
My parser will be using the non-graphic parts of Cocoa GNUStep, so it should be highly portable. The printing code I'm writing, on the other hand, will necessarily use graphics, but I'm hoping it will work on most (and maybe all) systems. On the Mac, at least, it will output PDF natively - I'm not sure on the other platforms what the output will be yet. Why not XML instead of direct printing, and reduce the graphics problem to one of generating PDF from XML? - such tools are bound to be created anyway. Some of the suggestions here seem to assume that ABC will only be used as the input to a series of filters. That doesn't fit some patterns of usage. For a start, it doesn't fit with what a structure editor does. And presently, just about any ABC user can store all the ABC ever typed in by anyone on their own machine, and disk sizes are expanding much faster than the ABC corpus, so it's likely to remain the case that anyone can hold a copy of all the ABC every made publicly available. It's time to stop thinking in units of individual tunes, tune files, or even tune sites: the only reasonable unit is the entire corpus. The corpus is already a small, ad hoc distributed/replicated/federated database - there are multiple near-complete archives around - and any new parser has to help that work more effectively. (Some numbers. There are no more than 50,000 Scottish-traditional-idiom tunes in existence. Making some deliberate overestimates, assume 50 different versions of each have been coded and that Scottish music is 1% of what's been put into ABC. At 1K per tune that's still only a third of a CD; on a fast broadband link you wouldn't have time to go for a pee before the download finished). So operations on large-scale ABC databases are likely to become more important - things like: - storing the tunes in a database, parsing and indexing them at entry time - distributed versioning, so that an ABC creator could get forwarding pointers or editing commands inserted into superseded copies of tunes - plagiarism search (assume the entire Harry Fox Agency database) - mending corrupt tunes by finding better versions of garbled parts - collating information from all copies of a tune, so you could unify the discography from one copy with the detailed formatting code from another - indexing the corpus of tunes by harmonic progression, as calculated by something like ABCMus's auto-harmonizer, and allowing fuzzy search All of that would be easier if persistent parse trees were available. It's a pity the Tune Finder doesn't yet have options to download everything it knows about or synchronize your own mirror with it. In the long run this might be *less* resource-intensive than what it's presently doing, as complete downloads could be offloaded onto mirror sites and intelligent synchronization of updates doesn't need to be any more expensive than search. - 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] !Current specification!
Thats one of my two dislikes of Macs done away with. The other one is the menuing system. Click and hold is bad for anyone with WRULD / RSI. The Windows Click, release, mouse/key around as you please then click when you are ready is good for RSI. Can you configure the Mac to have menus that are good for you rather than bad for you? Again, an old issue, long since fixed in Mac OS X -- you can click and release on the menu bar and the menu will stay popped up until you select from it. (And you can click and drag as well... Or click and release then use arrow keys.) Older Mac systems had it too, called Sticky Menus (I forget if this appeared originally in Mac OS 8 or 9), and again, third parties have had this fixed for ages. There was something built-in to the OS that gave you the option of click-and-stay-dropped (sticky) menus back as far as OS 7.6, I think. It's certainly there in OS 8.1. I generally find sticky menus slightly annoying but not annoying enough to turn them off. The first mouse - actually bitpad puck - I used had four buttons. I don't miss the other three, and anybody who puts an asymmetric two-button mice on a public computer with no instructions on how to remap the buttons needs to have one hand superglued to their bum 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 search session on a Windows-based library computer where you have no admin privileges?) - 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] thinking in the large
| So operations on large-scale ABC databases are likely to become more | important [...] | All of that would be easier if persistent parse trees were available. | It's a pity the Tune Finder doesn't yet have options to download | everything it knows about or synchronize your own mirror with it. Actually, doing that would be not just feasible; it would be easy, except for that one little elephant hiding over there in the corner: Copyright. I did talk about material made publicly available. One of the examples I gave was of using a large ABC database specifically to trace copyrights. This is an opportunity, not a constraint. The person responsible for an ABC tune being on the web/in a database is always identifiable. (If a file has been uploaded by an anonymous user, the person providing the anonymous upload service is responsible, and so on. This all has familiar, agreed legal analysis going back to Martin Luther's time, and maybe even before the invention of printing). Ownership flows downstream from the author, responsibility flows upstream from the consumer, and hopefully they meet somewhere in the middle if money's changing hands. What a parser needs to do, in the large-scale environment we are now operating in, is not lose information about who owns bits of ABC. For example: the Aird volume 1 file on my website is a pretty accurate transcription, the best out there, but it's not perfect and I know where the mistakes are. I haven't fixed them because I'm publishing a much more polished version (yeah, I know, long delayed, for reasons you really don't want to know about). It would be pretty easy for somebody with a copy of the polished version to diff what they've got with the free one and upload the result. Now one way I could deal with that would be to put something in the public version saying who Iam, how to contact me, and no merging with other editions of the music without my say-so. Other people wish to put other restrictions on use of ABC content; one-time printing, playback only, all use to be accompanied by explicit credit, micropayments to agencies like PayPal for certain categories of use, or whatever. If this stuff is in the original ABC header (and there's no reason why it can't be) the parser can pass that on to its clients; in fact the parser can *require* that clients do some explicit negotiation to confirm that statements of ownership and use restriction have been interpreted before they get at the parsed data they want. This kind of thing is familiar in security analysis; data flows are easily traceable if you build the right support in. Google's image bank does something like this in a brutally simple way: you only get to see more than a thumbnail of an image along with its context, and chances are the publisher of the image will have said what can be done with it somewhere in the chunk of context that Google shows. They're doing something much like what I do with the (subset of) ABC files on my website where I want downloads to be all-or-nothing. There is a subset of the ABC corpus where these issues are largely ignorable; one way to exploit that would be to build up from a core of known-PD material from whitelisted sources who are prepared to vouch for the fact and take responsibility, rather than just slurping up the entire ABC universe indiscriminately. But that's probably only a fraction of what's already out there. The other stuff needs some form of electronically assisted rights management, and it's a great strength of ABC for that application that it's so easy to annotate. This needs some extra header syntax to represent ownership and use constraints. It also needs something more basic, authentication; something like the PGP signatures attached to messages. (Otherwise I can upload an ABC of Yesterday, say I'm Paul McCartney and get royalty payments directed to my PayPal account). - 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] reusable parser
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've given several developers here copies of my CD-ROMs, as they're large, carefully transcribed collections, intended to be used far into the future, and where any idiosyncrasies are deliberate. The dialect of ABC I use is basically BarFly-with-the-bugs-fixed and without using some of the more arcane stuff. The idea is that if any incompatibilities should arise in futurw, it'll be clear enough what I meant that any musically knowledgeable user can fix the problem. The one important place where I've gone beyond anything BarFly has at present is in using part playing order for multivoice pieces with the same semantic model as in the 1.6 standard for monophonic ones. It's obvious what I mean but no software can interpret it yet; I have no intention of altering it until someone comes up with a syntax that expresses what I want, and meanwhile there are hundreds of CD-ROMs floating about with this construct done my way. There's a sample on my Music of Dalkeith website which has a bunch of ABC tunes with MIDI, QuickTime and GIF tadpole equivalents that I've generated and proofed myself, so the intended semantics is publicly available. I would suggest that test cases be documented the same way. This brings up another design/requirements issue when constructing this parser: to what degree should the parser be lenient with non-standard abc usage? For handling a large corpus (and preferably the entire corpus) you don't just want to be lenient, you want to provide error handling that will help a client disambiguate almost anything the most misinformed newbie might have tried with the aid of the least standard software or none at all. The musical content might still be valuable and the originator might be dead. - 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
[abcusers] Re: PERL ABC script?
For some reason this got sent to Dafydd instead of to the list, so here it is again: [unedited top-posting fixed] Is there a reliable PERL script out there that can convert ABC to images/midi? most sites which provide midi or postscript from abc will be using a simple script which invokes abc2midi or abcm2ps. Which is a bit of a problem, as I don't have command-line access to my web host. My problem is: I have a site where people can submit tunes in ABC. Why not ask them to submit in other formats too? Chances are they'll all have their own favourite tools, and if you get them to do it you'll know that the conversion tool used was appropriate for the ABC they wrote. (I would *not* be happy to have any of my transcriptions auto- munged by abc2midi in its out-of-the-box released form, and people who wrote tunes exploiting its interpretation of rhythmic constructs would not be happy with how more standard ABC software translated them). For the Welsh music you're doing, are you happy with what ABC gives you, or do you need more? How about special notations for the triple harp? - 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] Re: PERL ABC script?
[top-posting fixed and unnecessary quotation removed AGAIN] I would *not* be happy to have any of my transcriptions auto-munged by abc2midi in its out-of-the-box released form, and people who wrote tunes exploiting its interpretation of rhythmic constructs would not be happy with how more standard ABC software translated them I'd be quite happy to put a tune through abc2midi - if it was way out I'd complain, but otherwise I'd be cool about the idea. The problem is with broken-rhythm constructs. The ABC standard says these have a 3:1 ratio, but the implementor of abc2midi made it 2:1, that being the norm for hornpipes. The result is that a strathspey, pipe march or dotted jig in ABC run through abc2midi sounds rather silly, and if you change the default (there are various ways of doing this) a hornpipe will sound exaggerated. Some sites have fixed abc2midi's defaults to bring it ine with the standard, others haven't. The standard way probably accounts for many more uses of the construct by now, but either choice guarantees you'll get some tunes processed into something the transcriber didn't want. Remember there is a very large site that uses abc2midi - it's called thesession.org and it works very well. I just had a look, but couldn't see any way to extract a MIDI file from it. And extracting ABC wasn't much fun either. Using a text editor on the HTML source, I get this from their site after removing HTML tags: X: 1 T: Gan Ainm M: 4/4 L: 1/8 R: strathspey K: Emin ED^em|:B,/2E3/2E3/2F/2 G3/2E/2G/2B3/2| DA3/2G/2F3/2E/2 D3/2E/2F/2D3/2|^emB,/2E3/2E3/2F/2 G3/2E/2G/2B3/2| e3/2d/2B/2d3/2Gd/2e3/2gf|^eme3/2f/2e3/2d/2 B3/2c/2d/2B3/2| DA3/2G/2F3/2E/2 D3/2E/2F/2D3/2|^emB,/2E3/2E3/2F/2 G3/2E/2G/2B3/2[1| DA3/2F/2D/2F3/2^emE2ED:| [2DA3/2F/2D/2F3/2^emE2F/2A3/2 |:B/2E3/2E3/2D/2 B,/2E3/2E3/2D/2|B,/2E3/2D/2F3/2 G3/2E/2G/2B3/2| DA3/2F/2E3/2D/2 B,/2D3/2D3/2E/2| F3/2D/2F3/2G/2 A3/2F/2G/2A3/2|^emB/2E3/2E3/2D/2 B,/2E3/2E3/2D/2| B,/2E3/2D/2F3/2 G3/2E/2G/2A3/2|B/2e3/2d/2e/2f e3/2d/2BG| [1DA3/2F/2D/2F3/2^emE2F/2A3/2:| [2DA3/2F/2D/2F3/2^emE2|] Using broken-rhythm constructs, sorting out the anacruses to avoid needless repeats, and lining things up for readability, I get this: X:1 T:Gan Ainm M:4/4 L:1/8 K:E Minor ED |EmB,EEF GE`GB|DAG`FE DEFD|EmB,EEF GE`GB| edBd G degf | Emef`ed Bc`dB|DAG`FE DEFD|EmB,EEF GE`GB|DAFDF EmE2 :| FA|EmBE`ED B,EED| B,EDF GEGB|D AF`ED B,DDE| FDFG AFGA| EmBE`ED B,EED| B,EDF GEGA|Be d/e/f ed`BG |DAFDF EmE2 :| The two versions should sound exactly the same. With abc2midi as released, they don't. If you can see a way to get a MIDI out of that site, can you put my version in to check what it does? (I can't identify it either, though it sounds a bit like both The Highlands of Scotland, a tune in Kerr's collection from the 1880s, and The Banks of Spey, a tune by William Marshall). - 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
[abcusers] Re: PERL ABC script?
For the brave amongst you who want to see my site: http://www.welshtraditionalmusic.com Please check it out, and let me know if you have any ideas to make the tune submission painless! Not sure about submission, but some teething troubles: - you are using O: where B: or S: would be preferable - O: is the geographic place a tune a comes from, not the book or recording you found it in. - uneven numbers of notes on each line of staff notation (e.g. The Flower of the Thorn, Hoff Fron). - incorrect mode (everything is assumed major). - you don't always have beam-breaking spaces in the usual places, in fact no spaces at all in some tunes. - it might be an idea to put all the ABCs into one file; there aren't that many of them, and files only start to get really unwieldy when you get past 1000 tunes. Otherwise, the design looks fine. - 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
[abcusers] this tune intentionally left blank
I have some ABC files where I use the notation as a tunographic database - there is no body, either because I haven't got round to typing it in or don't intend to. The GS MacLennan tune file on my website is an example: I've included bodies for the tunes I can reproduce with no problem, but for the copyrighted ones I've simply included a header to describe the tune and say where to find it. I can imagine this might cause problems for some ABC software, indexes like JC's Tune Finder in particular. Having a reference to a print or audio source for a tune is an advance on having no information about it at all, so these null-body tunes should be indexed, but processing pipelines intended to create sound files or staff notation will need to throw an exception. Would it be easier if there were an explicit keyword to declare there was no body for the tune? If so, what? - 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
