Re: [tablatures] Power chords

[ Thread Index | Date Index | More lilynet.net/tablatures Archives ]




On 9/16/10 6:00 AM, "Patrick Schmidt" <p.l.schmidt@xxxxxx> wrote:

> 
> 
> Am 12.09.2010 um 23:09 schrieb Carl Sorensen:
> 
>> 
>> On 9/12/10 2:21 PM, "Patrick Schmidt" <p.l.schmidt@xxxxxx> wrote:
>> 
>>> Hi all,
>>> 
>>> here is a solution for typesetting power chords and their symbols.
>>> The solution is not new and I didn't invent it but including the
>>> little file makes life a tiny bit easier. Maybe these few lines of
>>> code could become part of the lilypond bundle thus making it
>>> unnecessary to have to include them in each and every file containing
>>> power chords??? Where would they have to go?
>> 
>> I think they could be added to ly/chord-modifiers-init.ly
> Is there anything wrong with adding the following lines to ly/chord-
> modifiers-init.ly?
> 
> powerChordSymbol = {
>      <c g>-\markup { \normal-size-super "5" }
>      <c g c'>1-\markup { \normal-size-super "5" }
> }
> 
> powerChords =
> #(sequential-music-to-chord-exceptions powerChordSymbol #t)

Adding these to ly/chord-modifiers-init.ly would be fine.

> 
> I also would like to have a command like \powerChords to avoid to
> have to write "\set chordNameExceptions = #powerChords". So far I use
> this command in my .ly-files.
> 
> powerChords = {
>    \set chordNameExceptions = #powerChords
> }
> 
> Where do I have to put this command and what do I have to do/change
> to make it an "official/executable" command without having to define
> it "manually" in my .ly-files?
>

This command should probably be added to ly/property-init.ly.  However, it's
possible that it will be moved during patch review.

I think that the way you've currently written this could be improved.  The
way it's written, your second definition of powerChords will replace the
first when the code is parsed, even if it's not used in your ly file.

It would probably be better to define something like

powerChordExceptions =
  #(sequential-music-to-chord-exceptions powerChordSymbol #t)

and then

powerChords = {
   \set chordNameExceptions = #powerChordExceptions
}

This way, powerChordExceptions is still available in case somebody wants to
combine powerChordExceptions with their own personal list of chord
exceptions, by doing something like

myExceptions = 
  #(append (sequential-music-to-chord-exceptions myExceptionMusic #t)
           powerChordExceptions)

>> 
>> I concur with the c:1.5 and c:1.5.8  I prefer these to c:5^3 and c:
>> 5^3.8
>> 
>> These should be added to Appendix A.2 Common chord modifiers.
> I guess there should be only one additional entry showing both
> versions in half notes?
> c2:1.5 c2:1.5.8

I think two entries -- one for two-voiced power chord, one for three-voiced
power chord.

>> 
>>> If no one objects I could offer
>>> to add a few lines of text to the manual concerning power chords??!!
>>> Is it worth adding this example to the snippet repository?
>> 
>> Since this uses \set, it belongs in the manual in the form of a
>> snippet.
>> Write the documentation right into the texidoc for the snippet, and
>> make
>> sure it gets added to the LSR with a docs tag and a fretted strings
>> tag.
> I haven't done that before so I'll first have to find an example for
> that.

If you use the definition of \powerChords, then \powerChords can be used in
the body of the documentation.  But there should still be a snippet showing
how to combine powerChords with other exceptions.

>> 
>> Then, we'll need to modify the Selected Snippets section of NR
>> 2.4.2 to
>> include your snippet.
> Ok, but what about the sections "Extended and altered chords" and
> "Printing chord names"? Shouldn't it be mentioned there as well?

Add a chords tag to the snippet as well.  A @seealso reference in each of
these sections would be appropriate.

When I search for "power chord" in google, it is clear that this is
primarily a guitar term, so I think it's appropriate to have the primary
documentation section in the Guitar music.

>> 
>> Also, I'd recommend that we consider adding the power chords to
>> ly/predefined-guitar-fretboards.ly.  Currently, the manual shows
>> how they
>> could be added as alternate voicings of regular major chords.  But
>> now that
>> you have specific chord modifier sequences for power chords, I
>> think it
>> makes great sense to add them to the predefineds.  If we do that,
>> then we
>> don't need to worry about adjusting minimumFret when transposing
>> (and the
>> predefined fretboard will automatically be transferred to the
>> tablature).
> I'll do that first. But unfortunately it's not possible to define
> different diagrams for the same pitches on different strings (unless
> we use different octaves for the chords which leads to wrong octaves
> in note mode.

My take is that predefined fretboards aren't really used in note mode.  I've
never seen a fret diagram used when the exact notes to be played are shown
in the music below the fret diagram.  So I'm not particularly concerned
about this issue.  At the same time, I don't feel strongly about going
forward with different voicings in different octaves.  Any user who wants to
can easily define their own predefined fretboards.

> So I don't think this is a good idea. I have some ideas
> and questions concerning chord mode but I'll post them separately)
> This means that I can only add a few diagrams to the predefineds,
> e.g. maybe some sort of compromise: 3-voiced power chords on the 6th
> string from e, to d and 2-voiced power chords on the 5th string from
> a to g?

IF you don't think we ought to add power chords to the predefined diagrams,
I'm fine with that.  If you think that the set you proposed makes sense to
add, I'm fine with that.  You're much more of an expert on power chords than
I am, so I'm perfectly willing to defer to your judgment.  That's why I said
"we should consider adding" the predefined fretboards, not "we should add"
the predefined fretboards.  Your choice -- do what you think is best.
> 
> Is this of any use?
> 

I think it's of great use!

Thanks,

Carl




Mail converted by MHonArc 2.6.19+ http://listengine.tuxfamily.org/