lilypond-devel
[Top][All Lists]
Advanced

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

Re: Fixing issue 37 with extra position callback (issue3928041)


From: Han-Wen Nienhuys
Subject: Re: Fixing issue 37 with extra position callback (issue3928041)
Date: Mon, 24 Jan 2011 11:22:54 -0200

On Mon, Jan 24, 2011 at 10:49 AM, Mike Solomon <address@hidden> wrote:
> I had just reverted it to the old behavior (I think...).
>
> The question is: when we have a collision like the third example, how much do 
> we shorten the stems before it becomes ridiculous?  We could shorten the 
> stems to avoid the collision there, but if the note were a perfect 5th lower, 
> it'd lead to a very squashed result.

If the note were a 5th lower, there would not be a collision to start with.

> I'm just not sure how low is too low before you have to give up and print a 
> collision.

That is the advantage of scoring: you can give points for how bad the
shortened stem is vs. how bad the colllision is, and let the scoring
figure it out.

The larger context of my objections to your patch is that we used to
have (pre 1.6.0) beam formatting routines like yours: a sequence of
routines that each tried to modify #'positions on its own to fix one
thing (slopes, quantizations, concavity, etc.).   The result was a
mess as all these routines interacted in unpredictable ways, and
although it would work for a large number of cases, there were always
new errors that required more complicated conditional fixups.  We
never got it working 100%, so we threw everything out and moved to
score based formatting.  If you dig in the archive, you can see it
happening around 1.5.42.  In particular, you can see old code being
thrown out in commit 46c5beb169abbc5a03bd57562cda1669640e4c72

Let me whip up a prototype for you to see how it works.

-- 
Han-Wen Nienhuys - address@hidden - http://www.xs4all.nl/~hanwen



reply via email to

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