"Carl Sorensen" <[email protected]> wrote in message
news:c84f5ada.13762%[email protected]...
On 6/28/10 10:36 AM, "Phil Holmes" <[email protected]> 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
TBH, I couldn't work out why you'd want to mess with which beams are
displayed, but the capability is there and so it should be documented and it
should work as designed. I'll update the snippet in the LSR and I've added
it as an issue: http://code.google.com/p/lilypond/issues/detail?id=1159.
--
Phil Holmes
Bug Squad
_______________________________________________
bug-lilypond mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/bug-lilypond
