[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Plans for docs, snippets and requests

From: Patrick Schmidt
Subject: Re: Plans for docs, snippets and requests
Date: Sat, 06 Feb 2010 12:48:37 +0100

> > This is what I would like to do in the near future:
> > 
> > 1) NR, Custom tablatures: add a list of string tunings. I think the
> users
> > shouldn't have to look up the names of the tunings in
> scm/tablatures.scm. I'm
> > thinking about creating a two-column table containing the names and a
> short
> > description of all available string tunings. Drawback: convert-ly
> couldn't
> > take care?!
> Exhaustive lists are very difficult to maintain, so we won't put them in
> unless some means of maintaining the list is developed.  Now, it shouldn't
> be too hard to develop a snippet that includes scheme to search through
> scm/tablature.scm to find (define-public *-tuning), then for each tuning
> found creates a TabStaff with a tuning key as you describe below. 
> Probably
> this would then belong in the Notation Reference appendices.
Sounds like a very good idea! I'll take a closer look at scheme. Can you 
recommend an existing snippet with a similiar function I could use as an 
> > 
> > 2) create a string tuning diagram (snippet):
> > ① = e♭
> > ② = b♭
> > ③ = g♭
> > etc.
> I can see this being possibly useful, but it seems to me that the tab key
> you propose below is better than the string tuning diagram.
> > 
> > 3) propose a tab key that shows the tuning of the guitar in tablature
> (please
> > see file attached). Maybe it's possible to achieve this with \markup?!
> The best thing to do would be to create a Tab_key_signature engraver. 
> This
> could be written as a straightforward Scheme engraver that would create a
> TabKeySignature grob.  I think it's a *great* idea.
I'll take a look at 

> > 
> > 4) add (or edit) some unnumbered subsubsections to NR subsection Guitar
> such
> > as:
> > - Position playing and barré fingering (instead of Indicating position
> and
> > barring)
> > - Slides (different kind of slides; pick scrape)
> > - Picking & strumming techniques (down & up picking, tremolo picking,
> pick
> > rake, arpeggiated chords/sweeping, pima, flamenco techniques)
> > - Harmonics (Natural, artificial, pinched, tapped, touch harmonics)
> > - Muted notes (Palm muting and fret hand muting (dead notes)
> > - Bending and vibrato (bend up and release; Re-pick bend; pre-bend;
> quarter
> > tone bend; vibrato)
> > - Vibrato bar/Whammy bar (Vibrato bar bends, scoop and doop, sustained
> note
> > and dive bomb, gargle)
> > - Capo notation
> > - Hammer-on & Pull-off (HO, PO, note trills, left/right hand tapping)
> > - Other techniques (Violining)
> It's important that the Notation Reference not be a tutorial on guitar
> playing, but a reference on generating LilyPond output.  For this reason,
> I
> prefer "Indicating position" to "Position playing".  The emphasis is on
> the
> notation, not the playing.  Similarly, "Picking and strumming techniques"
> sounds like a playing reference, not a notation reference.
> If we in fact have all of the notation above implemented as part of
> tablature, then we should have it in the notation reference.  But if such
> things require tweaking to create them, they belong in the Snippets
> section.
> > This would also serve as a test of the TAB-features.
> We don't need to test tablature features in the documentation; the
> features
> should be tested in the regression tests (input/regression/*.ly).
> Of course, the regression tests and the snippets in the documentation can
> be
> nearly the same.
With "test" I meant that I wanted to find out which of the techniques mentioned 
above are already implemented and which ones require tweaking. I think such 
snippets could be useful at least for the Snippet Repository.

> > 
> > 5) chordmode-request: Wouldn't it be good to be able to define any chord
> in
> > \chordmode and use it in normal Staffs, TabStaffs, ChordNames,
> FretBoards and
> > improvisationOn? 
> Right now, in git, a chordmode chord can be used successfully in Staffs,
> TabStaffs, and FretBoards.  ChordNames is currently being addressed by
> Thomas Morgan (see below).  And it can be made to work right now with some
> of the exceptions lists that have been posted on -user.
> I'm not that concerned about improvisationOn.  If I want to set the chords
> in strumming rhythm, then they show up as such in the TabStaff and the
> Staff.  If I don't want to set the chords in strumming rhythm, but instead
> show the strumming rhythm separately from the chords, I use a different
> music expression for the strumming rhythm in improvisationOn (likely
> because
> I want to use some \repeat unfold blocks).
> > A known issue is the problem with inversions. As I see it
> > LilyPond doesn't differentiate between 'closed' and 'open position'. In
> > inversions 3rds, 5ths, 7ths etc. always become the lowest note which
> leads to
> > correct *open* position chords (Drop 2, Drop 3 and "Drop 1"). I think
> the
> > default should be closed position but there should also be an option to
> choose
> > open position (Drop 2 and Drop 3).
> I'm sorry, but I don't understand 'closed position' and 'open position',
> nor
> Drop 2, Drop 3, and Drop 1.
Open, closed and mixed positions are explained here (Other positions of 
That's the way it was taught at my university, too.
"Drop 1" is not in common use AFAIK. I just used it as an analogy to Drop 2 and 
Drop 3 chords. Drop 2-chords are explained here:

Drop 3 is basically the same. The third note from the top is dropped to the 
bottom of a chord. Drop 2 and Drop 3 chords are not a guitar specific 
phenomenon. You can also find these chords e.g. in Bach chorales.

Right now LilyPond uses closed positions for the root position and 3rd 
inversion (e.g. \chordmode {c } = <c e g> and e.g. \chordmode { c/bes } = <bes 
c e g) but open positions for the 1st and 2nd inversion (e.g. \chordmode { c/e 
} = <e c g> instead of <e g c> and \chordmode { c/g } = <g c e> instead of <g c 
e> ).

Here I tried to describe how closed and open positions can be achieved:
> > In closed position raising the tonic by an octave leads to the first
> > inversion. Raising the root of the first inversion (3rd) by an octave
> will
> > result in the second inversion. The third inversion is achieved by
> raising the
> > root of the second inversion (5th), etc.
> > 
> > Drop 2 chords (open position) can be achieved by lowering the second
> highest
> > note of a closed position by an octave. A closed position 2nd inversion
> (e.g.
> > g bes c e) is thus transformed into an open root position (e.g. c g bes
> e); a
> > closed position third inversion (e.g bes c e g) is transformed into an
> open
> > position first inversion (e.g. e bes c g; a closed root position (e.g. c
> e g
> > bes) turns into an open position second inversion (e.g. g c e bes); a
> closed
> > position first inversion (e.g. e g bes c) turns into an open position
> third
> > inversion (e.g. bes e g c).
> > 
> > Drop 3 chords (open position) can be achieved by lowering the third
> highest
> > note of a closed position by an octave …
> > 
> > I found some other issues:
> > a) I have never seen a chord called "C add8" (c:8^7 or c:sus8 or
> c:3.5.8), "C
> > add10" (c:10^3.7.9) or "C add12" (c,:12^7.9) or even "C12"
> > (c,:8.10.12^ before. I'd just call them all *C* (octave, third
> and
> > fifth position). With <c g' e'> I get the chord name "C12" even though
> there
> > is no twelve in the chord. <c g' c e g> is called "C add12". <e, b' e g
> b e>
> > leads to a very strange chord name (E[major!]8/add8/addb10/add12/add19).
> I
> > know that I could easily put this straight by using e:m in ChordNames
> but
> > wouldn't it be more user-friendly to be able to use the same definition
> > throughout.
> We know that the chord namer is broken.  Thomas Morgan is working on a
> fix.
> He's somewhat run out of time to work on it.  If you would like to pick it
> up and finish his work, I'd guess that he'd be happy to have you do so.
I'll keep this in mind.
> As far as I can see, guitar chord notation is "sloppy".  That is, chords
> on
> guitar don't follow the normal rules for chord naming.  For example, the
> standard 5-string "C" chord is commonly called "C", but it contains 5
> notes.
> And a C major chord by definition is a triad.  The proper formal name for
> <c
> e g c> is *not* C, because it does have an added 8th.  The
> predefined-fretboards architecture is aimed at resolving that problem.
I'm not sure if I understand you. I would agree that guitar chord notation is 
"sloppy". In all the songbooks I know the chord name "C" can represent  <c e g 
c (e)>, <c e g c g'>, <c g' c e (g)>, <c g' c e g c>, etc.
I know that the proper formal (LilyPond) name for <c e g c> is *not* \chordmode 
{ c } but \chordmode { c:8^7 } or \chordmode {c:3.5.8} which is rather 
complicated. That's why I suggested that c:8 should not automatically contain 
the seventh. Even though <c e g c> formally has an added 8th I have never seen 
a normal chord name containing this information. The same holds for other 
chords in which one or more of the three notes of a triad are doubled. So I'd 
suggest that in these cases the chord name should not contain 8/add8 or 
10/add10 or 12/add12. But this is a ChordName issue …

> > b) I'd also suggest that c:8, c:10 and c:12 don't automatically contain
> 7 (and
> > 9). Maybe 8 (and 10) would be more appropriate?
> I'm not sure what you mean here.  If this is a ChordNames issue, see my
> comment about Thomas Morgan above.
> > c) Why are the chord extension numbers limited to 13? Chords such as <e,
> b' e
> > g b e> cannot be defined in \chordmode.
> I don't know.  This was a design decision made by somebody before my time.
> If we need to change that, I'm sure we could.
> > d) It should be possible to print a chord name based on the name of the
> tonic
> > even though the \chordmode definition of that chord didn't contain the
> tonic.
> > Many four part voicings for guitar leave out the tonic e.g. <g c e b'>
> > (Am9/G). a,:m9^1/g leads to Cmaj/G which is true but not intended.
> Patches happily accepted.
> > e) It should also be possible for each step to appear more than once in
> a
> > chord. Some guitar chords contain the same note on several strings (e.g.
> in
> > compositions of Villa-Lobos). Mixed position chords would become
> possible,
> > too.
> Patches happily accepted.

> > b) An alternative/addition to the chordmode-request above could be to
> define
> > all possible fretboards for each chord shape with 3,4,5 and 6
> notes/strings
> > (C-shape, A-shape, G-shape, E-shape and D-shape) in separate .ly-files.
> But
> > this would require some new commands to choose the chord shape and the
> number
> > of strings/notes involved, e.g:
> > 
> > \set FretBoards.cShape = #4
> > 
> > In combination with say \chordmode { c:7 } this should make it possible
> to
> > choose the exact fretboard needed ( <c e bes' c> ). (I know that it's
> possible
> > to define diagrams by using chorded notes but AFAIK these definitions
> are not
> > transposable and they lead to strange chord names.)
> You don't need to do different .ly files.
> It would be sufficient to add another parameter to the predefined
> fretboard
> hash table key, i.e. the number of strings.
> We already define chord shapes, so it would be not too hard to do this.
> I'd be happy to consider any patches you'd like to write.

> > So is there any idea you would second?
> I like all of the ideas except the improvisationOn one.  And I don't
> dislike
> that one.  Any of them would make welcome additions to LilyPond.
I'll see what I can do.


> Thanks,
> Carl

Jetzt kostenlos herunterladen: Internet Explorer 8 und Mozilla Firefox 3.5 -
sicherer, schneller und einfacher!

reply via email to

[Prev in Thread] Current Thread [Next in Thread]