Re: how to add barre indications to automatic fret diagrams?

[pls]

On 22.05.2015, at 01:43, Carl Sorensen <address@hidden> wrote:

I am now speaking solely in LilyPond internals terms.  When \transpose is
applied to a chord, it changes the pitches of the chord, but does not
change the fingerings.  And there is no reasonable system I can imagine
that would allow \transpose to do the right thing on both chords and
single notes, relative to fingerings.  So \transpose is almost guaranteed
*not* to work effectively on automatically-generated fret diagrams.

Understood!

That is *why* there is a predefined fretboard capability defined in
LilyPond.  You are free to define the set of chords you want to work with,
complete with fingerings.  And if you do that, the predefined fretboards
will work *exactly* the way you want them to work when you transpose.

As part of the predefined fretboard code, to make it easy to define
fretboards, we have the concept of a chord shape (e.g. E-shape, A-shape,
D-shape).  And we can define other chords as these shapes shifted by a
certain number of frets.  That is what I meant by shape shifting.  Not
changing shapes, but moving a shape along the fretboard by a given number
of frets.  I apologize for my lack of clarity.

I can’t see any lack of clarity on your side.  The concept of shape shifting is very familiar to me (both instrument- and notation-wise).

It’s actually me who wasn’t clear here.  I’m sorry for lumping together several problems.

In the current usage of predefined-guitar-fretboards, we actually don't
use E-shape, because it is missing the barre.  So we use F-shape (which
has the barre) and then slide it along the fretboard wherever we want to
go, to get F#, G, G#, etc.  Same with A-shape.  We use bes-shape (because
it has the barre) and then slide it along the fretboard.

Understood.

The predefined fretboards are really quite robust to LilyPond
transposition, meaning you can apply \transpose to a music _expression_
going to a FretBoards context, and it will give you what you want.  The
only problem is if you don't like the predefined fretboards, you'll have
to make your own predefined fret diagram table, but that is a one-time
thing.

Yes, I have some issues with the predefined fretboards shipped with LilyPond, e.g.:

+ the resulting diagrams are not always predictable:

  + the number of notes in the diagrams varies from 4 to 6 even when you enter a three-note chord modifier like \chordmode { e:m e,:m e:1.3-.5 e,:1.3-.5 }  or <e g b> <e' g' b'> .  I know it’s meant to make chord entries as easy as possible but it’s not exactly WYGIWYM and it leads to a different interpretation of these examples in different contexts.  In a FretBoards context and (therefore) a TabStaff context all six examples are interpreted as the same six-note chord <e, b, e g b e’> even though neither the chord structure nor the absolute octaves are in line with this interpretation whereas in a Staff context the chord structures, the number of notes, and the octaves are displayed correctly/as defined.  This means that in this case it would be necessary to define two different chord variables, one for the Staff context and one for the FretBoards/TabStaff context which seems a bit cumbersome to me.

  + the chord shapes vary depending on the octaves (I know, they were chosen to be simple in form and easy to play but more often than not the changing shapes really surprise me.)

  + quite a lot of chords are displayed in their first inversion instead of their root position as suggested by their modifiers (Again, I know / can see the reasons: avoiding barre chords, preference for the upper four strings, playability/“strummability” ;) but the output is nevertheless unexpected.) 

  + some chord shapes/structures are wrong, e.g. (I haven’t checked all of them yet and I haven’t found time to post a bug report.):

    + dis:m (<fis ais dis’ eis’> instead of <fis ais dis’ fis') and es:m (<es bes es’ f'> instead of <es bes es’ ges’). 

    + f+ (<dis aisis dis’ fisis’> instead of <cisis ais cisis’ fis’ or even better (root position) <fis ais cisis’ fis’>)

+ some frequently used chords are missing, such as m7.5- and suspended chords. (I know of course from my own experience that predefined fret diagram tables unfortunately are never complete.)

+ inversions are missing (Slash chords)

+ as discussed: the lack of being able to shift the same chord shape up and down the fretboard.

LilyPond’s automatically-generated fret diagrams solve almost all of the above issues. The only drawbacks I can see are:

+ the missing barre indications (which you fixed in the meantime! Thank you very much!)

+ some rare “unacceptable” diagrams which can be easily fixed by assigning note(s) to a string. 

+ problems arising from trying to transpose/shift diagrams potentially containing fingerings and or string numbers (as discussed here)

+ the need to customize the fret diagrams over and over again (for each new score)

These are basically the reasons why I started to make my own predefined fret diagram tables a few years ago (see https://github.com/Philomelos/lilypond-predefined-fretboards).  I haven’t found the time to document it yet and there are only just a few test files currently available.  The definitions are spread over 6 files:

+ c-shape.ly

+ a-shape.ly

+ g-shape.ly

+ e-shape.ly

+ d-shape.ly

+ alt-shape.ly (contains alternative chord shapes that cannot be included in the five basic shape files for technical reasons or due to their ambiguity)

You can include these files as usual and then use 6 new commands (\cShape, \aShape, \gShape, \eShape, \dShape, and \altShape) to choose a diagram derived from one of the five basic chord shapes, so e.g.

+ \chordmode { \aShape c,:1.5.8.10 } or \notemode { <c g c’ e’> }  returns a c major barre chord across the 3rd fret

+ \chordmode { \eShape c,:1.5.8.10 } or \notemode { <c g c’ e’> }  returns a c major chord at the 8th fret (on the strings 6, 5, 4, and 3)

+ \chordmode { \dShape c:1.5.8.10 } or \notemode { <c’ g’ c’’ e’’> } returns a c major chord at the 10th fret (on the strings 4, 3, 2, and 1)

You need to enter all the pitches you want to include in your diagram.  If there is a definition for the chord you should get the expected diagram including fingerings and a barre indicator (if necessary).  You don’t need to manually add fingerings or string numbers.  So there are no problems with shape shifting and transpositions.  If you don’t like a detail: don’t use this definition or override it! 

You can use other definition files in combination. You can switch the definition files on and off by using \predefinedFretboardsOn and \predefinedFretboardsOff (as usual).  If the tables don’t contain a definition for a certain chord structure (or if the chord structure or the octave is impossible in standard tuning) LilyPond jumps in and tries to automatically generate a diagram.

The tables already contain a couple of hundred transposable definitions (even some inversions) but of course the library is far from being complete.  The reason why I started this thread here was to check whether it makes sense to continue the work on this library or maybe just use LilyPond’s automatically generated diagrams… (But now I think my predefined diagrams are actually quite helpful — well, at least to me…)

Hm, I¹d either use <e,-0 b,-3 e-4 gis-2 b-0 e¹-0>

Yes, that is what I meant to type -- the other was a typo.

or (even more likely) <e,-0 b,-2 e-3 gis-1 b-0 e¹-0>,

This is my most often played E-chord.  But if this is used with automatic
(not predefined) fretboards, it will not be transposable.

the latter making it even more complicated! When transposing this open
chord to a barred chord all fingers would have to be raised by 1.

Yes, and this rule would apply in the case of E, but would not apply in
the case of A if you are playing the A as a barre on fret 2.

You are right! And it would not apply in the case of <a,-0 e-1 a-2 cis’-3 e’>.  So it’s a bad idea!

 And I can
imagine no straightforward means of configuring the transposition if you
don't like the default output.  That's why we have predefined fret
diagrams.

They both sound fine to me!  Are they mutually exclusive? I¹d suggest
another condition:

if we make a barre on the lowest fret and set the fingering of all the
dots on the lowest fret to 1, the other fingers should be automatically
raised by one.

It does make sense, but I can find some counterexamples, so I don't think
that rule should be implemented.

Agreed.

I've made some changes to the automatic fret diagram generator code that
will add barres, as long as you have fingerings listed in the diagram.
I've attached it to this email.

If you would like to try it out, copy translation-functions.scm to the
scm/ subdirectory of your lilypond installation.  Make a copy of the
original, of course.

Great!  The barre chords look really good!  Thank you so much!  

Sone minor issues: 

+ the fret labels seem to have vanished. 

+ some chords lead to unwanted barre indicators, e.g.:

  + <d-1 a d’ f’> or

  + <e, b,-3 e-3 gis-3 b e’> (wrong fingers!)

I can offer to add fingerings to all the (automatically generated) barre chords in the documentation as soon as your patch gets accepted (if you want me to). (So far I have found only 2 automatically-generated diagrams without fingering. ;) )

Thanks again

patrick

P.S.: On a related note: I think there is something wrong with the default vertical alignment of the fret labels in fret diagrams in general.  It looks to me as if it is placed one fret above the lowest fret it is referring to (LP 2.19.20).  I will try to post a proper bug report as soon as I can.  

P.P.S.: On a different note: some day I would like to get to know the reason why in \chordmode the absolute pitches are one octave higher than in note mode.  For chord names correct absolute pitches don’t matter. But they do when also using \chordmode in a Staff context.  Mixing both modes is rather error prone.