Re: Plans for docs, snippets and requests

[Carl Sorensen]

On 2/5/10 5:35 AM, "Patrick Schmidt" <address@hidden> wrote:

> Dear Carl,
> 
> I hope you received my last patch (01/02/2010).

Oh, I did receive this patch, but somehow lost it in my inbox.  I will
review it.  It will probably be tomorrow before I can get the review done.

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

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

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

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

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

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.

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

> 
> 6) fretboards:
> a) bug or feature? The barre "bar" does not always cross all needed strings in
> fret diagrams. If the highest strings are fretted with fingers other than the
> first one then the barre ends before these strings, e.g.:
> 
> \storePredefinedDiagram <c g bes e'>
>                         #guitar-tuning
>                         #"x;3-1-(;5-3;3-1-);5-4;x;"
> 
> 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.


> 
> c) There is a mistake in the second example of the unnumbered subsubsection
> "Automatic fret diagrams" (NR):
> 
> \storePredefinedDiagram <c e g c' e'>
>                         #guitar-tuning
>                         #"x;3-1-(;5-2;5-3;5-4;3-1-1);"
> 
> The last line should be changed to
> 
> #"x;3-1-(;5-2;5-3;5-4;3-1-);"
> 
> I wanted to send a patch but this probably would have interfered with my last
> one?

Thank you for catching this!  I'll fix it.

> 
> 7) ly2musicxml: A few weeks ago I started to write a perl script to convert
> ly-files to MusicXML which is probably not the proper way to do it. My
> original intention was not to be able to export ly-files to other
> (proprietary) notation formats but to be able to play the music in a browser
> (e.g. using the Myriad Music Plug-in as some sort of electronic notestand).
> The biggest problem is that MusicXML doesn't support all LilyPond-functions.
> It only covers a narrow time slot in music history (common western musical
> notation from the seventeenth century onwards, including both classical and
> popular music). So maybe it would be a better idea to develop an open source
> browser plug-in (LilyPond-Player) to preserve the lock-in status of LilyPond.
> Is this possible? If yes, where would I have to start to make it happen?

Because of the flexibility of LilyPond, I don't think a browser plug-in
would be secure.

\repeat unfold 30000 {\repeat unfold 30000 {\repeat unfold 30000 {c4}}}

I think the best thing to do is to create a MusicXML output format in
LilyPond.  I haven't looked into it, but it's been discussed on -devel in
the past.


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

Thanks,

Carl