On Feb 4, 2011, at 10:19 AM, Han-Wen Nienhuys wrote: > On Fri, Feb 4, 2011 at 10:08 AM, <mts...@gmail.com> wrote: >> 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: > > It's for dealing with UP/UP and DOWN/DOWN configs for the outer stems. > Collisions that fall below (for UP/UP) the edges of quant_range will > never really collide. UP/UP and DOWN/DOWN are the normal > configurations, so they would account for 99% of the beam cases. > True, although I think it's important to account for all beaming cases if possible. My old collision code used to work with first_normal_stem and last_normal_stem, but the problem I ran into is that if there are stems in the interior that go in directions other than these (for example, if the beam stems are down [ up up up up up up up down ], which happens a lot in Debussy), looking at just these stems does not reflect what's actually going on w/ the beam. I don't think accounting for all beam cases adds significant overhead to the code: if anything, difficult beaming can simply revert to the old non-optimized behavior (or a variant of it).
Cheers, MS _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
