Re: Behavior of non-flag side with strictBeatBeaming
> Am I right that you want a solution that prints exactly one beam less > than the neighboring stem with the least beams. Yes, since this looks quite natural to me (well, as far as something in your constructed example can look natural at all). Werner ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Behavior of non-flag side with strictBeatBeaming
Am 15.01.2016 um 08:49 schrieb Urs Liska: >> > 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)? > Maybe I should not add yet another option but change the (new) option to take a symbol \set subdivideAtStrictBeatBeaming = subdivision % beam counts like at a subdivision \set subdivideAtStrictBeatBeaming = simple % print as many beams as possible (one less than all neighbors) \set subdivideAtStrictBeatBeaming = off We could then discuss which of the two first options should be the default. To make it a little clearer for people who haven't followed that closely so far: "subdivision" would print the result as in line F) of the strict-beat-beaming.pdf attached earlier "simple" would instead print three beams between stem 2 and 3 of that line. Opinions? Urs ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Behavior of non-flag side with strictBeatBeaming
Am 15.01.2016 um 08:49 schrieb Urs Liska: >> 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. I could already fix that. Yes, it simply took the beam count from the neighboring stem, and I could tell it to take the lower number of the neighbor and its "generic" beam count (i.e. the one for its own duration). I take the fact that I could identify and fix the issue that easily as a proof that my new approach to iterating over the beam is indeed more straightforward and maintainable than the previous code :-) Urs ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Behavior of non-flag side with strictBeatBeaming
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
Re: Behavior of non-flag side with strictBeatBeaming
> 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. > 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). Actually, I'm missing a solution that looks like F) but has three beams between 2 and 3. 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? Werner ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Behavior of non-flag side with strictBeatBeaming
Am 15.01.2016 um 01:19 schrieb Simon Albrecht: > On 15.01.2016 01:09, Urs Liska wrote: >> F) is interesting as it*only* has strictBeatBeaming set. >> There is no subdivision in the middle of the beam (7-8) because >> subdivideBeams is not set. However, the beamlets at stems 2 and 10 force >> the subdivisions 2-3 and 9-10, each resulting in the beam count >> corresponding to the metrical value of the right stem. > > This looks odd, since there is such a large gap at 2–3. By mere > intuition, I’d say there should be three beams at this position. I think it would be rather trivial to do now. But I think the current solution is what people suggested. With music with such short notes (i.e. high number of beams) anything looks quite strange, and I wouldn't want to engrave *anything* without subdivideBeams on. Urs > > Yours, Simon ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Behavior of non-flag side with strictBeatBeaming
On 15.01.2016 01:09, Urs Liska wrote: F) is interesting as it*only* has strictBeatBeaming set. There is no subdivision in the middle of the beam (7-8) because subdivideBeams is not set. However, the beamlets at stems 2 and 10 force the subdivisions 2-3 and 9-10, each resulting in the beam count corresponding to the metrical value of the right stem. This looks odd, since there is such a large gap at 2–3. By mere intuition, I’d say there should be three beams at this position. Yours, Simon ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Behavior of non-flag side with strictBeatBeaming
Am 14.01.2016 um 12:33 schrieb Kieren MacMillan: >> So I suggest the following: >> >• Default behaviour is (as currently): point the extra beam to the side >> > with more stems (i.e. join them) >> >• strictBeatBeaming produces (as currently) the extra stemlet but (new) >> > joins the beams on the non-flag side >> >• subdivideBeams produces (as currently) a subdivision on the non-flag >> > side, regardless of the strictBeatBeaming setting. >> > The attached image beaming-options.png illustrates these three options. >> > However, as I'm aware that most people will want to have subdivided beams >> > at strictBeatBeaming's extra beamlets, even when beams are not generally >> > subdivided I suggest an option, say "subdivideAtStrictBeaming" that does >> > just that, and set it to ##t as default. > To me, that sounds like the best of all possible worlds. OK, here you go :-) It was quite some work, but I think I'm getting somewhere soon (although I'm sure there will be more intricacies ahead). 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. A) is just the default output, presumably barely usable in this music. 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. D) is also subdivided by 1/16, but has additionally set strictBeatBeaming. It's nearly the same as C) with the exception of the extra beamlet at stem 10 pointing to the right side. E) renders identically to D) although for different reasons: E) has three beams between 9-10 because 10 happens to be at a 1/32 position, so that triggers a subdivision. In D) there would be no subdivision at that point because it looks for the 1/16 positions. However, the extra beamlet at 10 (caused by strictBeatBeaming) forces the beam on the opposite side of the stemlet to be subdivided, and that happens to be a 1/32 position resulting in the three beams. F) is interesting as it *only* has strictBeatBeaming set. There is no subdivision in the middle of the beam (7-8) because subdivideBeams is not set. However, the beamlets at stems 2 and 10 force the subdivisions 2-3 and 9-10, each resulting in the beam count corresponding to the metrical value of the right stem. Finally G) uses (deactivates) the new property subdivideAtStrictBeatBeaming to suppress the triggering of the extra subdivisions. The result is basically the same as A) with the extra beamlets at 2 and 10. I wouldn't ever want to use that setting with *this* music, but there may well be occasions to use it (with less complex music) to be more consistent with other non-subdivided beams. Best Urs strict-beat-beaming.pdf Description: Adobe PDF document ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Behavior of non-flag side with strictBeatBeaming
Hi Urs, > Take the attached example "undivided". Of course the second line is easier to > read and therefore preferable Yes. > So I suggest the following: > • Default behaviour is (as currently): point the extra beam to the side > with more stems (i.e. join them) > • strictBeatBeaming produces (as currently) the extra stemlet but (new) > joins the beams on the non-flag side > • subdivideBeams produces (as currently) a subdivision on the non-flag > side, regardless of the strictBeatBeaming setting. > The attached image beaming-options.png illustrates these three options. > However, as I'm aware that most people will want to have subdivided beams at > strictBeatBeaming's extra beamlets, even when beams are not generally > subdivided I suggest an option, say "subdivideAtStrictBeaming" that does just > that, and set it to ##t as default. To me, that sounds like the best of all possible worlds. Thanks, Kieren. Kieren MacMillan, composer ‣ website: www.kierenmacmillan.info ‣ email: i...@kierenmacmillan.info ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Behavior of non-flag side with strictBeatBeaming
Am 13.01.2016 um 20:07 schrieb Pierre Perol-Schneider: > The second is simply the easiest to read. > HTH > Pierre > > 2016-01-13 18:59 GMT+01:00 Kieren MacMillan > mailto:kieren_macmil...@sympatico.ca>>: > > Hi Urs, > > > which of the attached engravings do you prefer, LilyPond's > current or the modified? > > The second. > And Gould agrees. =) > > Hope this helps! > Kieren. > The more I think of it, the more I find the current behaviour inconsistent. Actually LilyPond forces a subdivision when it performs strictBeatBeaming, not giving the user the choice. Of course the divided rendering is the easiest to read, but that's usually true for subdivideBeams = ##t. Take the attached example "undivided". Of course the second line is easier to read and therefore preferable, but still the first line is possible - and even the default behaviour. So I suggest the following: * Default behaviour is (as currently): point the extra beam to the side with more stems (i.e. join them) * strictBeatBeaming produces (as currently) the extra stemlet but (new) joins the beams on the non-flag side * subdivideBeams produces (as currently) a subdivision on the non-flag side, regardless of the strictBeatBeaming setting. The attached image beaming-options.png illustrates these three options. However, as I'm aware that most people will want to have subdivided beams at strictBeatBeaming's extra beamlets, even when beams are not generally subdivided I suggest an option, say "subdivideAtStrictBeaming" that does just that, and set it to ##t as default. Urs ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Behavior of non-flag side with strictBeatBeaming
The second is simply the easiest to read. HTH Pierre 2016-01-13 18:59 GMT+01:00 Kieren MacMillan : > Hi Urs, > > > which of the attached engravings do you prefer, LilyPond's current or > the modified? > > The second. > And Gould agrees. =) > > Hope this helps! > Kieren. > > > Kieren MacMillan, composer > ‣ website: www.kierenmacmillan.info > ‣ email: i...@kierenmacmillan.info > > > ___ > lilypond-user mailing list > lilypond-user@gnu.org > https://lists.gnu.org/mailman/listinfo/lilypond-user > ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Behavior of non-flag side with strictBeatBeaming
Hi Urs, > which of the attached engravings do you prefer, LilyPond's current or the > modified? The second. And Gould agrees. =) Hope this helps! Kieren. Kieren MacMillan, composer ‣ website: www.kierenmacmillan.info ‣ email: i...@kierenmacmillan.info ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Behavior of non-flag side with strictBeatBeaming
> given the following input
>
> \relative a' {
> \time 6/8
> \set strictBeatBeaming = ##t
> a8.. a32 a16 a
> }
>
> which of the attached engravings do you prefer, LilyPond's current or
> the modified?
[Both images are called `document.png', which is not optimal :-)]
I prefer the second one. Beamlets that are connected with ordinary
beams look very unnatural to me.
Werner
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Behavior of non-flag side with strictBeatBeaming
Am 13.01.2016 um 18:23 schrieb Urs Liska:
>
>
> Am 13.01.2016 um 18:09 schrieb Urs Liska:
>> Hi all,
>>
>> one more beaming question,
>>
>> given the following input
>>
>> \relative a' {
>> \time 6/8
>> \set strictBeatBeaming = ##t
>> a8.. a32 a16 a
>> }
>>
>> which of the attached engravings do you prefer, LilyPond's current or
>> the modified?
>> Would it make sense to add a beaming option (e.g.
>> "strictBeatBeamingNonFlagSide") so the user can choose?
>
> Note that I think this is actually the difference between
> subdivideBeams being ##t or ##f.
> Currently LilyPond produces the second rendering from my previous
> post, regardless of subdivisions or not.
>
> So I'd say *with* strictBeatBeaming *and* subdivided beams the
> non-flag side should have its stems governed by the rhythmic position
> of the subdivision while with strictBeatBeaming and *no* subdivisions
> it should have the beam number of the following stem.
>
> Objections?
>
OK, last one before shutting down for now.
Attached is what I think should be the behavior for the following input:
\version "2.19.36"
notes = \relative a' { a8.. a32 a16 a }
\relative a' {
\time 6/8
\notes
\set subdivideBeams = ##t
\set baseMoment = #(ly:make-moment 1/16)
\notes
\set strictBeatBeaming = ##t
\set subdivideBeams = ##f
\notes
\set subdivideBeams = ##t
\notes
}
Two measures with two beams each, the first beam without, the second
with subdivisions.
First measure with regular beat beaming, the second with
"strictBeatBeaming".
It's obvious that subdivided beams implicitly cause "strictBeatBeaming"
while at the subdivision.
Urs
> Urs
>
>> Best
>> Urs
>>
>>
>> ___
>> lilypond-user mailing list
>> lilypond-user@gnu.org
>> https://lists.gnu.org/mailman/listinfo/lilypond-user
>
>
>
> ___
> lilypond-user mailing list
> lilypond-user@gnu.org
> https://lists.gnu.org/mailman/listinfo/lilypond-user
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Behavior of non-flag side with strictBeatBeaming
Am 13.01.2016 um 18:09 schrieb Urs Liska:
> Hi all,
>
> one more beaming question,
>
> given the following input
>
> \relative a' {
> \time 6/8
> \set strictBeatBeaming = ##t
> a8.. a32 a16 a
> }
>
> which of the attached engravings do you prefer, LilyPond's current or
> the modified?
> Would it make sense to add a beaming option (e.g.
> "strictBeatBeamingNonFlagSide") so the user can choose?
Note that I think this is actually the difference between subdivideBeams
being ##t or ##f.
Currently LilyPond produces the second rendering from my previous post,
regardless of subdivisions or not.
So I'd say *with* strictBeatBeaming *and* subdivided beams the non-flag
side should have its stems governed by the rhythmic position of the
subdivision while with strictBeatBeaming and *no* subdivisions it should
have the beam number of the following stem.
Objections?
Urs
> Best
> Urs
>
>
> ___
> lilypond-user mailing list
> lilypond-user@gnu.org
> https://lists.gnu.org/mailman/listinfo/lilypond-user
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
