Fwd: Transposable guitar fret diagrams

[Han-Wen Nienhuys]

(oops, now with list)


---------- Forwarded message ----------
From: Han-Wen Nienhuys <address@hidden>
Date: Tue, Aug 5, 2008 at 2:33 AM
Subject: Re: Transposable guitar fret diagrams
To: "Carl D. Sorensen" <address@hidden>


On Tue, Aug 5, 2008 at 1:15 AM, Carl D. Sorensen <address@hidden> wrote:

>> -
>> +"Extract named music @code{music-name} from each element
>>
>> what's the return type ? (I assume list of musics?)  Reading the other
>> helper, actually it seems you only want to extract one instance?  I
>> think it's more general to extract all instances, and let the caller
>> get the 1st one, or panic if there is more than 1.  In any case, be
>> specific about this.

> I've struggled with this some because there are some musics with event, and
> some with events.  So built into the music is some sense that sometimes you
> return a music (when there is just an event) and sometimes you return a list
> of musics (when there are events).  I can see the confusion this causes in
> all sorts of routines (e.g. map-music, voicify-music).  But since it appears
> to be a design decision, I decided to try to follow the design decision to a
> certain degree.
>
> With my *very limited* understanding of LilyPond internals, it would seem to
> me that each music should have an elements property, which would return a
> list of music, and the list might be of length one.  But some music has an
> element property, which returns a music; while other music has an elements
> property, which returns a list of music, and I needed to somehow figure a
> way to deal with both.  What I came up with was not particularly elegant,
> but it seemed to work.

It is to mirror the structure of music expressions. Some use sequences
(parallel & sequential), most have just one (\transpose, \times,
\context etc.), while very few have both: \repeat.

> I'll look through my code and give it some more thought.  If you're OK with
> always returning a list of music, I can do that.  The main reason I didn't
> was for consistency with element and elements.

Since in your case, the return value does not have to map to the
original expression nicely, I think it is ok to flatten everything to
a big list.

>> - predefined-fretboards.ly has a large body of scheme code.  Is it
>> possible to put this in .scm somewhere?
>
> I'm sure it's possible to put it in .scm somewhere.  Earlier you were
> concerned about using a global variable for the predefined-fretboards hash
> table.  Based on your comments at that time, I've been working on the
> assumption that predefined-fretboards would only be loaded if the user asked
> for it, and it seemed best to me to put the scheme code in the .ly file so
> it would only show up when included.

> Could you give me some idea of your thought process in choosing whether to
> put scheme code in a .scm file or in a .ly file?

You could put the bulk of the code in a public function in a .scm ,
and call that function from the .ly file (passing the hash table as
argument).

The reason I'm not fond of long scheme codes in .ly is that they mess
up syntax highlighting, indentation and whatnot.  Also, if we ever
implement some kind of testing framework, having .scm mixed with .ly
will complicate things. The reason I criticized your earlier version
is that we can absolutely not leak overrides between .ly to .ly files
(it would totally ruin our regression test).

>> -
>> +
>> +  predefinedDiagramTable = ##f
>>
>> I'd think the predef'd tables are preferable to the autogenerated ones?
>
> For me, the predef'd tables are preferable to the autogenerated ones.
> Howver, the person who sponsored the autogenerated tables was quite adamant
> that the autogenerated tables were better because it gave the user complete
> control over which of the many forms of the chord were used.

I think feature should default to do the right thing for the majority
of our users.

 predefinedDiagramTable = ##f

is simple enouggh for your sponsor, I should think.

> 1) AFAICS it would require a global variable, since I'd need to set the
> table variable in the context definition.  And you previously asked me not
> to use a global variable.

see above - the default  can be global to a .ly file but it must
follow standard mechanisms for overriding.  See eg.

 ly/chord-modifiers-init.ly

where it says

 chordmodifiers = #default-chord-modifier-list

> 2) Setting the predefs to be the default will break all music for previous
> versions, and I can't readily imagine a convert-ly rule that will fix it
> automatically.  I can see a NOT_SMART statement that says "add
> \predefinedDiagramTable = ##f", but it will require manual tweaking for
> every file.

Well, we don't promise pixel-for-pixel equality between versions.  The
predefs will be preferable to automatic frets for music previously
typeset by older versions too.

> That being said, my personal opinion is that if I were new to LilyPond and
> wanting to use it to set guitar music, I'd prefer the predefs to be the
> default.  I would have no problem with a global variable.  I'd prefer to
> have the predef'd diagram code loaded automatically rather than having to
> put an \include in my input file.
>
> I'll be happy to set this performance whichever way you'd like it.  It's
> quite easy to set it up that way.



--
Han-Wen Nienhuys - address@hidden - http://www.xs4all.nl/~hanwen



-- 
Han-Wen Nienhuys - address@hidden - http://www.xs4all.nl/~hanwen