On Thu, Jan 27, 2011 at 12:47 AM, Mike Solomon <mike...@ufl.edu> 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 - han...@xs4all.nl - http://www.xs4all.nl/~hanwen _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel