FretDiagrams Architecture

[Han-Wen Nienhuys]

address@hidden writes:
> I've been exploring the architecture of the FretDiagrams context.
>[snip]
> I have some questions as I begin to implement this architecture.
> 
> 1) Does the basic architecture make sense?
> 
> 2) If this architecture looks OK, what symbol might be available to
> introduce a fret-diagram string?
> 
> 3) I assume that some symbol chosen in response to question 2 would need
> to be added in parser.yy.  Is this assumption correct?  
> 
> 4) Further, I would assume that a new type of music event would need to
> be created, say fret-diagram-definition-event.  Is this right?  If so,
> where is the best place to learn about music events?


Your idea is sound.  I'll just spout off by rephrasing your idea,
trying to clear up any questions along the way.

* We tack frets onto \chordmode{}, that is, we do 

 chordScheme = \chordmode { d }

 << \new FretDiagrams \chordScheme
    \new ChordNames \chordScheme
 >>  

The \chordmode produce <d fis a>. In Fret_diagram engraver (contained
in FretDiagrams context), we translate from this <d fis a> to the
appropriate fret diagram. For the rest, FretDiagrams will be very
similar to ChordNames

* How do we generate the correct fret diagram from a chord?  I think
the alist idea is basically OK, and we should use it in a first
implementation.

The only problem is that we have 60 odd chords, times 12 tonalities =
at least 720 different fingerings. That's a bit big to put into an
alist. It's probably better to invent something using a hash-table or
a tree. I believe GUILE doesn't come with code for trees
out-of-the-box, but we should check a little better.

* The alist should be stored in a context property, i.e.

   \set chordToFretDiagramTable = .. 

* Although it is possible to make a #(set-fret-diagram-string ) , I
think we can use the mechanism now used for chord exceptions, ie.

 fretDefinitions = {
    <d fis a>-\markup { \fretdiagram "xyz"  }
    <d g a>-\markup { \fretdiagram "pqz"  }
 }
 ...


and then in engraver-init.ly (note to self: rename this to
notation-context-init.ly),  we do

  chordToFretDiagramTable = #(translate-fret-exceptions fretDefinitions)

the set-fret-exceptions translates the exceptions variable into a
property setting; this is suitable for providing a "style sheet".

* Overrides of this style sheet can be done by constructing an
  \applycontext music expression, which takes the existing value of
  chordToFretDiagramTable and adds new exceptions to this.

* I suppose that this is still too difficult for "normal" users, and
  that we should also have an option

  a. to override fret diagrams for once, eg. 

    \chordmode { d:add9 \frets "abc9312" }

  b. to override a fret diagram from now on

    \chordmode {
      \set rememberFretOverride = ##t
      d:add9 \frets "abc9312" d:add9
    }

   would print the 2nd chord with the same fret diagram

Of course, we need to make sure that these once-exceptions print a
warning when a transpose is attempted.


* The \frets keyword would have to be added to parser.yy and
  lily-lexer.cc

* The \frets command would be translated to a FretDefinition music
object (see define-music-types.scm), which includes a
fret-diagram-definition music interface symbol. The
Fret_diagram_engraver will try to catch music objects that have
fret-diagram-definition.

FretDefinition should have a special transpose function, so we can
print a warning when anyone tries to transpose it.

* There is one thing I'm thinking about though. Should we do something
sensible when the guitar players puts a clamp on the neck (they're
called "Capo", aren't they) ?  Can we get away with

   \new ChordNames \scheme
   \new FretDiagrams \transpose d c \scheme

How about different instruments, retuned strings etc? My guess is that
we can't do much except for the clamp, but maybe I'm overlooking
something.

* Remaining problem: who will enter those 720 different diagrams?

-- 

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