Hi all, In the file lily/beam.cc, lines 231-232, we find the following comment:
> We want a maximal number of shared beams, but if there is choice, we > take the one that is closest to the end of the stem. I believe the maximal number of shared beams is indeed necessary, but the problem is to always take the beam that is closest to the end of the current stem, since I think this is what leads to the staircase effect. Probably a better algorithm would be to consider the beam closest to the end of the stem at the start of a subgroup. Basically, if a beam is added to a subgroup above the initial beam(s), then all others must be added in the same direction. Once we are back at the same number (or less) of beams as initially, then the next group can be created either up or down once again. E.g. in the image below, the beam for the fourth note in the lower staff should have been an extension of the bottom beam of the third note, since the previous subgroup was added above the initial beam: <http://lilypond.1069038.n5.nabble.com/file/n184520/55.png> One more example showing how the subgroups should have been beamed: <http://lilypond.1069038.n5.nabble.com/file/n184520/16.png> I also would like to offer a small bounty to get this fixed: I can pay 30 EUR to anyone who is able to fix this until February 2016. I know that giving a deadline for a bounty isn't really the most elegant thing to do, but this issue is greatly affecting my final work for my master's degree and I must have the score ready by the end of February :( Cheers, Gilberto -- View this message in context: http://lilypond.1069038.n5.nabble.com/Kneed-beam-and-subdivisions-tp184473p184520.html Sent from the Bugs mailing list archive at Nabble.com. _______________________________________________ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
