Am 15.01.2016 um 06:52 schrieb Werner LEMBERG: >> I have pulled together a complicated example, which is engraved with >> a number of option combinations. For ease of discussion I have >> numbered the stems. > Thanks. My comments below are of general nature, not specific to > subdivisions.
That's fine. Actually I ended up rewriting the whole beam counting code, so we have the chance to discuss anthing about that - and we are required to look very closely if I haven't introduced any regressions. >> B) and C) are with just subdivideBeams on, but with different >> baseMoment settings. >> For those who didn't notice so far: The divisions between 2-3 and >> 7-8 in B) have a different number of beams: the beam count >> corresponds to the metrical position of the stem right of the >> division. > For me, in B) there should be a beamlet at position 2, pointing into > the direction of position 1. In general, if there is a dotted note, > there should be an associated beamlet that fills up this combination > to a multiple of a (subdivision?) counter. Consequently, I also want > a beamlet at position 10, pointing to 11, as shown in D). This has always been intentional, as documented by the code comments: " // Try to avoid sticking-out flags as much as possible by pointing // my flags at the neighbor with the most flags. " This is what the option strictBeatBeaming is for, and version D) provides that flag at stem 10. It's LilyPond's explicit intention to avoid flags whenever possible, except the user explicitly asks for the different thing. So you can either simply set strictBeatBeaming to ##t, put that in your global stylesheet, or start a discussion whether LilyPond should change that option's default to ##t. > > Actually, I'm missing a solution that looks like F) but has three > beams between 2 and 3. I've been thinking about that too. This would somehow be like a "partial subdivision" where the beam count is not governed by the rhythmic_importance of the right note. Am I right that you want a solution that prints exactly one beam less than the neighboring stem with the least beams. I don't think you'd want to print four beams if it should happen to fall on a "1/64" subdivision? In general I think having the implicitly generated subdivision governed by the metric situation is a good thing, as it helps the eye knowing where we are. So I would prefer having yet another context option to control that behaviour. Any opinions whether that might be appropriate (to add an option for such a minor issue)? > > In solution G), I think that position 2 is really invalid. How can it > have a duration of 1/32 and 1/64 at the same time? That's true. I'll have to look into that (obviously the stem is also looking to the right side and takes more beams than it can handle ;-) ). Thanks for spotting. Urs > > > Werner _______________________________________________ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
