[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Terminology of baseMoment, beats, groups

From: Urs Liska
Subject: Re: Terminology of baseMoment, beats, groups
Date: Sat, 11 Nov 2017 21:43:40 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0

Am 11.11.2017 um 15:07 schrieb Hans Åberg:

On 11 Nov 2017, at 12:52, Urs Liska <address@hidden> wrote:

Am 11.11.2017 um 12:30 schrieb David Kastrup:
I find "grouping" without "beat" fine.  I could have been responsible
for the terminology in the code (pretty sure I wasn't, but it matches
the terminology I use quite better).

Now I have certainly not gotten an English music education, so can
someone who did chime in?
I haven't either, but I can refer to Gould's terminology. While we all agree that no 
single engraving book provides "the truth", it is surely a good idea to match 
her terminology, if only to be able to communicate with users/developers of other 

She says: "Divisions of a beat are beamed together in all metres." and states 2/4, 6/8, 
and 2/2 as metres of 2 beats. (p. 153, "Beaming according to the metre")
3/2, and 9/16 are given as examples of metres of 3 beats.

So it's clear that her terminology matches that of beatStructure, "beat" = "beat" and 
"baseMoment" = "Division of a beat".

The example I gave is also present in her examples (p. 155), other examples of 
metres with beats of different lengths include 5/16 (2+3 or 3+2) and 7/8.

So I think we can safely say the terminology of beatStructure is correct (or at 
least acceptable).

"Beat" also refers to what a conductor would do. the 3+3+2 from my example would be given as three 
"beats" by the conductor. Maybe your perception of "beat" as necessarily regular comes from the 
fact that in German we use "beat" too, but usually referring to specific styles that are limited to regular 
beats ...
"Beat" is synonymous with metric accent, but in practise, one also has metric 
subaccents. The notation indicates at which times the accents should occur, but not the 
actual length, and does not fully indicate their relative strength: In 4/4, one knows 
that first beat should be strongest, but there are two common different interpretations 
for the others (see below).

As I wrote elsewhere 3+3+2 is maybe a special case because it's often used as a *rhythm* /as *accents* against a 4+4 or 2+2+2+2 metre.

It seemed easiest to me to define a formal (sub-)beat or metric (sub)-accent 
structure, which has a 1-1 correspondence with the beaming. Then the actual 
beaming used consists of a choice of such formal beat structures for different 
note patterns.

If you are referring to the baseMoment/beatStructure concept I think this is appropriate both technically and musically. What I initiall referred to is that the C++ code uses *different* terms for the entities.

So the 4 above could have the other beats about the same in strength, or alternatively, a 
2+2 pattern. There is also "in one" accent structure, whereby only the first 
beat is accented-whther to call the other unaccented time positions I leave up to you. 
This is normally not typeset, but one can choose it in Finale, I am told.

LilyPond fails in the subbeat structures: For example the common meter, 9/16, 9 
= (2+2)+(2+3), like in the Daichovo, is now typeset as 4+2+3, with a break in 
the beaming between the 2 and 3. It would be nice to be able having them beamed 
together at the top level, but broken on the second one.

I'm not sure I understand what you mean. A simple \time 9/16 will beam 3+3+3, but when you set the beat structure to 2,2,2,3 it will do that.

Or are you talking about subdivisions, with a first beam over the whole measure and secondary beams grouped 2,2,2,3? If so, this would be possible with the changes I have in mind.

As for the tuplets, one needs to have them in a group for the subbeaming to 
come out right. The default is the above in one pattern, except for certain 
multiples of 2 and 3—Hindemith describes those. So there is a problem in 
LilyPond relative the beaming if one is allowed to just write tuplet values 
instead of a full tuplet group.

Actually I don't really understand what you mean here. But LilyPond's handling of tuplets (at least with regard to beam subdivisions, but maybe also for automatic beaming in general) is substantially broken anyway.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]