Re: [frogs] [PATCH] chord names language

[Carl Sorensen <c_sorensen@xxxxxxx>]

On 12/9/10 2:10 AM, "Valentin Villenave" <v.villenave@xxxxxxxxx> wrote:

> On Thu, Dec 9, 2010 at 6:06 AM, Carl Sorensen <c_sorensen@xxxxxxx> wrote:
>> Actually, we have it hardcoded in multiple lists.
>> 
>> We have note-name->german-markup, note-name->semi-german-markup, and
>> note-name->italian-markup as well.
> 
> Indeed, and whilst simpler it's still rather ugly.
> 
>> This code won't work for German and Norwegian note names, where b is what
>> english calls b flat, and h is what english calls b.  There needs to be
>> something more general, and I'm not exactly sure what it is.
> 
> Oh, indeed. Nice catch!
> 
>> Perhaps the note name files should define both a pitch and a base name for
>> each of the pitches, and then we look up the base name from the pitch in the
>> given language, instead of trying to fake it with some other function.
>> 
>> I'm thinking that perhaps the lists in scm/define-note-names.scm
> 
> Does that mean I can push my define-note-names.scm patch? ;-)
> 
>> would look
>> like
>> 
>> (nederlands . ((entry-names . (
>>                              (ceses . ,(ly:make-pitch -1 0 DOUBLE-FLAT))
>>                              ...
>>                              ))
>>               (display-names . (
>>                                ((0 DOUBLE-FLAT) . "C")
>>                                ((0 SEMI-FLAT) . "C")
>>                              ...
>>                                ))))
>> 
>> and then we'd need to modify the functions that get the pitch-name-alist to
>> get the entry-names key from the language alist.  The markup we'd get by
>> getting  display-names alist, and we'd do something like
>> 
>> (define (pitch->markup pitch)
>>  (let ((note-name (ly:pitch-notename pitch))
>>        (alteration (ly:pitch-alteration pitch)))
>>   (assoc-get (list note-name alteration) display-names-alist "")))
> 
> That could work. But wouldn't that be a tad bit overkill?
> 

Perhaps.  But it keeps all of the language definitions together.

In your code, you want to avoid hard-coded alists (which I actually prefer
as they are more readable).  I can see a reason for that.  But in order to
do so, you would keep needing to introduce various flags, e.g.
has-bflat-letter? and use-accent-on-re? (which we haven't discussed yet).
This eventually becomes a set of arbitrary tests, just to allow us to
convert from symbols to strings.

IMO, it's cleaner to define the strings we want to display somewhere.  And
the most logical place to define them is in the language file.  Perhaps not
with the exact architecture I've proposed.  Perhaps as separate alist
entries including things like notename-markup, and separate-bflat, instead
of display-name for all of the pitches.

Thanks,

Carl


---
----
Join the Frogs!