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 _______________________________________________ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
