Re: Introduce Beam_scoring_problem::quant_range, for quickly filtering out invalid positions. (issue4129050)

[Mike Solomon]

On Feb 5, 2011, at 7:40 AM, Han-Wen Nienhuys wrote:

> On Fri, Feb 4, 2011 at 1:30 PM, Mike Solomon <address@hidden> wrote:
>> On Feb 4, 2011, at 10:19 AM, Han-Wen Nienhuys wrote:
>> 
>>> On Fri, Feb 4, 2011 at 10:08 AM,  <address@hidden> 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.

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