On Sat, Jan 29, 2011 at 1:37 PM, [email protected] <[email protected]> wrote:
> > Hey Hanwen, > What you describe above is close-ish to what I wound up putting in my newest I don't think so, since the main scoring loops still loop through all combinations in no particular order. I looked closer at your example; the proof-of-concept code I showed you does not consider stems as collision objects, and hence configs where beams overlay stems of other voices are not considered problems. Let me try to refine my patch to include stems as well. > patch, which only has one pass thru the quanting function. It does all the > quant scoring, then does one last pass to check for collisions. This is > done through allowing "negative" pressure, or an amount of leeway that a > beam has to move in a direction before it will collide with something. > http://codereview.appspot.com/4022045/ > Cheers, > MS -- Han-Wen Nienhuys - [email protected] - http://www.xs4all.nl/~hanwen _______________________________________________ lilypond-devel mailing list [email protected] http://lists.gnu.org/mailman/listinfo/lilypond-devel
