Re: Plans for docs, snippets and requests

[Carl Sorensen]

On 2/6/10 4:48 AM, "Patrick Schmidt" <address@hidden> wrote:

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

As far as I know, there are no such snippets.  I'll take a look at what's
necessary to extract all the tunings into a list.  Then if you create the
TabKeySignature the snippet will be trivial.

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

Great!

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

Ahh, now I see.  Certainly snippets would belong in the Snippet Repository
as well as in the docs.  But they don't get their own sections if they're
snippets.

Full speed ahead on this, as far as I can see.  This is a great thing to do
for the tablature community.

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

Thanks for the clarification.  Thomas's new chord naming scheme will work
with this; it has "optional" pitches that can be, but aren't required to be,
in a given chord.

I had not paid attention to the 8/10/12 issue.  I'm showing my lack of
formal music training.

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

So you're proposing that c:8 would be the equivalent of c:.3.5.8, c:10 would
be c:.3.5.8.10, c:12 would be c.3.5.8.10.12, and all of them would have the
ChordName of c, right?  I think that makes sense.

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

Actually, this is not true.  Individual pitches can be added to any degree.
See the docs for "Extended and altered chords" in NR 2.7.1.

It's only the automatic stacking that won't go beyond 13.


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

As I've thought more about this, I don't think that named chords should have
a step multiple times.

I think it makes sense for explicitly entered chords to have repeated steps,
and the chord namer should be smart enough to catch it.