I apologize abjectly for taking so long on an issue so simple. Snapping
slurs to beams is intolerable because it makes them hard to read in all
cases. Slurs should stay at the heads of the notes, period. The idea of
snapping slurs to beams is a persistent bad idea. The person responsible
for the innovation simply did not consider the inevitable very bad
consequences. Phrase marks, on the other hand, go above the beams or at
the heads depending on the parts, but also in all cases beyond the
tuplet bracket if there is a tuplet (and more than one part). One
occasionally sees slurs between a beam and a tuplet bracket, and it is a
disgusting sight. Please cause lilypond to stop doing that. The phrase
marks should originate from and end at points exactly above or below the
heads and *equidistant* from the heads or stem ends of the originating
and ending notes. They need not be close. In that way you can very
easily avoid ridiculous horseshoe curves.
Reversing the curve of slurs when there are two or more parts is better
in theory, but unfortunately it is impracticable. I would rather it be
done that way, but I've had to give up the idea as impossible to
adequately implement consistently. I'm sure that all the rulemakers say
that it should be done, but in practice I have found that it is
generally not done by publishers who would rather not snap to beams at
the moment. If the horizontal spacing is tight, a slur bowed toward
beams becomes very short. (That may have been one of the original
justifications of snapping.) The only rational course is to keep the
slurs bowed outward (away from the stems) regardless of the other parts,
unless forced to bow inward by an actual collision. Most publishers,
including Schott, often do it that way. If publishers can't implement a
rule by hand, how can you do it with software? You can't.
If a collision occurs with a slur spanning more than two notes, the slur
should cross the stems. There is absolutely no difference in meaning
between these:
/----3----\ (spread triplet bracket)
===========
| __ | |
|/ \| | (curved lines = slurs)
|* \__/ (close note forces bow in)
|
/----3----\
===========
| ___|___ |
|/ | \|
|*
|
Therefore, a bit of white space so that the curve is broken by the stem
is perfectly logical. Engravers would not like the broken curve because
it would be difficult to draw that way. Why should you care what they
did when it was motivated by laziness alone?
Someone who can't stand this could always use a phrase mark instead of a
slur with no problem unless both are indicated. If he doesn't know or
care what the difference is, he won't use both anyway. You still don't
want anything between a tuplet bracket and a beam or stem end, because
the tuplet indication causes you to interpret the meaning of the beam or
stem end differently. Stem ends, including beams, and tuplets form a
logical unit. Absolute alignment of the stem ends in tuplets is
extremely desirable, and, again, with that feature it would never be
necessary or desirable to put rests on stems. (Jeff Covey's recent
tuplet example would be much more readable that way.) I had to use rests
on stems to write a tango because the (other) software would not do a
triplet including a rest otherwise. It was bad to have to do this:
---------
| | |
r *| *|
when this would be much better:
/---3---\ (tuplet bracket *always*
----- parallel to beam,
| | *always* at stem end)
r *| *|
And there are a lot of eighth notes in the tango too, so the potential
for confusion is there. It's a beginner's piece. It would be better if
the triplets had brackets.
Of course there is no reason for not being able to use any symbol
whatever for a notehead. I just don't think that it should be a default
or necessary workaround. I don't ever want to put a rest on a stem
again. It should never be necessary.
Have I told you lately that I am grateful for the efforts of this crew?
Bless you. Again.
--
Peace, understanding, health and happiness to all beings!
U U u ^^ ` 'U u U ''`'`
_-__o|oO|o-_|o_o_-_MN[-->mm@_-_--___o|o|oU_|o_o__lilypond
dave N Va USA David Raleigh Arnold [EMAIL PROTECTED]
