Re: Auto-beaming infrastructure redo

[Hans Aberg]

On 2 Jul 2010, at 16:22, Carl Sorensen wrote:

> 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.

As for meters, there is a need to define those. Currently, LilyPond  
seems letting time signatures determining meters. This is fine in CPP.  
For other types of music, one would like to depart from that, viewing  
the time signature as a derivative of the meter.

I think that the beaming structure is the same for expressing non- 
metric accents, only that it applies locally so a segment of music.  
There, the current LilyPond syntax does not admit full level accent  
level nesting in a convenient way.

> And so I'd like some feedback about (a) names of properties, and
> (b) the ideas I have for use of properties.

I found it necessary to in part invent a new, more clearly defined  
terminology, in the absence of a generally accepted one. So I guess  
you will have to likewise.

There is a Germanic-Latin divide in terminology, between Germany and  
France going up and down in Europe. On the Latin side, "duple" and  
"triple" refers to structure of the music, but not the metric accents.  
On the Germanic side, those are 2- and 3-time meters. Best to avoid  
this term.

Otherwise, I ended up using mostly Germanic style definitions. There  
is a difference between simple and compound, too (see below). It does  
not matter what words one is using - I used what was similar in math.

> 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.

So one generally seems to think of meters built up by fundamental  
components rather than divisions from a higher value. This is  
complicated by tuplets, which can be metrical, though rare. But adding  
it will make the structure the same as for non-metric accents.

The simplest unit is "in one". If it has subdivisions, one beams it as  
fully as possible, as there is no subaccent structure to indicate.  
Though there are some defaults: 3 is in 3, 6 is in 2. Then "in k",  
where k is an integer > 1, means a group where the first subgroup has  
a strong accent, and the other subgroups weaker accents. All else is  
unspecific, subject to interpretation. Specifically, this is k units  
followed by a note value; mathematically a pair (k, n), where n is a  
note.

One can define more complicated subgroups by the use of +,  
parenthesizes, and "in k" groups.

> 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.

Then I ended up defining two concepts: simple and compound meters. The  
simple meters are just those "in k", a pair (k, n), which does not use  
+ or parenthesizes.

Then one might define a regular meter as one which can be rewritten  
into a simple meter by means of a substitution. For example, the  
common 6/8 can be rewritten into 2/4 which is the pair (2, 1/4).

Those that are not regular are irregular. I don't think this concept  
of regular-irregular helps the beaming question though.

Note the complication of the meter 4/4: there are two interpretations,  
as the simple meter (4, 1/4) and as the compound meter (2, 1/4) + (2,  
1/4). It think the French Wikipedia indicated both. Strictly speaking,  
one has two different meters here, that might require different beaming.

> 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.

This is the Germanic way (from Scandinavia down to the Balkans). Look  
into the ENglish Wikipedia, and you will find another definition.  
People seem to be rather emotional when they discover the difference.

> 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.

Here it seems you are shifting to a Latin terminology. In Germanic  
tradition, 2, 3, 4 are simple, and others, like 6 are compound.

> 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 numbers that are multiples only has factors 2 and 3, the CPP  
default is assuming they have this subdivision. Otherwise, one has to  
indicate the subdivision using +. For example, 5 is 2+3 or 3+2. One  
can divide 6 as 2+2+2; I have an example in Bulgarian music where it  
used along with a 7.

There is a complication that one can have "in one". Finale has such an  
option, I am told. Beethoven's 5th is normally performed in one,  
though written in 2. In Balkan music, one can have 7 = 2+2+1+2 or 9 =  
2+2+2+1+2, for example.

> 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.

If one uses the nesting with +, parenthesizes and simple pairs (k, n)  
one comes down to the lowest level of (k, n) pairs. Then then work  
upwards first with number of beams until beam groups, possibly with  
different dotted bars, and even a metric shift structure.

The trick would be to describe this hierarchical structure.

> The concept of a fundamental unit differing from the beat is not  
> currently
> well-supported in LilyPond.

This was my impression, too, but it is a bit more complicated.

> 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.

So here is the connection with metric and other accent structures: I  
think they are the same. So focusing on both might be simpler.

> 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).

So there are really to 4, (using Germanic terminology) the simple 4  
and the compound 2+2.

> 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.

And as for 3, there are also meters: the simple 3, and the "in one"  
three. With the notation above, 3/4 can be (3, 1/4) or (1, 3/4).

Users must specify which one the want to have. They may want more to  
have in effect more than one subaccent meter, determined by say note  
values or other properties.

> 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).

So I think you need to somehow capture the nested structure of +,  
parenthesizes and pairs (k, n), where k is an integer >= 1, and the  
note value n is a rational number indicating is tome value. Then to  
each level in the tree it defines, one should attach a subbeaming  
construct: number of beams, space between groups, various dotted bars  
or even metric shifts. The number of beams is standard. The dotted  
beam structure must be specified by the user.

  Hans