LGTM, but I can't do a regtest today :(
http://codereview.appspot.com/4129050/diff/1/lily/beam-quanting.cc File lily/beam-quanting.cc (right): http://codereview.appspot.com/4129050/diff/1/lily/beam-quanting.cc#newcode215 lily/beam-quanting.cc:215: } Very cool stuff! I won't have time to do a regtest today, but I see what you're doing and it makes a lot of sense. One suggestion: perhaps we should create an enum: enum Stem_dir_scenarios { ALL_UP, ALL_DOWN, DOWN_TO_UP, UP_TO_DOWN, WACKY } that provides a tag for the beam which is then used in this function. My rationale is as follows: There are several functions that cycle through all the stems of a beam before we get to this one (the slope calculating function, for example). If this distinction can be added to a beam before you get here, it can save you a bit of code-duping and it can also constrain the problem even further. If I'm reading this correctly, you're accounting for the first four scenarios in the enum proposed above but not the 5th, where there are stems do not go uniformly from one direction to another (something like c,,16 [c''''' c,, c''''' c,, c,, c'''' ] may do the trick). In this case, you could squish the range even more on the ed side - it would look a lot like your code for the -ed side. http://codereview.appspot.com/4129050/ _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
