Re: Better pure heights for slurs (issue 5431065)

[address@hidden]

On Nov 27, 2011, at 11:16 PM, address@hidden wrote:

> LGTM
> Removing the contribution from 'height-limit' to estimated slur heights
> is very helpful.  It was never appropriate to add 'height-limit' to the
> extent of the slurred notes, because the note or stem furthest in the
> direction of the slur is much closer to the curve of the slur than
> 'height-limit'.  Piano music often has to increase height-limit, and the
> formerly ridiculous height estimates made the page-breaker useless for
> me.
> 
> Estimating the slur extent as an offset from the notes in the direction
> of the slur, rather than a widening of the notes extent on both sides,
> should also help a bit.
> 
> The stuff with slur slopes is fümms bö wö tää zää uu, but seems
> harmless.
> 
> 

The idea is that if there is no vertical gap between the start and end notes, 
then the "height" will be fully vertical (and height_approximation should thus 
be multiplied by 1).  If, on the other hand, there is a big gap between the 
start and end notes, there will be almost no vertical height (and 
heigh_approximation should thus be multiplied by 0).  The reason I use 1 - 
arctan (some_stuff) is because it gives a smooth, continuous function that 
encapsulates this idea.


> 
> http://codereview.appspot.com/5431065/diff/8002/lily/slur.cc
> File lily/slur.cc (right):
> 
> http://codereview.appspot.com/5431065/diff/8002/lily/slur.cc#newcode101
> lily/slur.cc:101: ret[downup] = minmax (downup, d[dir], ret[downup]);
> any different from ret.add_point(d[dir])
> 

Nope - changed.

> http://codereview.appspot.com/5431065/diff/8002/lily/slur.cc#newcode113
> lily/slur.cc:113: // we dampen the height approximation by the slur's
> likely slope
> 'height_approximation' now stores free_head_distance_, which is applied
> vertically so its effect doesn't depend on slope of the slur.  Its value
> is very small by default, and is only a request to the slur scoring
> routine, so why bother with it?
> 

Mm...I'm not sure.  I know we're talking about pocket change (between 0.0 and 
0.3 vertical space) in an approximation that'll only ever determine how the 
page breaker does its thing, but if we eliminate it, it could theoretically 
result in too-cramped pages.  That said, I've followed your advice and scrapped 
it in my most recent patch set, but with a comment that it may need to be added 
back in.

> http://codereview.appspot.com/5431065/diff/8002/lily/slur.cc#newcode114
> lily/slur.cc:114: // steeper slopes get smaller factors
> Without a count of the note-columns spanned, this is more of a height
> than a slope.
> 
> And larger slopes/heights get larger 'factor's, smaller '(1 - factor)'s
> 
> http://codereview.appspot.com/5431065/diff/8002/lily/slur.cc#newcode116
> lily/slur.cc:116: ret[dir] += height_approximation * (1 - factor);
> dir *
> 
> http://codereview.appspot.com/5431065/