>> I've been working on an Abc 2.0 proposal, which is a stripped-down
>> version of 1.6. Amongst other things, I removed most of the headers
>> (notably A-G, X and Z, to avoid confusion with notes and rests).
> In my view of things, removing the C:Composer field steps just over
> the line in being too radical :0( I really like to see this header
> just under the title, where it doesn't get lost.
Most of those are too widely used to be thrown away, though some
are too vaguely specified to be given a reliable semantics.
I use G: ("group") to indicate the rhythm of a tune, e.g. jig or
reel - the problem with using R: for it is that player programs will
usually interpret it to impose their own rhythmic interpretation,
which with Scottish music is nonsensical since tunes are equally
likely to be written straight and pointed, and adding even more
accentuation to something written with dots sounds bizarre.
I use F: on my CD-ROMs to give the file:// URL of the ABC. People
may want to find the original of something again after copying it
elsewhere and editing it. (I think I may also use this for the
http:// URLs of things I've put on the Web; if not I ought to).
I use A: for the author of the words. This violates the 1.6 spec,
but the "area" idea just doesn't work - you can't fit the geographic
description of a tune into a one-liner.
I use B: in every tune I've copied from paper to identify the exact
copy of the text I used (e.g. library catalogue number) - the name
and other generic info about the text goes in the S: field. I must
have thousands of instances of it.
Many, many people use D: and where they do it is exactly the right
place to put the information.
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.
-----------------------------------------------------------------------------
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
