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 _______________________________________________ lilypond-devel mailing list [email protected] http://lists.gnu.org/mailman/listinfo/lilypond-devel
