On 6/28/10 10:36 AM, "Phil Holmes" <address@hidden> wrote:
> I _think_ I've found a bug in manual beaming. See the snippet below and
> the
> image. In the last example in the snippet, the beams end up higher than
> they should be. This seems to be a consequence of having more than one
> note
> between the override Stem beaming commands, and not using 0 2 4 for the
> beamlet numbers.
I guess it's a bug. But it seems to me to be rooted in a nonsensical
musical expression.
What does it mean to have (0 3 4) beaming? What duration of note are you
trying to indicate with (0 3 4) beaming? The beams you have drawn in
order
to get the bug to show up are not musically correct, as far as I can
determine.
From everything I can see in the engraving literature, stem beaming should
be a list that starts at 0 and increases by 1 to produce the desired
number
of beams. There is no precedent I can find in the literature for having
omitted beams in the beam stack.
When a user overrides a function call ('beaming is normally
ly:beam::calc-beaming) with an arbitrary value '((0 1 2) . (0 3 4)), and
when the value is inconsistent with standard musical practice, then it
seems
to me that the user has taken over for the program.
That being said, I agree there is a bug; somehow the location of beam 0
shifts due to the override. But unless there's some real use for this
kind
of notation, the priority should be Postponed, in my opinion.
Thanks,
Carl