Re: Manual beaming

[Carl Sorensen]

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