Re: Terminology of baseMoment, beats, groups

[Urs Liska]

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