On 22.05.2015, at 01:43, Carl Sorensen <c_soren...@byu.edu> 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._______________________________________________
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
