Re: [tablatures] Re: \set predefinedDiagramTable in a TabStaff

[Carl Sorensen <c_sorensen@xxxxxxx>]

On 11/18/10 4:24 PM, "Patrick Schmidt" <p.l.schmidt@xxxxxx> wrote:

> 
> 
> Am 18.11.2010 um 16:38 schrieb Carl Sorensen:
> 
>> 
>> 
>> 
>> On 11/18/10 3:19 AM, "Patrick Schmidt" <p.l.schmidt@xxxxxx> wrote:
>> 
>>> 
>>> 
>>> Am 18.11.2010 um 05:36 schrieb Carl Sorensen:
>>> 
>>>>> I also wanted to show how I use your new
>>>>> function of different predefined diagram tables. BTW I have defined
>>>>> loads of "custom" chord shapes (not attached). Is there any chance
>>>>> that these predefined-diagram-table-files could become part of the
>>>>> LilyPond-package one day. They might reduce the need to define
>>>>> chord
>>>>> diagrams including fingering and barre indications for other users.
>>>> 
>>>> I've looked at your definitions, and they seem to me to be very
>>>> interesting.
>>>> I think they're also more complicated than I'd like them to be.
>>>> 
>>>> I've attached a revised version of your files that shows how I
>>>> think it
>>>> ought to work.  Of course it doesn't work now, because the notes in
>>>> the
>>>> regular staff don't match either the fretboard or the tablature.
>>> You seem to have forgotten to attach your revised version?!
>> 
>> Oh, I hate it when I do that.  It must be my advancing age (or
>> maybe I'm
>> just an absent-minded professor).
> ;-)
>> 
>>>> 
>>>> I think it should be possible to modify the note-head-engraver so
>>>> that it
>>>> does the same thing the tablature engraver does, that is, if
>>>> there's a
>>>> predefined fretboard for the chord in chordmode, it replaces the
>>>> notes that
>>>> came from the chord parser with the notes from the fretboard.  It
>>>> might be
>>>> difficult to do well, because of enharmonic spellings.  But it
>>>> would be
>>>> really nice in my opinion if we could just call it a C chord, and
>>>> let the
>>>> predefined fretboard in the desired table spit out the notes that
>>>> we need.
>>>> 
>>>> What do you think?
>>> Hm, on the one hand this sounds very user-friendly. On the other hand
>>> I am having difficulties to imagine how  LilyPond could possibly
>>> choose the desired fretboard diagram from various alternatives. Most
>>> chords (with the same pitches) can be fretted in at least two
>>> (sometimes even three) different ways on the guitar, e.g.:
>>> 
>>> Chords = \chordmode {
>>>    \set minimumFret = #2
>>>    e,1:1.5.8.10
>>>    \set minimumFret = #7
>>>    e,1:1.5.8.10
>>>    \set minimumFret = #12
>>>    e,1:1.5.8.10
>>> }
>>> 
>>> When I use fretboard diagrams I normally prefer to choose a specific
>>> chord shape (in this case either a d-, a- or e-shape). My definitions
>>> are based on the CAGED-system as all chords on the guitar can be
>>> derived from these five chord shapes. I admit that in some cases it's
>>> not always easy to "see" the underlying chord shape. So in the worst
>>> case my definitions might result in someone having to try out up to
>>> five chord shape commands to get the desired fret diagram. In the
>>> best case the definitions could be useful for users being familiar
>>> with the CAGED-system. [Of course this would mean brainless diligence
>>> for me. I have already defined c-shape-diagrams for powerchords, the
>>> four basic triads (in closed and open position, as well as inversions
>>> with three to six notes) and diagrams for the ten seventh chords. The
>>> c-shape-file is not finished, yet. I could add lots of alterations
>>> and I would still have to define all these chords for the other chord
>>> shapes as well.]
>> 
>> Right, but if you choose an a-shape C chord, it will be a five-note
>> chord
>> with a certain set of pitches.
> Well, I totally disagree here. It can also be a four-note (e.g. c:
> 1.5.8.10) or a three-note chord (e.g. c:3.5.8^1). But when you enter
> \chordmode {c} you get a three-voiced chord in both Staff- and
> TabStaff-contexts.

Currently you get a three-voiced chord in Staff contexts, but if you are
using predefined diagrams you get a voicing that corresponds to the
predefined diagram table in the TabStaff.

>  In my opinion it is neither logical nor desirable
> to get a five-note chord (or sometimes a four- or six-note chord) in
> a FretBoard-context with the same command. So if the default for
> \chordmode {c} is a three-note chord I believe LilyPond should
> produce a three-note chord in *all* contexts.

I can see an argument for that.

> The reason why I 
> started to work on my CAGED-files was to be able to choose an exact
> fret board via \chordmode or via the simultaneous pitches method of
> entering chords. A while ago we talked about that and you argued that
> you had never seen a piano?-edition using exactly the same pitches
> for both the chords in a Staff and the fretboard diagrams. I'd agree
> here but on the other hand I have rarely seen a piano edition with
> convincing guitar chords. Sometimes I get the impression that the
> fretboards are chosen by accident in certain editions.

I'm sure that's true.


> In many cases 
> five to six-voiced chords sound too heavy and would interfere with
> the piano voice. Very often it is more convincing to play three- to
> four-voiced chords even for seventh/extended and/or altered chords. I
> use exact chord diagrams when I want to show how a melody can be
> harmonized or to make it easier to read/remember an arpeggio study.

I have done that on occasion -- I don't use predefined fretboards when I do
that.

> So I don't see my CAGED-files as a substitution for the existing
> fretboard-files but as an alternative. If someone is not too fussy
> about chord diagrams than the existing predefined fret diagrams are a
> good start. The others could use the CAGED-files or would have to
> define their chord diagrams themselves.

I think we agree here.  I was thinking the same thing.

>> It's a pain to have to list all the pitches
>> (and remember them) when you're working on a particular chord.
> I totally agree even though we are probably not of the same
> opinion ;-). I think the current \chordmode method is unnecessarily
> complicated. But on the other hand it allows to define even complex
> chords. Unfortunately even simple four- or five-note chords look very
> difficult. But then again it's possible to use different definitions
> for the same chord (e.g c:1.3.5.8.10 or c:8.10^7).
>> Plus, the
>> set of pitches will mess up the chord namer.
> Well, the chord namer is broken, anyway. In my opinion for example
> all basic triads in which three or more notes are sounded together
> should result in the same chord name no matter which of the three
> notes are doubled. But currently even a simple chord such as "c:8^7"
> produces a weird chord name (C add8).

Well, this is what the Brandt-Roemer chord naming scheme requests.  Doubled
pitches are supposed to be included in the chord name.

>> 
>> If we could make it go:
>> 
>> \aShape
>> c1
>> \cShape
>> c1
>> \gShape
>> c1
>> 
>> and have the ChordNames context produce "C", the FretBoards context
>> produce
>> the desired fret diagram, the Staff produce the pitches that
>> correspond to
>> the fret diagram, and the TabStaff produce the tablature that
>> corresponds to
>> the fret diagram, I think that would be the ideal.
> I agree!

Well, I'll see if I can make that work.  If we can get the Staff to go along
with the FretBoards and the TabStaff, then we won't disagree about much of
anything of substance.  If that funcionality works, you can use your
chordmode definitions that list each pitch and create custom tables.  I can
create custom tables that are listed by basic chords, and we can both be
happy.

>> 
>> Right now, as you can see in my revised example (which *is*
>> attached this
>> time), we have that behavior for the ChordNames, the FretBoards,
>> and the
>> TabStaff.
>> 
>> I *think* that this behavior could be added to the Staff, but there
>> may be
>> some difficulties with getting the right enharmonic spelling.  And
>> before I
>> jump into doing it, I'd like to see if it makes sense to you.
> Hm, I see what you mean. I thought about it before I started to work
> on the CAGED-files but I just didn't like the idea that \chordmode{c}
> would represent four-note-chords as well as five- and six-note chords
> apart from the fact that it currently represents a three-note chord
> which is quite handy for the right hand of a piano voice. If
> \chordmode{c} represents for example a six-note chord it's not
> possible anymore to define a three-note voicing of the same chord
> (well, at least not in the same octave of pitches).

By using a different table, it *is* possible.  That's what I thought you
were doing with different tables.

\aShape \chordmode{c}

represents a different voicing than

\cShape \chordmode{c}


>  Personally I 
> prefer to list all the pitches I would like to have in a chord (what
> you mean is what you get). This ensures that I always get the correct
> voicing. If it is a pain to define chords in chordmode than this
> should be made easier. I see some room for improvements...
>

I'm fine if you prefer to list all the pitches you would like to have in a
chord.  LilyPond is certainly flexible enough to handle it, as you have
demonstrated.

I wouldn't use them that way, but I'm not an advanced musician.  Just a
campfire guitar hacker.  I choose my chord voicing based on what's easiest
to play in the context of the music, not based on what sounds best.  That's
why I ask for simple.

I think that we can add as many fretboard tables to LilyPond as we would
like to.  So by all means, use your preferred way.

> 
> Maybe some sort of compromise???

I don't even think a compromise is necessary.  I think LilyPond could
accommodate both our preferences.


Thanks

Carl