Werner LEMBERG wrote:
I just type-set a piece using version 2.7.7 and this piece also
had some ties in it. In this example I thought the new behavior was
a bit odd as I have two ties in a row but they are longer note
values and should they not appear at the same level? I noticed that
the change-log gives an example of this new feature but the first
note is tied to a very short note followed by a longer one.
I second that. Especially in chords, short ties are moved too much
vertically from the `correct' place. IMHO, this:
--___-------------___---
/ \ _____ / \
\___/ / \ \___/
------------------------
looks *really* bad. A tie, regardless of being short or long, must
not be placed completely between two staff lines if the notes are also
between the same two lines.
It depends. I think it should, but only in crowded situations.
For further references I suggest that you take a Henle or UE edition
of Beethoven's piano sonatas (the later ones).
I agree that the Tie code is not optimal. Unfortunately, writing it
already took it two to three times as long as I estimated (and was paid
for), and I just spent another 1.5 hours debugging some problems. Now
that it is more or less working, I have a better idea how the code
should really have been written. I think it would probably be easier to
do with a scoring based approach: generate all possible
tie-configurations (TC, ie. all combinations of (Y, UPDOWN-DIRECTION) )
The number of TCs is
M = (highest position - lowest position) * 2
Then, a single tie-column-configuration (TCC) for N ties is a subset of
TCS with N elements. Counting tie-head distances, tie-tie collisions,
tie-line collisions, and direction violations yields a score for a
single TCC. Then we need to find the best-scoring TCC.
The number of TCCs is binom(M, #ties). A chord spanning a single octave
with 4 ties already yields 36000 different possible TCCs, so a brute
force approach won't possible. We'd have to use a some heuristics to
generate a limited number of sensible TCCs, and pick the best scoring
one of them.
--
Han-Wen Nienhuys - [EMAIL PROTECTED] - http://www.xs4all.nl/~hanwen
_______________________________________________
lilypond-user mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/lilypond-user
