On Feb 4, 2011, at 10:30 AM, Mike Solomon wrote:
> On Feb 4, 2011, at 10:19 AM, Han-Wen Nienhuys wrote:
>
>> On Fri, Feb 4, 2011 at 10:08 AM, <[email protected]> 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
>
I just integrated all of my work into Han-Wen's new quanting stuff. None of it
seems to be broken - all of the collisions are still avoided.
http://codereview.appspot.com/4131044
Please disregard the previous Rietveld issue on this subject.
Cheers,
MS
_______________________________________________
lilypond-devel mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/lilypond-devel
