\set predefinedDiagramTable in a TabStaff

classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

\set predefinedDiagramTable in a TabStaff

Patrick Schmidt-3
Hi Carl (et al.),

the command \set predefinedDiagramTable used in a TabStaff leads to  
the following error:

.../Applications/LilyPond.app/Contents/Resources/share/lilypond/
current/scm/translation-functions.scm:232:10: In procedure filter in  
expression (filter (lambda # # ...)):
/Applications/LilyPond.app/Contents/Resources/share/lilypond/current/
scm/translation-functions.scm:232:10: Wrong number of arguments to  
#<primitive-procedure filter>
Processing time: 1 seconds

(The compilation does not complete successfully.)

To circumvent this error one has to define different music variables  
for tablature and trad. notation. Sample files are attached. It's not  
a minimal example because 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.

TIA

patrick


fretboards-alternate-tables.zip (4K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: \set predefinedDiagramTable in a TabStaff

Carl Sorensen

On Nov 17, 2010, at 4:51 AM, "Patrick Schmidt" <[hidden email]>  
wrote:

> Hi Carl (et al.),
>
> the command \set predefinedDiagramTable used in a TabStaff leads to
> the following error:
>
> .../Applications/LilyPond.app/Contents/Resources/share/lilypond/
> current/scm/translation-functions.scm:232:10: In procedure filter in
> expression (filter (lambda # # ...)):
> /Applications/LilyPond.app/Contents/Resources/share/lilypond/current/
> scm/translation-functions.scm:232:10: Wrong number of arguments to
> #<primitive-procedure filter>
> Processing time: 1 seconds
>

This is a bug, and will end up with a Critical priority. Please report  
it with a minimal example to the bug list so it gets an issue number.



> (The compilation does not complete successfully.)
>
> To circumvent this error one has to define different music variables
> for tablature and trad. notation. Sample files are attached. It's not
> a minimal example because 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.
>

We'd love to add more predefined diagrams. Are you able to prepare a  
patch and post it for comments on Rietveld?

Thanks,

Carl


Reply | Threaded
Open this post in threaded view
|

Re: \set predefinedDiagramTable in a TabStaff

Carl Sorensen
In reply to this post by Patrick Schmidt-3
On 11/17/10 4:51 AM, "Patrick Schmidt" <[hidden email]> wrote:

> Hi Carl (et al.),
>
> the command \set predefinedDiagramTable used in a TabStaff leads to
> the following error:
>
> .../Applications/LilyPond.app/Contents/Resources/share/lilypond/
> current/scm/translation-functions.scm:232:10: In procedure filter in
> expression (filter (lambda # # ...)):
> /Applications/LilyPond.app/Contents/Resources/share/lilypond/current/
> scm/translation-functions.scm:232:10: Wrong number of arguments to
> #<primitive-procedure filter>
> Processing time: 1 seconds

I've located and fixed this bug in the latest git.  Thanks for the report!

> 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.

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?

Thanks,

Carl



Reply | Threaded
Open this post in threaded view
|

Re: \set predefinedDiagramTable in a TabStaff

Patrick Schmidt-3

Am 18.11.2010 um 05:36 schrieb Carl Sorensen:

> On 11/17/10 4:51 AM, "Patrick Schmidt" <[hidden email]> wrote:
>
>> Hi Carl (et al.),
>>
>> the command \set predefinedDiagramTable used in a TabStaff leads to
>> the following error:
>>
>> .../Applications/LilyPond.app/Contents/Resources/share/lilypond/
>> current/scm/translation-functions.scm:232:10: In procedure filter in
>> expression (filter (lambda # # ...)):
>> /Applications/LilyPond.app/Contents/Resources/share/lilypond/current/
>> scm/translation-functions.scm:232:10: Wrong number of arguments to
>> #<primitive-procedure filter>
>> Processing time: 1 seconds
>
> I've located and fixed this bug in the latest git.  Thanks for the  
> report!
Wow, you are way too fast for me. I wanted to post my bug report this  
morning but you had already fixed it. Thank you very much!

>
>> 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?!

>
> 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.]

Does that make sense?

Thanks,

patrick
>
> Thanks,
>
> Carl
>
>
>



Reply | Threaded
Open this post in threaded view
|

Re: \set predefinedDiagramTable in a TabStaff

Carl Sorensen



On 11/18/10 3:19 AM, "Patrick Schmidt" <[hidden email]> 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.  It's a pain to have to list all the pitches
(and remember them) when you're working on a particular chord.  Plus, the
set of pitches will mess up the chord namer.

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.

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.

Thanks,

Carl


fretboards-alternate-tables-cds.zip (124K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: \set predefinedDiagramTable in a TabStaff

Patrick Schmidt-3

Am 18.11.2010 um 16:38 schrieb Carl Sorensen:

>
>
>
> On 11/18/10 3:19 AM, "Patrick Schmidt" <[hidden email]> 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. 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. 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. 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.  
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.
> 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).

>
> 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!

>
> 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). 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...

Shrug

Maybe some sort of compromise???

Thanks

patrick
>
> Thanks,
>
> Carl
>
> <fretboards-alternate-tables-cds.zip>



Reply | Threaded
Open this post in threaded view
|

Re: \set predefinedDiagramTable in a TabStaff

Carl Sorensen
On 11/18/10 4:24 PM, "Patrick Schmidt" <[hidden email]> wrote:

>
>
> Am 18.11.2010 um 16:38 schrieb Carl Sorensen:
>
>>
>>
>>
>> On 11/18/10 3:19 AM, "Patrick Schmidt" <[hidden email]> 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



Reply | Threaded
Open this post in threaded view
|

Re: \set predefinedDiagramTable in a TabStaff

Patrick Schmidt-3

Am 19.11.2010 um 01:19 schrieb Carl Sorensen:
Carl,

I hope I'm not getting on your nerves. As you said: we agree on the important bits. I just would like to make sure to understand some (probably) less important details...
[snip]

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.
I didn't understand the last sentence.

\score {
    <<
      \new ChordNames {
      \chordmode{c1}
      }
      \new FretBoards {
        \predefinedFretboardsOff
        \chordmode{c1}
      }
      \new Staff <<
        \clef "treble_8"
        \chordmode{c1}
      >>
      \new TabStaff  <<
        \chordmode{c1}
      >>
    >>
}

This results in three-note chords in all contexts. Everything is fine/consistent/logical.

\score {
    <<
      \new ChordNames {
        \chordmode{c1}
      }
      \new FretBoards {
        \set predefinedDiagramTable = #xyz
        \chordmode{c1}
      }
      \new Staff <<
        \clef "treble_8"
        \chordmode{c1}
      >>
      \new TabStaff  <<
        \chordmode{c1}
      >>
    >>
}

This results in three-note voicings in Staff and TabStaff and possibly a different voicing in the fretboard diagram depending on the definition in the predefined diagram table. I can't see any correspondence to what's going on in the TabStaff. Hold on, all of this would make sense if it were possible to use \set predefinedDiagramTable in a TabStaff to change tablature according to the definitions in the predefined diagram table. That would be brilliant and it would cure my brain hiccup! Blame me for not having tested your latest bug fix! ;-)

[snip]
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.
Ok, I didn't know that. I don't have this book. I'm pretty sure that I have never ever seen a symbol like C add8 or C add10 in any real book or song book. Not even Sammy Nestico uses it even though he sticks to the chord naming scheme of Brandt-Roemer.


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.
That would be brilliant!;-)

[snip]
 If it is a pain to define chords in chordmode than this
should be made easier. I see some room for improvements...

e.g. be able to choose the number of notes a voicing should contain in combination with the possibility to indicate the top note of a chord. This way the same chord symbols could be used for chords containing doubled notes and it would further reduce the need to list each pitch that should be part of a chord as there are certain rules concerning e.g. four-voiced chords (e.g. a ninth replaces the root; a thirteenth replaces the fifth…).

I could imagine something like that:

<pseudo code>
\set voicing = #3 %three-note chord (default)
c                            %meaning: <c e g>
c;5                         % ""
c;10                       %meaning: <c g e'>
c;6                         %meaning: <c e a>
\set voicing = #4 %four-note chord
c                            %meaning: <c e g c'>
c;8                         % ""
c;10                       %meaning: <c g c' e'>
c;12                       %meaning: <c c' e' g'>
c:7;8                      %meaning: <c g bes c'>
c:7;10                    %meaning: <c g bes e'>
c:9;12/e                 %meaning: <e bes d' g'>
</pseudo code>

(it's just an idea…) 

[snip]

So if you think that my files might be useful for someone else I'll continue adding some diagrams but it might take a while until the files are ready to be presented on rietveld.

Thanks

patrick


Thanks

Carl




Reply | Threaded
Open this post in threaded view
|

Re: \set predefinedDiagramTable in a TabStaff

Carl Sorensen



On 11/19/10 6:48 AM, "Patrick Schmidt" <[hidden email]> wrote:

>
> Am 19.11.2010 um 01:19 schrieb Carl Sorensen:
> Carl,
>
> I hope I'm not getting on your nerves. As you said: we agree on the important
> bits. I just would like to make sure to understand some (probably) less
> important details...

It never gets on my nerves to have people asking questions and contributing
to LilyPond.  I appreciate your thoughtful input.

> [snip]
>
>>>> 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.
> I didn't understand the last sentence.

I hope you did by the time you got to the end of the email.  Using
predefined fretboards in a TabStaff will get you the tablature that
corresponds to the fretboard.

>
> \score {
>     <<
>       \new ChordNames {
>        \chordmode{c1}
>       }
>       \new FretBoards {
>         \predefinedFretboardsOff
>         \chordmode{c1}
>       }
>       \new Staff <<
>         \clef "treble_8"
>         \chordmode{c1}
>>>
>       \new TabStaff  <<
>         \chordmode{c1}
>>>
>>>
> }
>
> This results in three-note chords in all contexts. Everything is
> fine/consistent/logical.
>
> \score {
>     <<
>       \new ChordNames {
>        \chordmode{c1}
>       }
>       \new FretBoards {
>         \set predefinedDiagramTable = #xyz
>         \chordmode{c1}
>       }
>       \new Staff <<
>         \clef "treble_8"
>         \chordmode{c1}
>>>
>       \new TabStaff  <<
>         \chordmode{c1}
>>>
>>>
> }
>
> This results in three-note voicings in Staff and TabStaff and possibly a
> different voicing in the fretboard diagram depending on the definition in the
> predefined diagram table. I can't see any correspondence to what's going on in
> the TabStaff. Hold on, all of this would make sense if it were possible to use
> \set predefinedDiagramTable in a TabStaff to change tablature according to the
> definitions in the predefined diagram table. That would be brilliant and it
> would cure my brain hiccup! Blame me for not having tested your latest bug
> fix! ;-)

So you see how it works now, right?

[snip]

>>>> 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.
> Ok, I didn't know that. I don't have this book. I'm pretty sure that I have
> never ever seen a symbol like C add8 or C add10 in any real book or song book.
> Not even Sammy Nestico uses it even though he sticks to the chord naming
> scheme of Brandt-Roemer.

Oh, that was my mistake.  It's the Banter style that uses the add8 notation.

I've found a couple of occurrences of pitch doubling in Chapter 10 (Compound
Chords) of Brandt and Roemer; they're just labeled with the primary 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.
> That would be brilliant!;-)

I'm not sure yet how to do it in specific, but maybe I can give it a try
over the Thanksgiving holiday or the Christmas holiday.

>
> [snip]
>>  
>>>  If it is a pain to define chords in chordmode than this
>>> should be made easier. I see some room for improvements...
>>>
> e.g. be able to choose the number of notes a voicing should contain in
> combination with the possibility to indicate the top note of a chord. This way
> the same chord symbols could be used for chords containing doubled notes and
> it would further reduce the need to list each pitch that should be part of a
> chord as there are certain rules concerning e.g. four-voiced chords (e.g. a
> ninth replaces the root; a thirteenth replaces the fifthS).
>
> I could imagine something like that:
>
> <pseudo code>
> \set voicing = #3 %three-note chord (default)
> c                            %meaning: <c e g>
> c;5                         % ""
> c;10                       %meaning: <c g e'>
> c;6                         %meaning: <c e a>
> \set voicing = #4 %four-note chord
> c                            %meaning: <c e g c'>
> c;8                         % ""
> c;10                       %meaning: <c g c' e'>
> c;12                       %meaning: <c c' e' g'>
> c:7;8                      %meaning: <c g bes c'>
> c:7;10                    %meaning: <c g bes e'>
> c:9;12/e                 %meaning: <e bes d' g'>
> S
> </pseudo code>
>
> (it's just an ideaS)
>

I can see this as an idea.  I'm not planning on going into this kind of
modification right now, at least.  But I'd be willing to have somebody else
do this if they want to.

This should probably be deferred to the GLISS discussion (Grand LilyPond
Input Syntax Survey) after 2.14 is out.


> [snip]
>
> So if you think that my files might be useful for someone else I'll continue
> adding some diagrams but it might take a while until the files are ready to be
> presented on rietveld.

Well, if they're useful for you, they'll be useful for somebody like you.
Go ahead and work on them as you get the chance.

Thanks,

Carl