Dear ABCers,
Since I am not much of a musician or active developer of any music
software yet, I'd like to make a few comments and observations as an end
user of (some of) the ABC tools. Far be it from me to educate anyone in
this group. I'd only like to share with you my way of seeing things.
In my mind macros are commands formed of linguistic statements using
keywords understood by the program for which they have been written and
not some external pre- or post-processor. Therefore, one ought to speak
about macros if and only if there is also an engine interpreting them.
Just because there is a way to assign various meanings to an arbitrary
symbol, one ought not refer to them as macros. (The #include, #define,
etc. statements in C or C++ are rather compiler directives, than
macros). According to this, there is not much difference between the
disputed U: and m:. They both serve only one purpose: assign a meaning
to a key-word, -code, -string, you name it.
A real macro language would support at least some VARIABLES and
OPERATORS. I could see the use of an operator that would control the
printing and the play of various ornaments, for example. Suppose I
wanted to say (and I will mix Phil's "macro definition" and the "U:"
style assignment just to emphasise what I mean),
U: vibrate<note> =
{_<note>}<note>{^<note><note>_<note><note>^<note>}{symbol}
and then just apply it as
!vibrate!a
which would mean
{_a}a{^aa_aa^a}
and it would show up explicitly "spelled out" in the output.
Furthermore, suppose one is familiar with the kind of ornament, and the
person would like to increase the legibility of the output. Then, by the
introduction of a unary operator as a modifier, say,
!~vibrate!a
only a sign would be printed above the ornamented note, like in
"symbol"a
where "symbol" could be selected or defined by the user.
In this manner, the U: or m: fields would serve a much broader purpose,
while complying with the current definitions, not to mention the fact
that, as many of you said it before, the primary concern should be the
readability of the source itself without the need for translation or
post processing of any kind, if you will.
Naturally, the playback tools could also make a good use of the modifier
operators, not just the macro commands.
Some were mentioning a 95 versus 5% needing other than ASCII characters.
Well, just in case anyone cares, besides the ascii vowels themselves,
the Hungarian alphabet contanins one accented version of a, e, i and
three of u and o. The same applies for the uppercase letters too. I
myself love TeX and LaTeX, but I never type a Hungarian text for them
directly. I wrote a tiny translator script that replaces every accented
character with its corresponding escape sequence. Although I consider
this procedure well automatized, it's a pretty poor solution. It's
really hard to decypher a text written with multi character escape
sequences if they occur frequently. So, once again, just in case anyone
cares about those 5%, please try to turn to solutions serving the
general public of (possibly) all nations, that is UTF. As a side note,
I'd like to announce that starting October I will make my Hungarian abc
*original* folk tune files available to the open public. There are only
a few for now, but I am working on adding more every day.
Portability is relevant and it constitutes the best brigde among users.
Having that in mind and adding an on-the-fly graphical interpretation
feature to the text editing procedure, has anyone considered Java and
its extensive graphical extension, Swing? By turning to such a platform,
besides solving the portability and licensing issues, the door for
network applications would open much wider as well. Java would be slower
most likely, but still fast enough for the purpose, wouldn't it?
My best regards to the whole group,
Tibor
To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
