Re: Issue 37 - new work

[Mike Solomon]

I cooked up this musical example that shows both responses to upward and 
downward pressure to give you an idea of where I'm coming from.

Is there a way to get this type of collision avoidance w/o a 2nd quanting pass?

Cheers,
~Mike

On Jan 28, 2011, at 7:45 AM, Han-Wen Nienhuys wrote:

> On Thu, Jan 27, 2011 at 12:47 AM, Mike Solomon <address@hidden> wrote:
>> Hey all,
>> 
>> I have a new Issue 37 fix.
>> 
>> The attached patch set implements a 2-pass approach through the quanting 
>> that is potentially a huge time drain in scores with lots of collisions, but 
>> likely not a time drain for most scores.  The problem is that the quanting 
>> algorithm, by fixing a region size, sometimes places all possible solutions 
>> in a range in which a collision will happen.  The algorithm will also 
>> sometimes create collisions where
> 
> The knee code has a similar problem.  See Beam::shift_to_valid on how
> it was handled there.
> 
> I'm not a fan of the 2 pass approach.  With the 2-pass approach, you'd
> always forego any beams with more extreme slopes; also, this patch
> looks hackish,
> 
> 
> +  Direction dir = to_dir (me->get_property ("collision-dir"));
> +
> +  if (dir)
> +  {
> +    Real max_demerit = 0.0;
> +    for (vsize i = qscores.size (); i--;)
> +      max_demerit = max (max_demerit, qscores[i].demerits);
> +
> +    for (vsize i = qscores.size (); i--;)
> +      {
> +        Real d = (yl * dir > qscores[i].yl * dir) || (yr * dir >
> qscores[i].yr * dir)  ? max_demerit : 0.0;
> +        qscores[i].demerits += d;
> +      }
> +  }
> 
> Why not increase the region-size for beams that we know are
> problematic, similar to what we do for knees?  In a typical score most
> beams will not have collisions, so performance would largely be
> unaffected.
> 
> Have you tried rebasing your work on the proof-of-concept code that I sent?
> 
>> there were none before, making it impossible to check for them beforehand.
> 
> I dont understand what you mean here.
> 
>>  Thus, we need to let that collision happen, then move the beam such that it 
>> is >around the point of the collision, and then rerun the quanting 
>> algorithm.  If you >only apply the first patch, you'll still get something 
>> that works, but w/ no good >quanting.
>> 
>> I'd like to hear your opinions - do you see anyway to trim down the 
>> computations?
>> 
>> I've been using the attached .ly file to monitor the results.  The only odd 
>> thing is the small beam for the C that is being squashed by the G, but I 
>> can't figure out a better solution with proper quants.  The alternative here 
>> would be just turning off the collision avoiding, but I haven't figured out 
>> how to do that in that particular scenario.  Otherwise, all of Han-Wen's 
>> concerns are addressed.  And, as before, the truly heinous collisions are 
>> unavoidable because there is no way to anticipate desired output.
>> 
>> I still need to do a make check.
>> 
> 
> 
> 
> -- 
> Han-Wen Nienhuys - address@hidden - http://www.xs4all.nl/~hanwen