Re: Reintroduce beaming "begin" rules back to solve issues?

[Carl Sorensen]

On 2/19/12 1:45 PM, "Xavier Scheuer" <address@hidden> wrote:

>Hi Carl, dear developers,
>
>Carl's recent comment in issue #2246 , introducing  beamHalfMeasure ,
>make me think, because I have never heard of such concept as "half
>measure beaming".  Is it explained that way in references like Ross,
>Read or Gould?  Or is it a concept that have no musical meaning but
>that is purely a "programming commodity" variable to use in LilytPond's
>beaming "system" code?

Quoting Gould: "In 3/4, any number of quavers can be beamed together[,]
provided that groups in 3/4 do not give the appearance of 6/8
accentuation.  a4. a8[ a a] incorrectly implies 6/8 accentuation.  (Music
from the Classical and Romantic periods frequently uses this beaming --
the context makes it clear that cross rhythm is not intended."

3/4 appears to have 6/8 accentuation when a half measure is beamed
together.

I would welcome suggestions you might have for a better name.


>
>LilyPond beaming rules system is really great ‹which is mainly due to
>Carl's work‹ thanks and congratulations.  It is also really nice to see
>Carl improving it again for the rare cases where some users want
>different specific rules to achieve their expectations.
>
>But I'm a little bit afraid that "strictBeatBeaming", "beamHalfMeasure"
>introduced to fix respectively issues #2228 and #2246 might
>"overcomplicate" the automatic beaming rules system (which is already
>not easy to understand, especially for lambda users) and could
>potentially produce unwanted/unexpected *new* issues in circumstances
>other than what was the original fix for (at least that is my impression
>as a user).

I understand your concern, but I'm not overly concerned with this problem.

beamHalfMeasure *only* applies in 3/4 time, as does beamFullMeasure.

strictBeatBeaming allows users to change the subdivision to respect beats,
if they want it to do so.  It has been demonstrated to produce *no*
unintended changes in the regtests, which do a lot of checking of beams.

In all of these cases, the default properties produce the generally
desired behavior. Changing the defaults is only required to produce
exceptional behavior.  And the change is quite straightforward, and is
shown in the documentation.

>
>IIRC 2.12 beaming system made the distinction between rules allowing a
>beam to _start_ ("begin" rules) and rules allowing the beam to _end_
>("end" rules) at specific moment in the measure.
>AFAIK the rules implemented in the new 2.14 beaming system are only
>"end" rules.
>Can't we (I mean, probably you, Carl  ;-P) introduce "begin" rules
>again and wouldn't it potentially permit to "solve" situations like the
>ones expressed in issues #2228 and #2246 in a more generic way?
>Or are the concept of "strictBeatBeaming", "beamHalfMeasure" really
>necessary because they would cover cases that would not possibly be
>covered with "begin" beaming rules?
>
>For example, IMVHO, the issue expressed in issue #2228 could be solved
>if we forbid the start ("begin") of 16th beaming on the 4th and 10th
>semiquaver in 6/8 time.

No, this would not work.  Beamlets are not considered to be the start of a
beam.  The beam starts on the first note that is part of the beam.  So
issue 2228 is not concerned with the start of a beam; it's in the middle
of the beam.  And so begin rules wouldn't help.


>And issue #2246 could be solved by forbidding 8th beaming to start
>("begin" rules again) on the 4th quaver of 3/4.
>
>Is there something wrong with this approach?

This is not the way the rules are explained in the references on beaming.
I'm trying to get the logic to match the descriptions that are present in
Gould and the other references.

In general, beaming is considered to indicate the beat.  However, there
are some cases where beaming *doesn't* follow standard beat patterns.
These can be either beamed manually, or by setting beamExceptions.  For
widespread exceptions, we ought to have some way of automatically
including those.

>
>Sorry for "late awakening", I'm following LilyPond development more and
>more scarcely and the code usually goes way over the top of my head.

I'd rather have comments than not, so thanks for your input.

But recognize that I've spent a lot of hours studying beaming references
and the beaming code, so I tend to be fairly attached to my code.  I'll
try to listen when there are suggestions for how to do things better, but
my prejudice is likely to be that things are just fine.

Thanks,

Carl