> > 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 _______________________________________________ lilypond-devel mailing list [email protected] http://lists.gnu.org/mailman/listinfo/lilypond-devel
