RE: guitar chord diagrams

[Han-Wen Nienhuys]

address@hidden writes:
> So, I've been working on making a Chord_diagram_engraver.  A few
> questions:
> 
> 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?

> 2.  How do I get both Chord_name_engraver and Chord_diagram_engraver to
> process the same music expression.  Is it just by having both engravers
> in the context for the music expression?

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

> 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.

> 4.  Where would I look to find examples of routines that implement grobs
> by putting TeX into the output file?

The Scheme expressions go through output-tex.scm and output-ps.
Check lookup.cc for samples of the C++ interface.

-- 

 Han-Wen Nienhuys   |   address@hidden   |   http://www.xs4all.nl/~hanwen