lilypond-user
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Behavior of non-flag side with strictBeatBeaming


From: Urs Liska
Subject: Re: Behavior of non-flag side with strictBeatBeaming
Date: Thu, 14 Jan 2016 09:00:34 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0



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 <address@hidden>:
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

Attachment: undivided.png
Description: PNG image

Attachment: beaming-options.png
Description: PNG image


reply via email to

[Prev in Thread] Current Thread [Next in Thread]