[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Automatic beaming fails with tuplets
From: |
Hans Åberg |
Subject: |
Re: Automatic beaming fails with tuplets |
Date: |
Sat, 11 Nov 2017 22:11:46 +0100 |
> 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.