Re: Extend Beam::shift_region_to_valid() to also take into account collisions. (issue4239047)

[Han-Wen Nienhuys]

On Mon, Feb 28, 2011 at 11:48 AM,  <address@hidden> wrote:
> Great work!  Two comments below concerning beam properties.
>
>
> http://codereview.appspot.com/4239047/diff/3002/lily/beam.cc
> File lily/beam.cc (right):
>
> http://codereview.appspot.com/4239047/diff/3002/lily/beam.cc#newcode1156
> lily/beam.cc:1156: Real min_y_size = 2.0;
> here, we should have something like
> if (to_boolean (me->get_property ("avoid-collisions"))
> so that users can opt out of the avoidance if they so choose.
> then, we would have an `else' that set the collision penalty in the
> quanting to 0 so that no collision avoidance took place.

?

Why not modify the beam-collision engraver to not add the objects as
collisions in the first place?

> I think that in a lot of real-music scenarios such as organ scores,
> people's may in fact want beams to collide, and thus, they should be
> able to opt-out of this avoidance.

Let's wait for a bit for these situations to surface.  As a first line
of defense, people can simply remove the collision engraver .

> http://codereview.appspot.com/4239047/diff/3002/lily/beam.cc#newcode1256
> lily/beam.cc:1256: beam_left_y = point_in_interval (best, 2.0);
> Here, there should be a padding property that allows users to control
> breathing room for collisions.  Otherwise, you could wind up getting a
> beam that is pushed just below a notehead in the quanting (see example
> in next email).

No, the padding is part of the scoring.  This is code is just to
provide a credible starting point for the quanting code to look.  As
noted in the comments, it assumes single beams as an approximation, so
if you start using this with 128th beams, it may fail.  Are you really
using 128ths in this way? We could add a crude offset to account for
beam multiplicity.

-- 
Han-Wen Nienhuys - address@hidden - http://www.xs4all.nl/~hanwen