Re: Kneed beam and subdivisions

[Gilberto Agostinho]

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.