Re: Automatic beaming fails with tuplets

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

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

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