Well, there hasn't been much response on the list, though I
did get a couple of private messages on the topic. It seems
to me that the main question to be decided is between:
John Chambers wrote:
m: T !trill!
m: ~ !roll!
m: H !fermata!
Phil Taylor wrote:
| U: R = arpeggio
As I recall, there might have been one or two other letters
suggested in addition to 'm' and 'U'. Anyone recall? This
isn't a real big deal, of course. The actuall syntax is
more of a deal, but even that isn't all that important. I
have no fear of the idea that my implementation would make
both the '=' and the '!' optional. I doubt if many other
programmers would consider this a major hassle.
What I'm considering is just a trivial definition facility
that amounts to no more than text substitution, plus code
in the parser that recognizes and accepts a list of !...!
symbols. I figure I could implement this in a morning.
One of my primary motives is that my tune finder is trying
to return tunes from around 240 web sites now, and there is
little consistency in what some of the letters above G
mean. This doesn't matter if people fetch the abc, but lots
of users ask for GIF or PDF, and in many cases they get
something very different from what was intended. Then I get
the bug reports. I have to tell them that they're seeing
one of the areas of abc that is not yet standardized, and
there isn't much I can do to help them.
One approach is to announce that the formatter behind the
tune finder, jcabc2ps, understands this simple definition
header line. So if you want your abc's ornaments to look
right on other people's screens, there is one approach that
will work (though it's not ideal). If you add the ornament
definitions to your tunes, and others fetch the tunes via
the tune finder's converter, then the ornaments will stand
a good chance of coming out correct.
This could slowly put pressure on other implementers to add
the ability to output tunes with such ornament definitions
in the header lines. This would be trivial to code in any
language, of course. It would be just a fixed routine to
write out some fixed text. Then, if this becomes popular,
we might even see other apps that accept the definitions.
There's also the possibility that the tune finder's code
could attempt to guess the ornament definitions at a site
and generate the definitions itself. But this is an AI
project that might not be done in a morning (or ever).
So should the header field be 'm' or 'U' or something else?
I have a weak preference for 'm', because I think of this
as a (parameterless) macro. I don't know what 'U' might
stand for. But the letter doesn't really need to stand for
anything, any more than 'Q' or 'Z' do.
Also, how many abc apps already have something like this
sort of ornament definition facility? Although I'm not yet
considering a full macro extension, it might be nice to at
least not do something that is in conflict with a gimmick
that is already in use elsewhere.
To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
