On Sat, Apr 23, 2011 at 9:28 AM, [email protected] <[email protected]> wrote:
>>> >>> One interesting thing is that it is the stems, not the noteheads, that >>> are pushing this down. If you remove stems from the >>> beam-collision-engraver, this problem does not arise. Why would stems >>> do this but not note heads? >> >> The problem is that the initial guess for the configuration has two >> choices: over all 'big' collisions, and below the big collisions. The >> separate high note adds a collision that is impossible to pass from >> the top, so we revert to the bottom. >> > Even with a small high note (see above) the problem kicks in. > If you want, I have some time next week to put in printf's and see what the > exact numerical cutoff is for picking the lower solution. My first > commitment is to have a look @ Janek's flag code, and then I can look over > the beam code. The real solution is to work with a list of intervals rather than just an up/down choice. I think the simple quick solution is to disable stems for beam collisions for now. -- Han-Wen Nienhuys - [email protected] - http://www.xs4all.nl/~hanwen _______________________________________________ lilypond-devel mailing list [email protected] https://lists.gnu.org/mailman/listinfo/lilypond-devel
