Re: New slur/tie behaviour

[Trevor Bača]

On 9/4/05, Han-Wen Nienhuys <address@hidden> wrote:
> 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.

Pregenerated tables included as part of the distribution (where the
large combinatorial spaces have already been searched ahead of time)?
Then do single lookups against the "known good table of optimal tie
configurations" during interpretation?

I've seen this solution work well for accidental configuration in
front of humongous chords ... just a thought ...


-- 
Trevor Bača
address@hidden