[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Introduce Beam_scoring_problem::quant_range, for quickly filtering o
From: |
Mike Solomon |
Subject: |
Re: Introduce Beam_scoring_problem::quant_range, for quickly filtering out invalid positions. (issue4129050) |
Date: |
Fri, 4 Feb 2011 10:30:44 -0500 |
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. 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
- Introduce Beam_scoring_problem::quant_range, for quickly filtering out invalid positions. (issue4129050), hanwenn, 2011/02/04
- Re: Introduce Beam_scoring_problem::quant_range, for quickly filtering out invalid positions. (issue4129050), mtsolo, 2011/02/04
- Re: Introduce Beam_scoring_problem::quant_range, for quickly filtering out invalid positions. (issue4129050), Han-Wen Nienhuys, 2011/02/04
- Re: Introduce Beam_scoring_problem::quant_range, for quickly filtering out invalid positions. (issue4129050),
Mike Solomon <=
- Re: Introduce Beam_scoring_problem::quant_range, for quickly filtering out invalid positions. (issue4129050), address@hidden, 2011/02/04
- Re: Introduce Beam_scoring_problem::quant_range, for quickly filtering out invalid positions. (issue4129050), Han-Wen Nienhuys, 2011/02/05
- Re: Introduce Beam_scoring_problem::quant_range, for quickly filtering out invalid positions. (issue4129050), Mike Solomon, 2011/02/05
- Re: Introduce Beam_scoring_problem::quant_range, for quickly filtering out invalid positions. (issue4129050), Han-Wen Nienhuys, 2011/02/07
Re: Introduce Beam_scoring_problem::quant_range, for quickly filtering out invalid positions. (issue4129050), percival . music . ca, 2011/02/04