For the benefit of the newer members of this list, I'd like to give some
information about the way we got here.
Those that have been reading this list for a while will know that I
have a bee in my bonnet about the U: field, macros and the mess which
the abc 1.7 "standard" has created around them.
About eight years ago, there were two abc lists, this one and a closed
developers list. The U: field came about as a result of discussions
on the developers list. I don't remember who made the original
suggestion, but it was adopted as a means of defining the meanings
of the single characters H..Z, which the standard explicitly made
available to represent all of the other musical symbols which were
not already defined. Since there are hundreds of possible musical
symbols and only 19 letters, a method was needed to reassign the
symbols to different letters, and it was suggested that this should
be done as follows:
U: K = segno
Now, a program which knows what a segno is can draw one (or use it
to control playing sequence) whenever it encounters the letter K.
This was consistent with the existing standard, and since it's
unlikely that any one piece of music would need more than 19 different
extra symbols it provided a complete solution to the problem. I
implemented it in BarFly, and documented exactly how I'd done it
on my web site so that any other developers could see how to do it.
Note that this is not a macro definition; it's not implemented by
substituting text in the original abc but by re-mapping the meaning
of the letter K, and can only be used for those symbols which a
program knows how to draw or play.
Macros were my suggestion; I was looking for a flexible way of playing
ornaments, given only a few symbols to represent them in the abc.
I suggested that to play the ornament represented by the tilde
character in abc you could use a definition like this:
m: ~G3 = G{A}G{F}G
When playing the abc, a program would search the tune for every
instance of the string ~G3 and substitute the string G{A}G{F}G
(it's an Irish roll the way a whistle or flute player would do it).
Of course you would need a separate static macro for every different
note with a roll on it, and Henrik Norbeck suggested an extension to
this - use the letter n to represent the principal note, and other
lower case letters adjacent to n in the alphabet for related scale
steps, then let the program transpose this to produce the correct
ornament on any principal note:
m: ~n3 = n{o}n{m}n
Once again, I implemented this in BarFly, in such a way that the user
can turn it on or off separately for both playing and display of music.
Again, I documented it on my website. It proved a very useful extension,
and the program now comes with several files of symbol and macro
definitions which define how rolls, turns mordents and trills are to be
played or displayed for different purposes. Using it I was able to
transcribe the entire Golberg Variations into abc, and have it play and
display complete with all the baroque ornaments Bach prescibed. Likewise
I can play a traditional Irish reel with the rolls sounding correct as
played in Donegal or in Clare depending on which external macro file is
selected.
Many years later, along came John Atchley, a developer with a burning
desire to fix the abc standard. He put together the draft 1.7 standard
and persuaded Chris Walshaw to put it on the abc home page. Most of
what he put into it was (and is) uncontroversial, and simply codified
what the more advanced abc programs were already doing. Unfortunately,
he didn't look much beyond abc2ps and his own clone of it, and he had
different ideas about what to do with the U: field. He introduced
the !...! format (breaking zillions of old abc2win files on the net)
and totally confused the two concepts of symbol redefinition and
macros. Then he went away, and we haven't heard from him for
a couple of years.
I argued against this draft standard on this list (the developers
list was dead by this time), first politely and then LOUDLY.
I made it clear that I was not going to give up an extension system
which was very successful and appreciated by my users in favour of
of something which was demonstrably inferior. I was ignored.
Jef Moine went ahead and incorporated the !...! into abcm2ps,
and James Allwright used it in abc2midi. Everybody else thought
this was the "de facto" standard and so here we are. John Chambers
doesn't understand what I'm talking about, and neither, I suspect,
does anybody else who hasn't used BarFly. This list is dominated
by Linux users, none of whom seems capable of even giving consideration
to anything which isn't open source, and doesn't run on their
platform.
I'm not averse to compromise - I've made lots of changes to my program
to improve compatibility. I support the %%staves directive from
abcm2ps, even though it's utterly cryptic, and so badly documented
that I had to run the program and experiment with it to figure out
how it works. I deprecated the use of V: fields on the same line
as the music because nobody on this list liked it. I introduced
the middle directive so that BarFly users could have clefs other
than the treble work the way they do in abcx2ps. Every extension
I have introduced has been announced and discussed here, and
publicly documented.
I've got to draw the line somewhere however. I will accept no
new abc standard unless it sorts out the mess surrounding the
current use of the U: field.
Phil Taylor
To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
