On Mon, Jan 24, 2011 at 10:49 AM, Mike Solomon <mike...@ufl.edu> 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 - han...@xs4all.nl - http://www.xs4all.nl/~hanwen _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
