RE: guitar chord diagrams

[Carl D. Sorensen]

>> 1.  One of Chord_name_engraver's jobs is to find out the name of the 
>> chord, which is stored as chord_name_, then typeset by 
>> Chord_name_engraver::stop_translation_timestep().  I'd like to have 
>> the chord name available to help me find a chord diagram; either one 
>> set up by default or one previously entered in the music.  But I
don't 
>> like having Chord_diagram_engraver depend on Chord_name_engraver.  I 
>> also don't like repeating the chord name search code in both 
>> Chord_name_engraver and Chord_diagram_engraver.  This is why I 
>> originally thought that adding a diagram feature to the 
>> Chord_name_engraver would make sense.  Based on comments in the code,

>> it appears that the lilypond authors would prefer to have the 
>> engravers separate, even if the cost is repeated code in multiple 
>> engravers.  Is that correct?
>
> The naming is a rather hairy affair, and can be customized by the
user. Why do you need it for printing a
> diagram?

I was envisioning that I'd define a diagram that matched a chord name,
then the music expression could have the chord (either by lilypond chord
name structure or as a set of chords made by notes), rather than the
diagram notation, when it was time to produce the diagrams.

So we might have

cDiagram = { syntax for diagram, c }
fDiagram = { syntax for diagram, f }
gDiagram = { syntax for diagram, g }

myChords = \notes \relative c' {
        \chords { c f g} 
         <c e g>}
}

<<
  \context ChordNames \myChords
  \context ChordDiagrams \myChords
>>

And lilypond would be able to generate the diagrams for all of the
chords based on the name, rather than having the syntax included each
time the chord appears.  This also ties in with comment 3 below.

>> 3.  How might I be able to store default chord diagrams for common 
>> cords, so that when a chord is entered, the diagram is already known 
>> about by the engraver?
> 
> Why? If it is for efficiency, then forget about it. We can worry about
that later.

I can see that it's reasonable (as a first cut) to have the input file
required to contain diagram information.
However, it seems to me that the diagram should be outside of the music
expression passed to the ChordDiagrams context.  If the diagram
information is going to be in the music expression, then we need to make
all other contexts ignore the diagram information, which seemed to me to
be a bigger job than forcing the ChordDiagram context to know the chord
name in order to find the diagram.

I'm happy to move in another direction if it makes more sense.  I'm very
much a newbie in regards to lilypond internals, and I appreciate the
feedback you've given me so far.

Carl Sorensen