Slurs Rests Params Spacing Tab Score

[David Raleigh Arnold]

One of my happiest discoveries is that in the stable version foo =
gub_gub = 100.0  works, which I find amazing, and I hope that never
changes, since it can save *a lot* of typing at collision time.

Can I turn off snap to stem for individual slurs, to get this, for
example? oldTieBehavior doesn't look real good. :-)

===============
| -tie | slur |
|/    \|/    \|
*      *      *
*      *      *
|\    /|\    /|
| slur | ~tie |
===============

(Bass part underneath.)

I know, you've never seen it, but I have. It is the *standard* way of
doing this, but I doubt seriously whether your old buddy Dr. Read ever
even saw it. :-) This example occurs in Tarrega's arrangement (ca. 1900)
of Gottschalk's "Tremolo" (ca. 1850), and probably the piano original
also, and in one of Coste's guitar studies (ca. 1830), the latter
reprinted by Schott in the 1920's I think. In newer music, when there
are more other slurs bowed out under the same beam, it is often used
when needed to avoid collision by Schott. That is how I want to use it
when I have to.  Since you allow nested slurs now, this is sometimes
necessary to take advantage of that feature. The inside slur is always
opposite the outside phrase mark, I hope, which puts slurs and ties at
heads and pm's at stems. I don't understand why you no longer allow ~
for slurs as well as ties anyway. If lily can issue a warning, it can
write the slur.  With grace notes the curved line is neither a slur,
because grace notes are slurred anyway, nor a tie, because an
anticipation would be tied anyway, but a usually unnecessary indicator
of whether time is taken from the note after or before, and completely
without other meaning. If a grace note is tied (to the previous of the
same pitch), is the following note slurred? Maybe. *Nobody* knows. Don't
you want to avoid that sort of question?

Why can't I enter rc'4 to put r4 at c' on the staff? To override decent
settings when there are 3 parts on one staff and the rest *must* be
squeezed in. It happens. That was a problem with the Milan Pavan, too.
It broke.

Quite a number of params.ly don't seem to work in /paper, including
rulethickness, which is mentioned in the tutorial, and
gourlay_maxmeasures. Increasing notespace is probably better than
maxmeasures anyway, but I wanted to experiment with rulethickness,
because a printer doesn't print lines, it prints dots. I improved the
look of my scores greatly by making the stems the same width as the
staff lines. Since both work visually with noteheads, it is rational
that the best width for the one is the same as the best width for the
other. To do otherwise is to sacrifice legibility for some esthetic that
makes no sense to me. *Nothing* is more important than legibility, or
even close. That should be the default. You should mention Barenreiter
or whoever in the comments, for those who want to sacrifice legibility
for something-or-other. :-)

Lily spaces this way:

|  |   | | |   |
*  o   * | o   o


instead of this:

|  |     | | |     |
*  o     * | o     o

which is good, because it is more compact, but if you have multiple
parts on one staff, like Jeff's Milan Pavan in Mutopia, it looks really
bad. Worse than this, if in 3 time:

|  |   | | |   |
*  o   * | o   o
o   o    | *  o   R  
|   |    | |  |   (

in which case, one wants this, adding collision, fingering and
accidental:

|  |     |  | |        |
*  o     *  | o        o
o     o     |  *  4#o     R  
|     |     |  |    |     (

I hope that lilypond does that now, and if it is done by constructing a
virtual part from the other parts, for horizontal spacing, and then
optimizing *its* spacing:

                             **= horizontal shift
2  1  1  1    2     1  1  0  = how many notes at\
*  *  *  *  | **  4#*  *  R    \each event, for tab
|  |  |  |  | |     |  |  (

then it can also be used to make tab from a tab staff, so that only
string (a letter) and fret (a number or anything that can look up a
symbol from a list) need be entered, and not the pitch or time value?

Is it still necessary to enter time values in lyrics? Why?

You no longer have to have \score at the end of the ly file, yes? Lily
now reads \score first and then looks above the *first* score block and
then below the *current* score block for the first instance of
\whatever-is-in-it? Otherwise, it seems to work the best to put the
absolute least possible outside of a score block and forget
modularization. When I upgrade, I can have melody-x = .... be the last
thing in the file, yes? And still have multiple score blocks in one file
if I want?