lilypond-devel
[Top][All Lists]

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

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

```