RE: Transposable Fret Diagrams for Guitar

[Carl D. Sorensen]

Rick Hansen wrote:
> By a table lookup were you thinking of something like this?
[He then goes on to describe a table lookup mechanism based on parsing
the string name of the chord, which produces a five-dimensional table]

This would probably work, but it's not my proposal.  The proposal you
made has an index entry in addition to the chord name.  Plus, it would
require a string parse of the chord name into the component parts.  And
it would not work with chords entered as notes, rather than as chord
names , e.g. <c e g>.  To allow it to work with the same input as the
Chords context, the Chords context would need to be modified to ignore
the index to the fretboard string.

My proposal is to use the Lilypond generated notes as the index to the
hash table.  I want to be able to use the exact same input to generate
the chord name output (in the Chords context) and to generate the fret
diagrams (in the FretBoard context).  I don't want to create a parallel
chord-name parser to generate fret diagram hashes (although it certainly
could be done that way). 

There are three necessary additions for my porposal:

1. Create a hash table indexed by Lilypond chords (not the input
notation, <c e g>, but the chord produced by parsing that notation) 

2. Provide a .ly file compatible mechanism for adding and removing
entries to the hash table, e.g. set-fret-diagram-hash-table
<lilypond-chord> <fret-diagram-string>, where <fret-diagram-string> is
nil to remove an entry

3. Modify the FretBoards context so that when it sees a lilypond chord
(again, after parsing the input notation), it first checks the hash
table to see if an entry for the chord exists.  If it does, that entry
is output.  If it doesn't, it uses the current procsess of automatically
calculating the fret diagram.

It would probably also be desirable to have a property use-diagram-table
that could be set to ##f to prevent the use of the table and force
automatic calculation of the fret diagram.

In this mode, to use a non-standard fret diagram, you could add the
non-standard diagram (which would not be preserved by transposing).
Another possible mechanism to have non-standard diagrams is to have
different diagrams associated with different octaves (but IIRC
\chordmode in Lilypond ignores ocatve differences).

I can see that your proposed architecture is more versatile than my
proposed architecture in that it allows simultaneous storing of multiple
entries for a given chord.  But I think it is less compatible with the
current Lilypond parser and architecture.  And if Lilypond allows
multiple octaves in \chordmode, then my proposed architecture also
allows simultaneous storing of multiple entries for a given chord.

Carl