Re: Kneed beam and subdivisions
Gilberto Agostinho wrote > 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 :( I managed to extend the deadline of my master's composition a bit further, so in case anyone is interested this bounty will be active until the 15th of April. Cheers! Gilberto -- View this message in context: http://lilypond.1069038.n5.nabble.com/Kneed-beam-and-subdivisions-tp184473p186670.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
Re: Kneed beam and subdivisions
<https://sourceforge.net/p/testlilyissues/issues/4684/> Yours, Simon On 06.12.2015 13:10, Gilberto Agostinho wrote: 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 ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Kneed beam and subdivisions
Thanks a lot, I really appreciate it, Simon. Take care, Gilberto -- View this message in context: http://lilypond.1069038.n5.nabble.com/Kneed-beam-and-subdivisions-tp184473p184571.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
Re: Kneed beam and subdivisions
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
Kneed beam and subdivisions
Hello bug squad,
I would like to report a "ugly" type of bug. When using kneed beams,
LilyPond does not set a "main beam" around which all subdivisions are
created. The result is not only extremely confusing in some cases, but
also absolutely non-standard. For instance, the code below:
\version "2.19.32"
\autochange {
c'''64[ c c32
\repeat unfold 6 {c'''64 c c32}
c'''64 c c32]
}
Outputs a staircase:
http://lilypond.1069038.n5.nabble.com/file/n184472/00.png
For more on this discussion (and tons of other examples, as well as
excerpts of Elaine Gould's /Behind Bars/), see the full discussion at:
http://lilypond.1069038.n5.nabble.com/Kneed-beams-and-changes-of-staff-td184339.html
Please let me know if I can be of any help with this, okay?
Cheers,
Gilberto
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
