Re: Transposable guitar fret diagrams

[Carl D. Sorensen]

On 8/4/08 9:00 PM, "Han-Wen Nienhuys" <address@hidden> wrote:

> Various random remarks:
>
> - (eq? '() x) => (null? x)

OK -- two occurences found and changed.

> - there are list? typechecks.  list? is rather expensive, since it has
> to check for cycles.  You probably want pair? ?
I hadn't paid attention to the expense of the checks.  I was just going on
the assumption that things were lists, so check to see if they're lists.

When I look at the code, I can see that I'm really checking to see if they
have more than one element, so pair? will work.  I'll make the changes.

> -
> +"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 will fix this; I haven't yet.

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.

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.

>
> - the 2 functions called in extract-named-music do not seem very
> generally applicable. Consider nesting the functions in
> extract-named-music.

I will consider this.
>
> - 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.

I'd be happy to either create a new .scm file or put much of the scheme code
in fret-diagrams.scm if you'd prefer.

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?


>
> - same file: looks as if there is a stray %} at the end.

Oops -- Good catch.  It's gone now.

>
> -
> +
> +  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 suspect that, although all the notes transpose properly, and the
autogenerator will still work, there will be a fair amount of hand tweaking
necessary to properly transpose music with autogenerated fretboards.

In my files, I'll always use predefs, with the possible exception of some
classical music where I have specific notes and I want to get some
fingerings out.  But there are two reasons why I chose not to make the
predefs the default:
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.
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.

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.

Carl