After reading Marc's responses I think I see where I may have
sewn some confusion. I have conventional string numbers in the
non-tab staff, since my audience is partly classical guitarists who
cannot (or do not) read tab. So the information I'm providing is
redundant -- it's for two separate audiences. At some point I'll
be looking into compiling them separately, but for now I show
both staffs on each page.
So I can't just turn off string numbers as a workaround for this issue.
Sorry for not being clearer about that,
-steve
On Tue, Nov 23, 2010 at 9:25 PM, Steve Yegge <steve.ye...@gmail.com> wrote:
> On Tue, Nov 23, 2010 at 10:16 AM, Carl Sorensen <c_soren...@byu.edu>wrote:
>
>> On 11/23/10 12:37 AM, "Steve Yegge" <steve.ye...@gmail.com> wrote:
>>
>> > Hi all,
>> >
>> > The TabStaff is amazingly cool. I'm not a big tab user myself,
>> > but for people who want tabs, LilyPond makes it easy to add them.
>> >
>> > I've been busily adding tabs for a few months and have some feature
>> > requests to put into the queue if possible.
>> >
>> > 1) Setting fixed strings to use for ascending/descending chords.
>> > Currently it's nontrivial to specify tab positions for something like:
>> >
>> > <c c'> <d d'> <e e'> <f f'>
>> > <g g'> <a a'> <b b'> <c c'>
>> >
>> > I've found it's most convenient to append the actual strings after
>> > every chord, hence:
>> >
>> > <c c'>\5\3 <d d'>\5\3 <e e'>\5\3 <f f'>\5\3
>> > <g g'>\5\3 <a a'>\5\3 <b b'>\5\3 <c c'>\5\3
>>
>> Why not
>> <c\5 c'\3>
>>
>> Why do you want to put the string numbers *after* the chords, even when
>> you're putting finger numbers inside the chords?
>>
>
> Putting them after the chords is how you prevent printing string numbers.
> It's the documented technique for giving override instructions to the tab
> calculator. You can even put some inside the chord, thus printing them,
> and move others outside in the same chord.
>
> It is a nice feature. Tabulature would in fact be nigh-unusable without
> it,
> because the tab calculator is often "wrong". For example, consider:
>
> \include "english.ly"
> music = \relative c {
> <a' e' a cs a'>1
> }
>
> \score {
> <<
> \new Staff {
> \music
> }
> \new TabStaff {
> \transpose c c, { \music }
> }
> >>
> }
>
> In this example, the low A is placed on the 5th fret, 6th string.
> The minimum fret is the default (zero), but the tab calculator
> does not choose the open-A string, even though it would be
> far more convenient to play it that way. If you annotate it with
> fingerings:
>
> <a'-0 e'-1 a-1 cs-1 a'-4>1
>
> it becomes doubly clear to the guitarist that the open-A string is
> intended here, both because of the -0 fingering notation and
> because it is the only physically reasonable configuration.
>
> There are actually _two_ signals here that the tab calculator
> should be picking up but is not. They are separate issues.
> One is that even though the TabStaff.minimumFret is zero, the
> calculator is not actually using the minimum fret. The other is
> my #2 feature request, which is that it should respect open
> string "fingering" requests, because they are unambiguous.
>
> The workaround is to use string numbers external to the chord.
> Putting them next to their notes merely creates redundant and
> possibly irritating text for the guitarist to parse. It's already clear
> that it's an open A, so having a circled string number at that
> note is pointless. Instead you do this:
>
> <a' e' a cs a'>1\5
>
> And then you recompile and discover that even though extra
> strings are processed from left to right, so the \5 logically should
> go with the low a' note, the tab calculator has given up in despair
> and is now showing only two strings, both incorrect. So you wind
> up with this:
>
> <a' e' a cs a'>1\5\4\3\2\1
>
> and everything is magically solved.
>
> I feel obliged to point out at this juncture that one of the primary
> reasons for LilyPond's awesomeness -- perhaps the single biggest
> reason -- is that it provides you with enough flexibility to work around
> the default behavior if you're willing to dig deep enough.
>
>
>> >
>> > 2) Have the automatic tab calculator understand the -0 fingering.
>> > Currently if you do something like this:
>> >
>> > \relative c' {
>> > \set TabStaff.minimumFret = #2
>> > <d'-0 a'-2 d-3 f-1>
>> > }
>>
>> I would not be in favor of this -- all other fingerings except 0 indicate
>> a
>> finger number, but zero indicates a fret number.
>
>
> Um, no. Think of it from a set-theoretic perspective. You have 4 fingers
> and can choose up to four of them. There are sixteen possibilities, not
> fifteen, because your choice can include the empty set.
>
>
>> I think it's much better
>> to have you write:
>>
>> <d'\4 a'-2 d-3 f-1>
>>
>> This will get you just what you want.
>>
>
> I believe you are mistaken. I do not necessarily want a printed string
> number.
> I would have to set the stencil to ##f with tweaks in order for it to work
> this way.
> It would be the very pinnacle of inconvenience, and a step backward from
> the
> current functionality.
>
>
>>
>> >
>> > It will choose strings 5, 4, 3, 2. Obviously in this case you could
>> > just set the minimum fret to #0, but this may be an exception to a
>> > passage that is otherwise all in position 2.
>> >
>> > Moreover the calculator gets confused by open chords in higher
>> > positions, e.g.
>> >
>> > \relative c {
>> > <e'-2\5 ges-1 d'-3 b-0 b'-4>
>> > }
>> >
>> > It picks correct strings for all the notes except the open b, which
>> > is ignored (and for which a warning is issued). You can fix it
>> > by specifying the remaining strings:
>> >
>> > <e-2\5 gs-1 d'-3 b-0 b'-4>16\4\3\2\1
>>
>> I think it will work correctly if you just specify the string for the note
>> you want open:
>>
>> <e-2\5 gs-1 d'-3 b\2 b'-4>16
>>
>> HTH,
>>
>>
> I'm afraid there is more going on here than meets the eye, so your
> proposal doesn't address the problem. Thanks for considering it,
> though. It helped me think about the problem more clearly.
>
> -steve
>
>
>> Carl
>>
>>
>
_______________________________________________
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
