lilypond-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Issue 37 - new work


From: Mike Solomon
Subject: Re: Issue 37 - new work
Date: Fri, 28 Jan 2011 08:07:53 -0500

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

You're right about the hackish part - I've put a new version on:
http://codereview.appspot.com/4022045
that is less 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.
> 

The problem is that it is difficult to anticipate which beams will be 
problematic unless we run some sort of collision-sniffing algorithm beforehand.

> Have you tried rebasing your work on the proof-of-concept code that I sent?
> 

I haven't, but I read through it attentively.

I really like the approach, as it is much more elegant and simple than mine.  
I'd like to be able to get mine down to that size.

Currently, the reason I'm going with a more protracted approach based on 
pressure (see new patch) is because certain grobs exert downward pressure on 
the beam, certain exert upward pressure, and certain can exert both depending 
on where the beam is placed.  This is why, in my most recent patch, beams move 
up/down correctly (as far as I know! it could be buggy...) depending on what 
type of pressure is being exerted up on them.

You'll see that in action in the regtest.

Do you think there is any way to keep the simplicity of your proof of concept 
while being able to verify the direction of the pressure that grobs exert on 
the beam?

>> there were none before, making it impossible to check for them beforehand.
> 
> I dont understand what you mean here.

Sorry - I don't really understand what I meant either...

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]