Re: Issue 37 - new work

[Han-Wen Nienhuys]

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