I've been exploring the architecture of the FretDiagrams context. One thing I think is really important to do is to have the FretDiagrams music expression be the same as the ChordNames music expression. That way the user doesn't have to try to synchronize two different sets of chord definitions.
I did an example using the existing string/finger notation from
lilypond:
mymusic = <d'\4 a'\3-1 d''\2-2 fis''\1-3>
\score{
<<
\chords{\mymusic}
\new FretDiagrams {\mymusic}
\chordmode{\mymusic}
>>
}
The typical guitar D chord covers notes from two octaves, as I indicated
in the chord above (mymusic). But this leads the ChordNames context to
produce the chord name D/add8/add10, which is correct, but not usual for
a guitarist (see attachment).
A second issue I'm having with this method of defining fret diagrams is
that they won't transpose well. If I transpose from D to C, I don't
want to keep the same notes on the same strings but dropped two frets.
I want to move to a C chord structure, which is entirely different.
Based on these results, I've decided to propose yet another FretDiagrams
architecture. In this architecture, I'd have a big alist of
fret-diagram-terse strings. The index part of the alist would be the
pitches that come out from /chordmode. So in essence, I'd do \chordmode
{d}, get the (d fis a) pitches already produced by lilypond, and then
lookup in the alist the fret-diagram-terse string corresponding to that
set of pitches.
As part of this, there would need to be a procedure (set-fret-diagram!
lilypond-chord-entry terse-fret-string) to allow users to define their
own terse-fret-strings for whatever chord they wanted. So if they chose
to redefine the fret diagram for d, they could issue (set-fret-diagram!
d my-new-terse-string).
Another feature that would be very nice to implement would be the
ability to enter
\new FretDiagrams {d:"x;x;o;2;3;2;"}
which would use the string following the chord name to produce the fret
diagram.
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?
Thanks for your help and your patience.
Carl
<<attachment: d-chord-with-strings-fingers>>
_______________________________________________ lilypond-devel mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/lilypond-devel
