Re: Automatic beaming fails with tuplets

[Urs Liska]

Hello Hans,

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


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).

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

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

So my current understanding is:

 * A tuplet should be treated like a "local measure" with a local
   "beatStructure"
 * 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.
 * 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.)
 * 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.

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

Urs