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 there were none before, making it impossible to check for them beforehand. 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. Cheers, Mike
0002-Triggers-second-quant-pass-for-collisions.patch
Description: Binary data
0001-Implements-a-more-robust-solution-to-issue-37.patch
Description: Binary data
full-beam-collision.ly
Description: Binary data
_______________________________________________ lilypond-devel mailing list [email protected] http://lists.gnu.org/mailman/listinfo/lilypond-devel
