David Kastrup wrote Wednesday, December 02, 2009 11:15 AM
"Trevor Daniels" <t.dani...@treda.co.uk> writes:
I posted my first patch to Rietveld last night, but nothing seems
to
have been cc'd to the list. Not sure what I did wrong. It's at
http://codereview.appspot.com/164063. Here's what it does.
This is the first patch of a series aiming eventually to enable
Baroque lute tablature to be produced.
This first patch enables an option to indicate fret numbers with
letters. The option is turned on by setting the context variable
tablatureFormat to fret-letter-tablature-format. The letters are
taken sequentially from the alphabet by default, but the first n
of
these may be overridden by setting the context variable
fretLetters to
a string of n length. For example, the third fret on a Baroque
lute
is indicated by "r" rather than "c", as "c" can easily be
confused
with "e". (Actually it was originally a Greek gamma, but "r" is
usually used). So, for a Baroque lute, fretLetters would be set
to
#'("a" "b" "r").
How about fretLetters not overriding "the first n of these", but
completely substituting for the alphabet, by having the last
element in
the list be the model for the next ones. And permitting numbers
as
well. Then the default numbering would just be
#'(0)
And your Baroque numbering would be
#'("a" "b" "r" "d")
In that manner, the baroque numbering does not need an exception.
Converting a number to string (if necessary) and calculating
successor
of either number or string might be a bit of a hassle. But I
think that
the resulting interface would be quite generic and convenient.
Thanks for your suggestion, but there are at least three
arguments against it, and as it really offers no significant
improvement or extra facility I am not in favour.
1. There already is another tablatureFormat procedure,
for the 5-string banjo, that cannot be met by your
generic suggestion, so the tablatureFormat mechanism
could not be removed. There are likely to be more
instruments with strange fret numberings.
2. Removing tablatureFormat would be a syntax change,
not to be undertaken lightly as it would break existing
code with no obvious means of upgrading automatically.
3. The code to implement it would be more obscure than
the existing, granted not by much, but I am in general
in favour of the simplest implementation.
Trevor
_______________________________________________
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
