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

[pls]

On 23.05.2015, at 06:22, Carl Sorensen <address@hidden> wrote:

> 
>> + 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.)
> 
> m7.5- is not commonly used in  US consumer-grade pop charts, but I'd be
> happy to add them.  

Hm, m7.5- probably isn't used very often in pop music.  But in jazz music it 
definitely is a very common chord. 

> Suspended chords are also not commonly used in US
> consumer-grade pop charts.

Hm, being a guitar teacher quite a few more or less popular songs containing 
suspended chords pop into my mind:

+ All Of Me (John Legend)
+ Fireflies (Owl City)
+ Wonderwall (Oasis)
+ Stairway To Heaven (Led Zeppelin)
+ Brothers In Arms (Dire Straits)
+ You Take My Breath Away (Eva Cassidy)
+ Dreamer (Ozzy Osbourne)
+ How You Remind Me (Nickelback)
+ Underneath Your Clothes (Shakira)
+ To Be With You (Mr. Big)
+ Come As You Are (Nirvana)
+ Behind Blue Eyes (The Who/Limp Biskit)
+ Bubbly (Colbie Caillat)
+ Dear Mr. President (Pink)
+ Sweet Home Alabama (Lynyrd Skynyrd)
+ Viva la Vida (Coldplay)
+ Wake Me Up When September Ends (Green Day)
+ When You Say Nothing At All (Garth Brooks/Ronan Keating/Allison Krauss)
+ You’re Beautiful (James Blunt)
+ Your Body Is A Wonderland (John Mayer)
+ Born To Run (Bruce Springsteen)

I’d suspect that this list is not exhaustive and that these examples are not 
rare exceptions. ;)

> 
>> + 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)
> 
> String numbers should be consistent as you transpose diagrams within a
> given shape, I think.  Have you found any case where they don't work?

No, actually I haven’t.  I thought string numbers would interfere with 
predefined diagrams.  They don’t.  LilyPond simply ignores them.  

In the case of transposing automatically-generated diagrams LilyPond might 
throw some warnings ‘Ignoring string request and recalculating’  but the 
resulting diagram is fine, e.g.:

stringedA = <a,\5 e\4 a\3 cis'\2 e'\1>1
\new FretBoards {
  \stringedA
  \transpose a e { \stringedA }
}

> 
> Fingers should be OK as well, as long as you finger for the barre chord.

Yes, they basically are.  I alluded to the problem we already discussed: 
LilyPond can’t guess which fingers should be used in a chord, e.g.:

fingeredA = <a, e-3 a-3 cis'-3 e'>1
\new FretBoards {
  \fingeredA
  \transpose a e { \fingeredA } %wrong fingering
}

>> 
>> 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 <http://c-shape.ly>
>> + a-shape.ly <http://a-shape.ly>
>> + g-shape.ly <http://g-shape.ly>
>> + e-shape.ly <http://e-shape.ly>
>> + d-shape.ly <http://d-shape.ly>
>> + alt-shape.ly <http://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Š)
> 
> I think it makes great sense to complete your library.  And we should
> certainly add the library to LilyPond, so people don't have to go
> somewhere else to get it.

Wow, that’s nice to hear and an incentive to continue!

> 
>> Great!  The barre chords look really good!  Thank you so much!
>> 
>> Sone minor issues:
>> + the fret labels seem to have vanished.
> 
> Hmm -- I don't think anything I did should have changed the fret labels.
> Can you share an example.

Hm, I can’t reproduce it.  I probably got confused.  Sorry for the noise!

>> 
>> 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. ;) )
> 
> I don't think we want to have all of the diagrams with fingering.  We want
> to show the capability of making the diagrams both with and without
> fingering.

I did not mean to add fingering to *all* the diagrams in the manuals but only 
to those automatically-generated diagrams that look plain wrong without a barre 
indicator.  If I’m not mistaken it’s actually only one chord that needs to be 
changed: the first f major chord in the first example under the heading 
Automatic fret diagrams 
(http://lilypond.org/doc/v2.19/Documentation/notation/common-notation-for-fretted-strings#automatic-fret-diagrams)

It’s in a prominent place and to be honest: this example initially discouraged 
me to use automatic fret diagrams.

> 
>> 
>> 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.
> 
> Please do post a proper bug report.  I will investigate.

Will do.

>> 
>> 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.
> 
> I do not know the answer why, but I believe it is intentional.  There are
> comments in the code that indicate the original authors knew of the one
> octave shift.  I believe it was defined that way so that \chordmode c
> would give <c' e' g'>, since lilypond staffs have treble clefs by default.
> I believe it should probably be fixed.  The code is probably not hard to
> fix, but I think the convert-ly rule is nearly impossible (it's certainly
> beyond *my* python regexp-fu).
> Post a bug report, and let's get an issue created.

Will do.

Thanks,

patrick