<<inline: hanwen6.png>>
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 <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