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/ _______________________________________________ lilypond-devel mailing list [email protected] http://lists.gnu.org/mailman/listinfo/lilypond-devel
