Re: Add option to indicate frets by letters in tablature (issue164063)

[Carl Sorensen]

On 12/6/09 9:50 AM, "Trevor Daniels" <address@hidden> wrote:

> Hi Carl
> 
> Thanks for taking a look at this.
> 
> You wrote Sunday, December 06, 2009 3:23 PM>
>> 
>> http://codereview.appspot.com/164063/diff/2001/3008
>> File scm/translation-functions.scm (right):
>> 
>> http://codereview.appspot.com/164063/diff/2001/3008#newcode393
>> scm/translation-functions.scm:393: (define-public
>> (fret-letter-tablature-format str context event)
>> The change from string to str is contrary to the desired goal in
>> LilyPond programming.
>> 
>> The goal is to have all variable names be english words, rather
>> than
>> abbreviations of english words.
>> 
>> There is lots of legacy code where that is not true, but we should
>> not
>> be writing new code like this.
> 
> I changed it because "string" is a keyword in Scheme.
> It is even used as such in the same few lines of code.
> Although "string" can be used as a variable name I don't
> think it should be - it seems bad practice to overload
> keywords in this way.

I don't know of string as a keyword in Scheme.  It's not listed in the Guile
reference manual index.

string?  is a predicate.

substring is a procedure.

There are a bunch of string-*, string->*, and *->string procedures.

But string by itself seems to not be part of the Scheme language.  Have I
missed something? (I easily could have.)

> 
> I fully agree with your point in general, but we need
> to think of a variable name other than "string" for the
> string on an instrument.  I tried, and failed :(, hence
> str.
> 

Dana suggests "course", which I guess speaks well to lute players.  But not
to guitar players.

string seems the best to me.

I know that I used string all through the fret-diagram code.

>> http://codereview.appspot.com/164063/diff/2001/3008#newcode399
>> scm/translation-functions.scm:399: (make-vcenter-markup
>> If length of 'fretLetterExceptions is greater than zero, I think
>> we
>> ought to throw a warning if fret is higher than the length of
>> 'fretLetterExceptions so that the user will have an idea of why
>> things
>> didn't work the way they wanted it to.
> 
> Hhm, I'm not so sure about this.  I had envisaged changing
> only the c to r, leaving all letters beyond c to default.
> As this would be the norm I don't think a warning is desirable,
> but I'm willing to be convinced otherwise.  Actually, for most
> ancient instruments only i or j, not both, is used, so maybe the
> length of fretLetterExceptions would be somewhat greater than
> 3 normally, making a warning more appropriate.  Although if i
> not j is a general rule, maybe that should be built in to the
> default, then we'd be back to needing just the change from c to r.
> Maybe a question on -user is needed on this point.

I had envisioned that a full set of fretLetters would be given (in fact, I'm
not really a big fan of the term fretLetterExceptions).  But now that I see
your design intent, I'm not sure what the best thing to do is.

Perhaps we just ought to define lists called fretLabels (instead of
fretLetters).  And we could then define lists of any kind of glyphs to be
used.  There could be specific lists for each different style of tablature,
that would be very easy to switch to.  The fretLabels list wouldn't need to
be characters; they could be markups or stencils, so users could define
whatever is needed or desired.

I'm not refusing to approve for any of this; I'm just kicking some ideas
around.

Thanks,

Carl