Re: Automatic beaming fails with tuplets

[Hans Åberg]

> On 13 Nov 2017, at 23:39, Urs Liska <address@hidden> wrote:

> sorry for the delay. I had private matters to take care of - but in the 
> meantime I've incorporated several of your thoughts in my document already ...

Fine.

> Am 11.11.2017 um 22:53 schrieb Hans Åberg:
>> 
>>> On 11 Nov 2017, at 22:29, Urs Liska <address@hidden> wrote:
>>> 
>>> Am 11.11.2017 um 22:11 schrieb Hans Åberg:
>>>>> On 11 Nov 2017, at 21:32, Urs Liska <address@hidden> wrote:
>>>>> 
>>>>> AFAICS a tuplet suspends/shadows/interrupts the beatStructure. The 
>>>>> regular processing of the measure should ignore a tuplet, and the tuplet 
>>>>> should be handled separately.
>>>> Each full tuplet group behaves like a mini-measure with its own beaming 
>>>> pattern, though the general structure is the same. The beaming is then as 
>>>> of the written notes values, not the actual timing values implied.
>>> Exactly. And that's what LilyPond currently (explicitly) does wrong.
>> I think the feature that one may enter just the note value and not a full 
>> tuplet group leads into the wrong track. If one should have that feature,
> 
> I think so, as I've often encountered music with mixed meters of, say, 4/4 
> plus one eighth triplet (i.e. 4/4 + 1/12).

(See below.)

>> for correct beaming, one should first reduce it to full tuplet groups, and 
>> then apply its local beatStructure.
> 
> I'm not sure how that would apply if the tuplet group isn't complete, like in 
> my example given in the previous paragraph.

I suspect that the beaming model breaks down here, and it is a flaw of LilyPond 
to no always require full tuple groups. So somehow, when entering a full tuplet 
group, that structure should be forwarded to the beaming algorithm. Then it is 
unclear what exactly to do when it is not a full group.

>>>>> From the results I assume that the beaming code suffers from the same 
>>>>> misconception as the code in beaming-pattern: tuplets are recalculated 
>>>>> and processed according to their *absolute position* in the measure. That 
>>>>> means that an event that happens to occur on a beat of the measure's beat 
>>>>> structure is treated like an event on a beat, which is incorrect. Instead 
>>>>> the tuplet should get a "virtual" beat structure.
>>>>> 
>>>>> In the example we have a 3/2 tuplet giving three crotchets over two. So 
>>>>> any beaming (and subdivisions) should be based on an assumed 
>>>>> beatStructure of three crotchets. That way the eight notes would 
>>>>> automatically beamed together because they represent one crotchet.
>>>> Each tuplet should have its own local beatStructure. A sextuplet should 
>>>> have by default a 3 3 beatStructure, if not explicitly overridden.
>>> With sextuplets I've come to the conclusion that it's possible to shorten 
>>> the fractions - together with the tupletSpannerDuration.
>>> 
>>> \tuplet 6/4 4 is equivalent (in terms of beaming) to \tuplet 3/2 8. The 
>>> same is true for \tuplet 12/8 4 => \tuplet 3/2 16, so I think it's a 
>>> general rule.
>> Hindemith, "Elementary Training", p. 116, suggests that 6 8th notes beamed 
>> together should be musically interpreted as two groups of three 8th notes, 
>> which also can be written as two triplets. However, one can also have the 
>> 2+2+2 beaming, in which case it cannot be reduced to two triplets, instead 
>> it is a single one.
>> 
>> So, in LilyPond, I think would be more natural to have a local beatStructure 
>> where one can indicate different pattern like (6), (3 3), (2 2 2), etc.
>> 
>>>>> Generally speaking a tuplet should be treated according to the 
>>>>> visible/generic/unscaled durations of the content while the remaining 
>>>>> parts of the measure simply ignore it, i.e. pick up at their usual Moment 
>>>>> after the tuplet.
>>>> Indeed, the beaming is as if the tuplet group did not exist but with a 
>>>> local beatStructure, taking up the amount notation space as indicated by 
>>>> the tuplet total time.
>>> This local beatStructure can be inferred from the tuplet definition. If the 
>>> tuplet is \tuplet 3/2 4 (as in my initial example) the resulting local 
>>> beatStructure is:
>>> - baseMoment 1/4 / 2 = 1/8
>>> - beatStructure #'(3)
>>> A single tuplet always has such an unary beatStructure whose baseMoment is 
>>> derived from the tuplet denominator and span, and whose repetition 
>>> (beatStructure entry) is the tuplet numerator.
>> This is just an interpretation for standard CPP music. One can other 
>> patterns as well, if one so like, and that is the case to irregular tuplets, 
>> say a quintuplet could be (5), (2 3) or (3 2), just as for measures.
> 
> This is something I hadn't thought of but that makes sense when thinking 
> about it. I would have seen triplets always as 3*1 and quintuplets always 
> 5*1, and I'd said a sextuplet *is* another way of writing two triplets.  But 
> of course it would be an unrealistic limitation to restrict LilyPond to that.

Hindemith suggest to add the beaming explicitly for such patterns such as 
2+2+2, but as LilyPond does it automatically, one would have to have a local 
beatStructure. 

> So my current understanding is:
> 
> * A tuplet should be treated like a "local measure" with a local
>   "beatStructure"

It is more complicated: One might also have a meter with a tuplet definition, 
and somehow an iterated beatStructure to express that, but it becomes 
complicated to pin it down. So it seems simplest to me to just start with local 
beatStructure in the current format.

> * This measure is isolated from the surrounding beatStructure
>   That means, if a tuplet starts at the second 32th note of a measure,
>   or at the third quaver of a nested tuplet within a triplet, it will
>   get its regular local beatStructure, and its beaming and beam
>   divisions are totally unrelated to where the stems occur in absolute
>   time.

Syncopated tuplets seem rare, so I think they should either have their own 
local beaming, or one will have to break them up and use ties if the 
surrounding metric accents should be expressed.

> * The local structure applies to beaming, beam subdivisions, (and more?)
> * The tuplet is divided into a number of base moments that direcctly
>   corresponds to the tuplet numerator. A sextuplet is always divided
>   into six base moments. (This is different from the regular beat
>   structure of a measure where we are free to choose arbitrary base
>   moments.)

Looking into Hindemith, it seems that the standard beaming is always in one, 
i.e. (6) etc. He said that that the (6) should be musically interpreted as (3 
3); if one wants (2 2 2) one should do that beaming explicitly. So I think the 
(3 3) pattern could be used if one wants to be explicit in the notation about 
the standard musical interpretation, or if one wants (6) (in one) to be 
contrasted against (3 3) accents.

Since LilyPond can do it automatically, perhaps a (3 3) pattern might be to 
prefer as default, but then those used to (6) might object.

> * Like with the existing beatStructure there is a default grouping of
>   base moments into beats per numerator (3, 5, 7 are not grouped by
>   default, 6 is (3 3), 12 is (3 3 3 3)) but that can be overridden by
>   the user.

So in Hindemith, they are all beamed in one, as (3), (5), (6), (7), etc, only 
that (6) has a different musical interpretation than in one.

>>> Multiple identical tuplets can either be considered as sequential elements 
>>> or as a larger "local measure":
>>> 
>>> \tuplet 3/2 4 {
>>>   c8 c c c c c
>>> }
>>> 
>>> can also be seen as
>>> - baseMoment 1/8
>>> - beatStructure #'(3 3)
>> I think suffices to implement beaming for full tuplet groups, each treated 
>> as a separate entity with its own beatStructure. Other things could be 
>> implemented later if so wanted, but for a start, it might just be 
>> complication.
>> 
> 
> What I was talking about is not a question about features but about how to 
> handle the material as efficiently as possible. The most straightforward way 
> would probably be to treat every single tuplet as a single local beat 
> structure. But it might be more efficient to deal with consecutive equal 
> tuplets as one single entity. But I'm not clear about that yet.

So I think LilyPond here jumps out of the beaming model. So for 4/4 + 1/12 one 
would need it to be expressed as tuplet something plus a beatStructure. 
Something to think about.