Re: Plans for docs, snippets and requests

[Patrick Schmidt]

> > 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 
inspiration?
> 
> > 
> > 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 scheme-engraver.ly 
(http://codereview.appspot.com/181109/show).

> 
> > 
> > 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 
triads): http://www.oscarvandillen.com/Triad?printable=yes
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:
http://www.free-guitar-chords.com/drop-2-guitar-chord-voicings.htm 
http://www.guitarlessonworld.com/lessons/lesson43.htm

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^3.5.7.9) 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,

patrick
> 
> Thanks,
> 
> Carl
> 

-- 
Jetzt kostenlos herunterladen: Internet Explorer 8 und Mozilla Firefox 3.5 -
sicherer, schneller und einfacher! http://portal.gmx.net/de/go/chbrowser