Carl, Trevor,
You've discussed the overloading of 'string' in Scheme and what variable
name to use, and looked at Dana's suggestion of using 'course' but did
you consider the other important point Dana made?
dem...@suffolk.lib.ny.us wrote:
<snip>
Hhm, I'm not so sure about this. I had envisaged changing
only the c to r, leaving all letters beyond c to default.
I don't understand this insistance on misreading gamma as r. It was not
written as gamma, the letterform used was always understood as 'c'. It
should be read today as c, and is most logically encoded as c. Yes, naive
musicologists and new players might take a while to get used to the idea,
but no experienced player reads gamma as 'r' to my knowledge. Go this way
and you make a nightmare for possible analytical use of music thus
encoded.
Let the choice of font display a glyph in the proper shape. Provide the
user with a way to display arbitrary glyphs and ligatures for each encoded
'stop'. This will be useful for bass stops (/a /b /c... //a //b //c,
///a) and essential for german tab should we go there.
It would be wrong to presume the encoding of the font. The need for
glyphs beyond what is used in prose makes necessary special fonts whose
encoding has no standard.
afm-like information in external files keyed by name to their relevant
font would be my suggestion for that.
Although if i not j is a general rule
I have generally seen i used in preference to j, but I have seen both in
the same document albeit this was german tab (same semantic). Note that
that edition had large pages and lots of staves, it must have been a
challenge to find enough sorts to set the amount of type on each page,
several sizes and flavors of each sort were also used interchangeably
(both tall and short s for example).
J Wolf Handbuck der Notationskunde (2vv, ca 1926) and Apel _Notation of
Polyphonic Music 900-1600_ are the two standard references. Groves
Dictionary of Music and Musicians (22vv or 26vv edition) 'Tabulature' is a
lengthy article also worth having a copy of.
--
Dana Emery
Cheers,
Ian
_______________________________________________
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
