Auto-beaming infrastructure redo

[Carl Sorensen]

I'm trying to redo auto-beaming so that it matches better with what I read
in the literature.  When I get it done, I hope to have it set up so that the
default properties do the right thing, and all we have to do is define
exceptions.  Working in this framework, I think the LilyPond syntax needs to
change.  And so I'd like some feedback about (a) names of properties, and
(b) the ideas I have for use of properties.

Let me start with a simple classification of meters.  In order to classify
meters (and their beaming) we have three different levels of structure that
seem to apply:  the fundamental unit, the beat, and the beat combination.

Each measure of music is divided into a number of rhythmic elements or
beats.  For *regular* meters, all beats are the same length.  For irregular
(or complex, or additive) meters, different beats have different lengths.
Hence, for irregular meters, we can't talk about "the beat length", because
there isn't a unique beat length value.

Regular meters can be classified according to the number of beats per
measure.  Duple meters have two, triple meters have three, quadruple meters
have four, and so on.  These terms are really not important for beaming (at
least as far as I can tell) so I won't discuss them more here.

Regular meters can also be classified as simple meters or compound meters.
Simple meters have beats that are regularly divided into two equal parts;
compound meters have beats that are regularly divided into three equal
parts.  Other divisions are possible, but for purposes of this discussion we
will consider those other divisions to be part of the irregular (or complex)
meters.

For simple meters, the fundamental unit is the same as the beat.  So the
beat in 4/4 time is 1/4, and the fundamental unit in 4/4 time is 1/4.
Hence, it is common to think of the beat as the fundamental unit.

However, for compound meters, the fundamental unit is *not* the same as the
beat.  For example, in 6/8 time, the fundamental unit is 1/8, while the beat
is 3/8.

The concept of a fundamental unit differing from the beat is not currently
well-supported in LilyPond.  In current practice, we would consider the
beatLength of 6/8 music to be 1/8 (the fundamental unit, not the beat) and
then establish a beatGrouping of (3 3).  While functional (it provides a
data structure that allows the calculation of appropriate autobeaming), it
differs from the engraving literature.  It also causes problems with beam
subdivision.  The practice in the literature is that beams are divided at
beat boundaries, and subdivided at fundamental unit boundaries.  For the
current LilyPond practice, beams are subdivided at beat boundaries, and
divided at beat group boundaries.

Finally, there is another level of metric structure that is not currently
accommodated in LilyPond.  For 4/4 time, beats 1 and 2 or beats 3 and 4 can
be combined to form a unit (but never beats 2 and 3).  For 3/4 time, beats 1
and 2; or 2 and 3; or 1, 2, and 3 can be combined to form a unit (but only
if the unit includes *all* of beat 2; if beat 2 is split, 3/4 looks like
6/8).  This level of combination is not supported at all in LilyPond, and so
we try to make it work with custom beaming rules.

As I move forward, I think I've settled on the following that I want to have
as properties:

1) subdivideUnit:  a pair (or perhaps moment) that defines the fundamental
unit of the meter.

2) beatLengths: a list that defines the beat lengths in the meter, in terms
of the fundamental unit.  If the meter is irregular or complex, beatLengths
will be a list of all of the beats in the measure.  I haven't yet settled on
what happens in a regular meter.  Currently, I still use a list of all the
beats in the measure (which is automatically generated when the time
signature is changed).  But I could see that for user overrides it might be
preferable to only have one entry in beatLengths.

I've got mixed feelings about the following property:

3) beatCombinations: an alist with a key of beam type, and a value of the
beats that can be combined for that beam type.  This is currently only used
for 3/4 and 4/4 time, and it doesn't really capture the special rules used
for 3/4 and 4/4 time (although it comes close).  I can't decide whether to
create this general property and use it to define rules for 3/4 and 4/4
time, or whether I should just go ahead and hard-code the special rules for
3/4 and 4/4 time (so I could get them perfectly).

I'd welcome any thoughts or suggestions about this implementation.

Thanks,

Carl