> On 11 Nov 2017, at 21:32, Urs Liska <li...@openlilylib.org> 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. _______________________________________________ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
