Bryan Creer writes:
| John Chambers wrote -
| >I've also found the phrase "explicit key signature" more useful than
| >"global accidentals", though I don't suppose that's a real big deal.
|
| These seem to me to be two separate things.  Whem converted to conventional
| notation, an "explicit key signature" is the collection of sharps, naturals and
| flats you find at the start of the staff; "global accidentals" are
| accidentals applied to notes throughout the music.  (Does anybody ever use these?)

The difference is somewhat minimal, though.  The original text had as
example  "K:D  =c",  which  implies a key signature of two sharps but
with a natural written before all the c's.  The natural  reaction  to
this  is  "If  all  the  c's  are  natural,  why put a c sharp in the
signature and then cancel  it  everywhere?"  This  is  indeed  rather
silly.  It's better to just use ^f as the key signature.  OTOH, using
"K:Dmix=c" with ^f=c as the signature can be sensible, because that c
natural  in  the  key  signature  instead  of a sharp is an "advisory
accidental" that emphasizes the fact that the c is not sharp.

| >Careful readers might note that I also  dropped  the  old  standard's
| >requirement that global accidentals be set off by spaces.
|
| Setting off by spaces is the only way to distinguish between these two
| different things in John's proposed notation.

I doubt that this is a useful distinction.  I'd think that  a  better
approach  would  be  to  put  the accidentals in the key signature by
default.  An option to put them before the  notes  could  be  useful,
though  I  expect  that  only  a few advanced abc tools would ever do
that. In the only uses I can think of for such a feature, I'd find it
more useful to be able to turn this on and off with a runtime option.
Doing it by editing the abc would not be nearly as useful.

Also, experience has shown that abc users are not  likely  to  follow
such persnickety rules for use of spaces.  You and me and Jack Campin
maybe, but how many others?  After all, we can't even get them to use
X:1 lines in their tunes.  People who write abc parsers quickly learn
that, unless you want to hand-edit 90% of the tunes  you  get  before
using  them,  you  have to make your parser very accepting of trivial
formatting variants.  Accepting odd white space is a  large  part  of
this job, along with accepting strange double-bar symbols.

| I would like to propose the addition of two new optional parameters to the K:
| command; tonic= and mode=.  Using these, John's K:Amix=g could become -
|
| K:^f^c=g tonic=A mode=mixolydian
|
|        which seems much clearer to me.

If we were designing abc from scratch, I'd agree.  As it is now,  I'd
guess  that few if any users would ever use this, mostly because it's
so much wordier.  So I'd think that such  clear  but  wordy  notation
would  be appropriate for the more complete notations like MusicML or
LilyPond, while ABC's  "K:Amix=g"  is  more  in  keeping  with  ABC's
compact  style.   And  it really is mostly a matter of style.  ABC is
compact and cryptic, but easy to type.  We might as well keep it that
way.


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

Reply via email to