On 2024-07-02 21:33, Werner LEMBERG - wl(a)gnu.org wrote:
My beam subdivision algorithm tries to strictly respect metric
values as subdivision is intended to ease readers' track of the
current measure position. Adding features that loosen that
strictness such as one to support your desired output may allow
composers to unintentionally confuse readers, [...]
Well, this beam notation is not my invention but rather found in
existing scores. The specific subdivision was taken from Henle's
Urtext version of Händel's violin sonata in g minor HWV 368, bar 2.
https://www.henle.de/de/7-Sonaten-fuer-Violine-und-Generalbass/HN-191#
I guess the very reason for using this kind of subdivision is to make
it resemble the first edition's incorrect beaming as much as possible
(see attached image).
Nevertheless, it may be simple enough to make a new context property
that defines ab offset for # of beamlets while still respecting the
value of `minimumBeamSubdivisionInterval`. So in your case, that new
context property would be 1 (must be a whole number).
Sounds very promising! I'm waiting for your Merge Request :-)
I have thought of a probably better solution. Currently, if
`minimumBeamSubdivisionInterval` > `maximumBeamSubdivisionInterval`, the
algorithm basically pretends that `subdivideBeams` is false. What if I
change the behavior of that case such that you can add
`maximumBeamSubdivisionInterval = \musicLength 16` to your example for
your desired output? Not sure if it's as simple as removing this check
in an if statement.
Even though you want this special subdivision at just one point in your
example, do you have examples where this special subdivision occurs at
multiple points in the same beam? My former suggestion acts as a offset
of # of beamlets for every subdivision, this suggestion acts as a bound
on # of beamlets.
