Re: Plans for docs, snippets and requests

[Patrick Schmidt]

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

This snippet (scheme-engraver.ly) compiles with an error (version "2.13.10"):

syntax error, unexpected SCM_TOKEN, expecting STRING
    
    #(list

Without any description it's hard to tell for me what the engraver is supposed 
to do in this snippet (even though I followed Eric Knapp's and your emails. But 
– as you suggested – there might be easier ways to write an engraver…

I think first off I'll try to "manually" tweak a minimal example to achieve 
that the pitch names of the standard guitar tuning are printed on the lines of 
the TabStaff. Then I'll try to automate this process and extend it to other 
tunings using the variables defined in tablatures.scm. So maybe this way and 
with the help of the Extending manual I might be able to develop the 
Tab_key_signature_engraver from scratch. Does that sound like a promising 
approach?

> >>> 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.
Well, what about Marc's \palmmute- and \deadNote-commands? If muted notes don't 
get an own section where should I place them in the notation reference?


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




> >>> 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.
True. I wasn't clear. I was aiming at the automatic stacking. Provided an 
automatic stacking going beyond 13 and the chordmode/ChordName-behavior 
described in the last paragraph it would become possible to define the chord <e 
b' e g b e> with a simple e:m15^3. 

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

I didn't mean that this should affect the chord name. I meant the possibility 
to enter something like c:3.5.8.8 or c:8.8. The chordname would still be c.

Cheers,

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