Re: FretDiagrams Architecture

[Carl Sorensen]

On Fri, 2004-11-19 at 07:38, Han-Wen Nienhuys wrote:

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

Yes, this is what I had in mind.

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

I'll start with an alist, and try to learn more about hash-tables and
trees in guile.  I guess that we could build a tree based on the
sort-order (I think you use the term "lexicographical order" somewhere
in the code) of the pitches.  I've made trees in scheme before as part
of a class assignment, so I could probably resurrect that code, even if
it is 21 years old.

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

This is a good idea.  It's got a lot more flesh on it than the skeleton
I had worked out.  I'll have to study the code some more in order to
have all this make sense to me.

I'd still like to have some syntax that allows me to enter a fret
diagram for a chord name, rather than for a list of pitches, because
that's the way I think.  I've already completed the code that gets the
pitches given a chord name.

So do you envision that the style sheet is created in engraver-init.ly 
(notation-context-init.ly)?  That is, is the fretDefinitions assignment
string part of notation-context-init.ly, along with the
chordToFretDiagramTable assignment?

> 
> * 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'll learn more about 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.

Yes, and we could also have a warning if a chord is requested for which
no table entry exists.

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

OK.

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

OK, I'll figure out how to do this.

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

Yes.  It seems to me that the way it works is you transpose the
requested chord down by the number of half steps corresponding to the
capo location, get the fret diagram, and add the same number of half
steps to every fingering in the diagram.  Should be quite easy to
implement.

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

I see a lot of chord calculators on the Web, including some in Java, and
some that are GPL'ed.  I believe that I can eventually write some code
to come up with plausible fret diagrams for chords, given the notes in
the chord, the string tunings, and some limits on the number of frets
that can be reached and the number of fingers that can be used.  Of
course, such chords may be unplayable, and authors would always be free
to indicate the diagram that they use.  Going after this solution would
be fun, but it will come after the dummy mode.

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

I'll start with ones that I'm interested in, which will probably be a
quite small subset of the 60 odd chords per tonality.  My Gig Bag Book
of Chords has 1008 chord diagrams.  It also lists 23 different chords
per tonality.  I suspect I'll start with 7 chords per tonality (major,
minor, maj7, 7, m7, dim, sus4), for an initial list of 84 chords.

As mentioned above, I have future plans for automatically generating
diagrams for non-included chords and alternate tunings.

Thanks for the careful review of my proposal.  You've given me enough
guidance now that I believe I can move forward on implementation.  If I
have more questions, I'll be sure to let you know.

Onward to World Domination!

Carl