On Apr 23, 2011, at 8:33 PM, Han-Wen Nienhuys wrote: > 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. > >
If you're confident that the problem will only be caused by stems and not clefs, time signatures, etc., I'll do it. Otherwise, I think it'd be worth it to work on the list-of-intervals solution. Otherwise, beams won't avoid grace note stems, which is the whole reason the stem code was added. Cheers, MS _______________________________________________ lilypond-devel mailing list [email protected] https://lists.gnu.org/mailman/listinfo/lilypond-devel
