RE: Transposable Fret Diagrams for Guitar

[Carl D. Sorensen]

Rick H wrote: 

> 
> Carl this sounds good, but I work from notes myself, to 
> derive names with my own chord names exception list.  The 
> main pitfalls I see are that the permutations of chord forms 
> for guitar against chord names would be in the hundreds of 
> thousands of table entries just for the basic forms.  As long 
> as the names can have exceptions to any anlgorhythm 
> auto-determining a name, and/or the user can outright 
> override the name on a single chord with text specified so 
> that the algorithm knows the specified root letter and bass 
> note letter (for slash chord names).  Then it will know what 
> portion of the override name needs to transpose.
>

I understand that there are thousands of permutations.  And I would
certainly not change the current FretBoards functionality that works
directly from notes.  However, there's a bunch of music currently out
there that just uses chord names, and Lilypond supports those chord
names.  And almost all of the currently published music uses the same
fret diagrams for the common chords if it includes fret diagrams.  This
is the market my proposed feature is after, not the expert guitar player
market.

 
> Given the notes <c e g a> I can name it C6 or Am7 or EmSus4/C 
> or Am7/C etc... and it will know to always transpose both the 
> root name and the "slash" (bass note) name if present, all 
> the other aspects of the name like m, M, sus, 7, etc. should 
> be completely in control of the user as most chord forms on 
> guitar have at minimum 3 or 4 names, and when you start 
> getting into 5 and 6 note chords with b5, b9, etc, those 
> chord forms frequently have 10 to 20 names, all of which are 
> valid depending on the place in the song and what note you 
> are designating as the root of the chord.
> 

I don't propose to take any of this control away from the user.  The
current FretBoards functionality will be unchanged when it is fed a
chord (in the form of notes) that is not in the standard lookup table.
And it would be possible to completely disable the standard lookup table
if that were desired.  Something like \override
use-chord-lookup-table=##f would work.


> The current lilypond "names from notes" and "names to notes" 
> functionality is very rudimentary in that the note stack i/o 
> must be only in first inversion where the bottom note is 
> always assumed to be the root, on guitar this is rarely the 
> case.  This functionality as is will not work for guitar. 
> With guitar chord stacks all 20 to 30 names of a given note 
> stack would have to be renderable and offer a user hard 
> override.  I wrote out all the permutations a while ago and 
> was up to 5000 or so chord names/diagrams and I was not even 
> finished with all the possible 4 fret stretch chords.  IOW an 
> algorhythmic approach would be a huge project, and probably 
> not interpret names properly in the end.

I agree with your statement if you are trying to cover all 5000+ chord
names/diagrams.  But the current functionality can be used to cover most
of these by including every desired note.  The feature I plan to use
will need standard diagrams for 12 different roots, and major, minor,
maj7, m7, and sus variants, give or take a variant or two.  Anything
fancier could be added by the user if desired (and we could keep them in
the LSR, to make available to others), or just handled with explicit
note inclusion.

The rudimentary functionality of the "names from notes" and "names to
notes" is precisely what allows it to work as a reasonable pointer to a
hash table.  Anytime I say \chordmode {c} Lilypond creates <c e g>.
While this is not an appropriate guitar chord, it's great pointer to a
fret diagram that has a good C guitar chord, just like it's a great
pointer to the chord name "C".  It doesn't support the variety you'd
like to play, which is why you wanted the current FretBoards
functionality.

> 
> So I would stick with maybe just a user-maintained table of 
> chord shapes related to names where the LP enhancement would 
> be just a lookup of whatever names the user provides in the 
> list, this way LP would not have to get into the business of 
> trying to interpret names and relate them to diagrams. 
> There are at least 20 different ways to play a CM7 chord for 
> example, given just CM7 how would lily know what shape 
> diagram to choose?  Maybe CM7_1, CM7_2, CM7_3, CM7_4, CM7_5, 
> etc?  Then the user would just remember what diagram each 
> enumerated name renders?  Then you also have duplication, a 
> CM7 <c e g b> can also be called Em13 and chord diagrams for 
> CM7 are also valid digrams for Em13.  My head is spinning and 
> this is just one very simple example.
> 

A user-maintained table of chord shapes wouldn't be transposable.  It's
using the Lilypond chord naming structure that makes the transposing
work, IMO.  This functionality wouldn't work for you, because you're an
excellent guitar player.  It would work for my purposes -- creating
introductory guitar books of campfire songs to help novices have fun
with the guitar.

Thanks for your feedback,

Carl