[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: TabStaff feature requests

From: Steve Yegge
Subject: Re: TabStaff feature requests
Date: Wed, 24 Nov 2010 06:51:56 -0800

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,


On Tue, Nov 23, 2010 at 9:25 PM, Steve Yegge <address@hidden> wrote:
On Tue, Nov 23, 2010 at 10:16 AM, Carl Sorensen <address@hidden> wrote:
On 11/23/10 12:37 AM, "Steve Yegge" <address@hidden> 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 ""
music = \relative c {
  <a' e' a cs a'>1

\score {
    \new Staff {
    \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

  <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


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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]