Bryan Creer wrote:
>> Oh, did Bryan mean that statement seriously? Hmm... I thought
>>there was a hint of sarcasm there, just as I've taken this entire
>>thread as an indirect demonstration that the saying "abc is for the music
>>alone*" (_whatever_ that may mean), is a worthy rule of thumb for overall
>>design, but an unreliable guide for individual decisions.
>
>Sorry John, but I was perfectly serious. There was no intention of sarcasm
>but perhaps my dealings with this list have left me a little bitter and
>twisted.
>
Hmm... Actually, I thought it was humor, not misanthropy
(mislistthropy?); "sarcasm" may not have been the right word. In fact,
after I posted, I thought I should have said "reductio ad absurdem"
instead, since I figured you'd shown that that line of reasoning led to
the outlawing of instrument-specific notation in abc. Which I
thought--think--is absurd, and that everybody would agree with me on that.
Clearly I'm wrong on at least one of the two.
From my point of view, instrument-specific notation is necessary.
I use abc for, among other things, transcribing uilleann pipe music.
Like most instruments, the pipes have some techniques unique to
themselves: cranning, popping, ghost D, hard and soft low D, off-the-knee
fingering, regulators... At the minute, I can handle this more-or-less to
my satisfaction (tho I'd like more) with abc2mtex, but not with any other
application.
One basis of misunderstanding here may be an assumption that
instrument-specific notation must be carved in stone in the language--as
u and v for upbow and downbow are now, for instance. It doesn't. (It
can't, really, for abc doesn't have the resources. In my own case, I have
to invent notation which would be quite useless to almost anyone else, and
I certainly don't want to saddle others with it.) However, I think that a
lot of the instrument specific--and other--notation could be introduced
from the users end, if there just is sufficient flexibility in abc. (And
there is, at least potentially.) For instance, suppose we had a
generalization of the much-overused guitar-chord mechanism which would:
(a) put arbitrary text over the staff
(b) ditto under the staff
(c) ditto over a note
(d) ditto under a note
(e) ditto in front and behind a note
and which could
(f) deal with fonts, and
(g) have enough flexibility in positioning to
keep things from overwriting each other, and even (heresy!) make them
look nice.
Then one would be able to handle much, even the majority, of these things.
(The suggested notations "^foo" and "_foo" are a start, but I'm more
ambitious--I think font-handling and flexible positioning are also
needed.)
[Non-uilleann example: I've just been transcribing some tunes from
Ryan's/Coles for John Chambers' project. These include fingering for the
fiddle on some notes. I had to use guitar chords to stick this in, and, to
be charitable, it looks awful. The numbers are too far from the notes,
and often conflict with other markings on the same notes. I wouldn't put
up with this for my own music, but this is John's project, so I can't use
abc2mtex.]
It almost goes without saying that this implies that
definitions--the details of the way this mechanism would be used--would be
given outside the abc, either in the header or in an auxiliary file,
say--since in the abc, this would probably be called with one of the
letters H--Z, or even h--y.
Of course, the wish-list doesn't end here, but it
would be a very good start.
Cheers,
John Walsh
To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
