Re: Issue 37 - new work

[Han-Wen Nienhuys]

On Fri, Jan 28, 2011 at 11:22 AM, Mike Solomon <address@hidden> wrote:
>
> 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?

You are now dramatically extending the problem scope: you are looking
for a configuration that optimizes configurations of all beams at the
same time.  For example, it is conceivable that individually, the beam
for A below staff would be better served when the beam goes up the
line of D''.  However, that would leave no room for the A' beam, since
it would be on top of the A'' beam.

A solution that would work for this should optimize all of the beams
at the same time.  It might be feasible to code, but probably only if
you restrict all the beams to be

You could try thinking of a A completely different option would be to
restrict these beams to be


>
> 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
>
>



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