Toni writes:
| ...
| > How an ABC tune is translated to staff notation, or Tabulatur, or MIDI, or whatever
| > however, will always be subject to difficulties, as there are
| > so many variants of staff notation.
|
| Yes! That's it!
| You can try to get ABC convenient, readable, close to some staff
| notation or what ever you wan't. But first of all you must keep (or get)
| it to contain unique (well formed or well defined if you want)
| information.

Well, now; I'm not sure I'd agree with that. Granted, I'd like to see
such  a  computerized  notation, and I suspect that both the lilypond
and MusicML people are making good progress toward such a goal. But I
don't  think  that we should push ABC in this direction.  ABC's niche
that led to its success is that  it's  a  relatively  simple,  basic,
plain-text notation that is compact and mailable.  It doesn't require
a sophisticated UI; it can be typed (and read) by mere humans.   None
of  this  would  be true of any notation that is well formed and well
defined.

Furthermore, such precision isn't necessary.  The proof  of  this  is
staff  notation.  It has survived for centuries, and has been adapted
to many different musical styles, despite  its  serious  deficiencies
and  ambiguities.  You could argue that its success is partly because
of these "problems".

Thus, people have spent a lot of time agonizing over the  limitations
of  the  7-note  octave  and  the 12-note chromatic scale.  But staff
notation is routinely used in many musical styles that have all sorts
of  other  scales.   Thus,  in the Middle East, it's common to simply
state the scale at the top. None of the scales actually use more than
7 notes in an octave, except in the same sense as the classical minor
scale that has an ascending and a descending form.  So 7 notes and  3
accidentals  are  sufficient  for the knowledgeable practitioners who
know how to adjust the intonation for the stated scale. Precise marks
to describe the intonation are not necessary, and just clutter up the
page and make it less readable.

Similarly, the persistence of accidentals has different rules in some
different  kinds  of  music.  This is a problem for people looking at
music in an unfamiliar  style.   But  it's  not  a  problem  for  the
"insiders" who know the style.  They know their rules, and don't need
to mess up the page with unnecessary junk.

The result is often incompatible rules in different styles.  One case
that I've seen a lot: I play traditional Scandinavian music, in which
it's common to divide the beat more or less at random into  2,  3,  4
and  5  notes.   Very  often,  the  usual tuplet notation is omitted,
because it just clutters up the music.  To do  it  accurately,  you'd
need  a tuplet thingie on half the beats, and this is just messy.  So
it's often omitted.

OTOH, in Balkan music (which I also play), this doesn't work at  all.
The music inherently uses beats of different lengths.  It's common to
have a 3-note beat followed by a 2-note beat, and the  first  is  50%
longer  than  the second.  If that first 3-note beat should be in the
same time as the  second  2-note  beat,  you  need  to  indicate  the
triplet.  So you see tuplet notation in this style.

Thus, when a Swedish musician sees something like | CDE FG AB |,  the
normal  interpretation  would  be  that the CDE is a triplet.  When a
Bulgarian musician sees this, the normal interpretation is that  this
is  a  7-count  measure whose first beat is 50% longer than the other
two.  Both of these involve sloppy, imprecise notation, and both  are
done  to  keep the notation simple.  Neither is at all confusing to a
musician who knows the style.

Anyhow, I think ABC should be kept simple.  And any problem  that  it
shares  with  staff  notation  is a pseudo-problem that can be easily
ignored by most of its users.  High precision should be left  to  the
more  sophisticated  notations  that  others are developing.  (And we
should be encouraging them to include ABC as an input/output  format,
despite its loss of information.)

To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html

Reply via email to