Re: Transposable Fret Diagrams for Guitar

[passport]

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.

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.

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.

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.

Rick


----- Original Message ----- 
From: "Carl D. Sorensen" <address@hidden>
To: "Lilypond User" <address@hidden>
Cc: <address@hidden>; <address@hidden>
Sent: Friday, December 29, 2006 12:58 PM
Subject: Transposable Fret Diagrams for Guitar


I'm proposing a method for getting transposable fret diagrams for the
guitar.

The method I propose is different from the current FretBoard
functionality.  The FretBoard context takes a set of notes and
determines a fingering that will allow the playing of that set of notes.
This is a very useful too, and I appreciate Rick for sponsoring it.

I've asked Han-Wen about the cost for sponsoring a modification to
FretBoards that will allow it also to take the name of a chord and
determine a chord diagram.  There would be a default set of chord
diagrams (one for each chord name) that I would enter based on a
standard chord reference for guitar.  Then, the input to FretBoards
would be a set of chord names (which Lilypond will change into a set of
chords).  If the sequence were transposed, the chords would be
transposed.  The diagrams would be looked up in a hash table and
included in the score.  Any chords not found in the hash table would be
treated just as in the current FretBoards context -- a fingering would
be determined by FretBoards.

Of course, if users wished, they'd be able to define their own chord
library (I assume the library will be defined in a .ly file), or replace
entries in the existing chord library.  And the current functions of
FretBoard will still be available.

The cost for sponsoring this feature is eur 150.  I'm hoping to get a
couple of people to help me sponsor this feature.  Any takers?

Thanks,

Carl Sorensen