This is a really great discussion that has been going on about language
issues. I've been following the abc mail group summaries.
I got interested in abc when i was looking for a way to compose printed
music (and proof-listen it with poor quality midi output),
and it has served that purpose.
I was a little surprised at how fragmented the languaged definition is,
and i am totally confused about "abc standard" -- is there really an
abc standards body out there? I've seen a 1.6 standard and a draft
document with a latest number but i'm clueless who promulgates these...
can anyone fill me in?
I find the varying language standards pretty interesting.
I've written the basic part a Backnus Naur Format (bnf) automated
parser: given the language description (a bnf file) and an input file
written in that language, it builds a data structure with the input
file hiercharly parsed according to the bnf, with references to the
exact text to allow further processing to translate into another language
(by which i could include, for abc, e.g. postscript and midi output, as well as
another abc language, etc. ).
In theory this allows language neutrality; so long as you have a
suitable bnf file to describe the input language, you can get the same
output (subject to the limitations of the input and output languages).
(Incidentally, there are lots of bnf variants out there...! ).
The key to making such a translation work is to have very well defined
set of named semantics and flexible output drivers that can deal
alternate semantics.
This of course only works for a culture that has some well established
semantics shared by many people.
Western music has some pretty well established norms, so this shouldn't
be a great obstacle, but one should expect perfection from any translator.
I'm now working on abc specific stuff.
For example, the bnf file for the input language might define tones as:
abc_context_tone_1 ::=
*abc_accidental_1 abc_context_base_tone_1 [abc1_context_octave_1]
Each of the names above names a somewhat language-neutral semantic
concept.
The semantic abc-context-tone-1 defines a tone specification that depends
upon the context in which it appears,
namely the cleff, key, and previous accidentals,
as well as some sequence of accidentals, base tone, and octave specifier.
The bnf parser could automatically break up the text to small enough
chunks that second state input code could parse the chunks in simple ways
that don't require much thought.
To allow for future semantic changes, i've named them all here
as abc-...-1 ;
future unforseen changes might required abc-...-2 definitions,
and all the output drivers would have to be updated to accept this,
which is pretty painful.
To minimize such pain, a lot of thought has to go into the semantic
definitions, and also the output drivers should be written to ignore
sub-semantics that they don't understand, and not be too picky about
order.
For example, suppose we add a semantic that allows a tone to be played
a tad flat; we may still be able to use abc-context-tone-1 but
it can include abc-tadflat-1 which is ignored by output drivers that
don't know about it (perhaps with a warning)... you get something
that at least bears some resemblance to the original, which often
times is good enough.
Semantics is always a slippery slope (witness the difficulties in
translating between various conversational human languages),
but for specialized fields such as western music it isn't so terribly bad.
Implementing such a language translator for the abc world
in full probably requires more time (and knowledge of music theory)
than i could give to it, but i'm enjoying making a small stab.
In order to make it at all reasonable (although i still probably
wouldn't have enough time) i would restrict my effort to translating
from various abc dialects, to the dialects of various abc and other
music composition programs (for example, there is a lot i like about
the mup program, it's verbose input format not being one the things).
Once such a translator was partially working, then it could be improved
iteratively by handling bug reports as follows.
Based on a bug report, first determine if is a simple bug or a problem
of inadequate semantics.
For the latter, introduce new semantic definitions or modify the old,
and update the various drivers accordingly.
Since all the drivers would use the same names for all the semantics,
finding and fixing things may (or may not) be too hard.
However, there is never any pressure to actually support a semantic
other than to pass it on to a program that does actually support it!
The advantage of the above approach is that i don't have to write a
translator into say midi format, i just find an adequate abc to midi
translator and write a translator to it's particular input format.
This can also allow for automatically working around bugs in various
programs, while at other times the bugs (or limitations) of programs
can defy any easy characterization, at least as far as automatic
language translation goes.
Well, i can dream... you might someday find i've written a useful tool
or maybe this is just another step in my education.
Anyway, i'm not opposed to language variety... although it would be
nice if published abc files gave hints as to which abc programs and
versions they work with... i suppose it could be part of the language,
but let's not get into that!
Ted Merrill
[EMAIL PROTECTED]
To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
