On Feb 5, 2011, at 7:40 AM, Han-Wen Nienhuys wrote: > On Fri, Feb 4, 2011 at 1:30 PM, Mike Solomon <mike...@ufl.edu> wrote: >> 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. > > This is a performance optimization, ie. a way to run collision > detection without performance impact if the object does not really > collide, so it does not need to deal with all cases. >
From reading the code (correct me if I'm wrong), the upper collision in the attachment would be taken into account because its stems all point in the same direction, whereas the bottom one would not because its first and last stem do not completely reflect the beam's stems' directions.
<<inline: updownraw.png>>
<<inline: updown.png>>
In the serialist music of Stockhausen, Messiaen, and Boulez, beams are crucial structural indicators of the pitch collection to which a note belongs. I think that contemporary composers are continuing to use beaming to group pitches in voices that span several octaves. While I agree that 99% of LilyPond users will never run into the configuration in the attached file, it is important to provide for it if we want to be as inclusive as possible. Personally, since writing this beam-collision code, I've created a couple works using it and redone others to take advantage of it. Is there any way that I could measure what type of performance hit LilyPond is taking with this more robust beam-collision code? I am not really qualified to speak to what type of trade-off is acceptable, but it'd be good to have an actual benchmark to make the comparison. Cheers, MS
_______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel