Re: Fixes issue 39 by raising stems (issue3934041)

[k-ohara5a5a]

On 2011/01/12 15:34:22, MikeSol wrote:
> Fixed (I think).

I like how this patch behaves!
No problems at all this time in the music I threw at it  (but I haven't
yet seen the original issue 39 in music either).

Playing around with the various situations, only 2 problems.

1) the flag in << e'32. \\ e'2>> raises enough to let the dot try to
slip in, and the dot merges with the flag.  Adding 0.2 to raise_tip
gives enough clearance.  This case isn't really within issue39 because
the flagged note goes on the right, but it falls within the test I
suggested:
> > I think the ideal target set is (touch && !merge_possible) but I
will be slow

2) the flag raises for no reason on a few chords where stem-shorten
affects the flag; compare
<< <a' c''>16 \\ a'2 >>  << <c'' e''>16 \\ c''2 >>


http://codereview.appspot.com/3934041/diff/29001/lily/stem.cc
File lily/stem.cc (right):

http://codereview.appspot.com/3934041/diff/29001/lily/stem.cc#newcode398
lily/stem.cc:398: if (initial_length + extra_stem_length + hp[DOWN] >
stem_end)
stem-shorten fooled this filter by reducing your pre-computation of
stem_end, but not reducing initial_length.  I see the contortions you
went through to apply your correction within stem_length().  If you
think it fits more naturally in calc_stem_end_position, that is probably
wiser.  I think I see a good fit but this time I'll test before I
suggest.

http://codereview.appspot.com/3934041/