Re: Transposable guitar fret diagrams

[Carl D. Sorensen]

On 7/31/08 9:47 AM, "Han-Wen Nienhuys" <address@hidden> wrote:

> A couple of comments:
>
>  - there is
>
>    defchord =...
>
> everywhere. Why?

I have a couple of goals with this.

First, I want to be able to define a set of fret diagrams in an init file,
rather than interspersed with the music.  That way, I can have a specific
set of fret diagrams I like to use repeatedly, and include them in all of my
guitar music files.  So I don't want to add diagrams using \override in a
context.  This mechanism allows me to do it outside of the main music
expression.

Second, the key for the hash (for efficiency) is a cons of the stringTunings
with the pitches extracted from the chord.  I need to extract the pitches
from the chord so the duration doesn't affect the hash.  In order to extract
the pitches, I need to get the music expression from the parser.  Assigning
a value to an identifier (variable) was the method I came up with to get the
parser to handle this outside of the music expression.

If you can suggest a better way to make this happen, I'd be delighted to
implement it.  I'm still a bit fuzzy on the interactions of the parser, the
translators, and the engravers, even after reading Erik's thesis.  It makes
sense to me in the abstract, but when it comes down to the specifics it's
still magic to me.

>
> - You're storing the fretboards in a global variable, so changes to it
> will leak from one file into the other.  Declare the table in the init
> .ly files, like
>
> #(define default-frets ... )
>
> and have the music function add to that.


> It should probably be a
> list, so it is easy to modify.
>
> Then in the engraver init, you can assign
>
>   defaultFretDiagrams = #default-frets
>
> Then, you can get the default frets using (ly:context-property context
>  'defaultFretDiagram) when you need it.

OK, I have now moved the #(define default-frets ...) to the init file, and
changed the \override from useDefaultDiagrams to defaultDiagramTable.  It's
a context property of type hash-table.  I can easily change it to a list if
it's the right thing to do in the future.

This change is now working.


> Once the fret_diagram_engraver comes alive, it can compute the hash
> table from the list to have efficient lookups.

How do I make something like this happen?  Would I write the code to compute
the hash table in lily/fret-board-engraver.cc?  If so, where?  In
Fretboard_engraver::Fretboard_engraver?

> I suspect that using a list will make it easier to create a sane
> mechanism for users to extend the default fret diagrams.  With a bit
> of luck, you could even do
>
>   \override defaultFretDiagrams #(make-fret-key ... ) = #...fret-diagram..

So let me see if I understand.  The mechanism you are proposing here is that
there would be an alist of (hash-key . diagram) pairs that would be created
in the init file, and possibly added to by the user using the \override
infrastructure of LilyPond.  Since it would be an alist, all of the
\override and \revert techniques would work.  Then, once the fretboard
engraver fired up, a hash-table would be generated, from which all the
fretboards would be pulled.  Is this right?

One thing that concerns me a bit about this technique is that the \override
can be applied anywhere in the music, but I don't see that the \override
would get added to the hash-table, since the hash table is only created at
the fretboard_engraver startup.  If I've misunderstood, please let me know.
>
> Another option is to have 2 properties: the hash table (as a context
> property) for the system defaults (efficiency!) and a list for user
> overrides.

So under this option, we'd have the system hash-table set up, and do
something like

(let ((user-diagram (chain-assoc-get hash-key user-override-list))
      (hash-handle (hash-get-handle sytem-fret-table hash-key)))
  (set! (ly:grob-property grob 'dot-placement-list)
        (if user-diagram
            userdiagram
            (if hash-handle
                (cdr hash-handle)
                (calculate-string-fret-diagram args-needed-to-calculate)))))

I guess this would work, but I don't really see the benefit for it.

As a user, rather than having to load in specific fret diagrams for a
specific piece of music, I'd rather just build a big table, and use the
different octaves to store my custom chord set.  I don't ever need a \revert
in my anticipated usage.


>
> Perhaps you can also drop the boolean var, and just use the list/table
> context property.

I've done this already.
>
> Han-Wen Nienhuys - address@hidden - http://www.xs4all.nl/~hanwen

In summary, I'm not sure why having a scheme procedure

(add-alist-to-hash diagram-alist diagram-hash)

and then building a scheme list to pass to that procedure is "saner" from a
user point of view than having a lily function

add-chord-to-hash specific-chord-information

that is repeatedly invoked, similar to the way I've currently done it.  I'd
welcome an explanation of your thoughts; I've always found your thinking to
be excellent.  If I could get a picture of what you think is a sane override
method and why it's sane, then I'm sure I can make things happen properly.

Thanks,

Carl