Am 11.11.2017 um 15:04 schrieb David Kastrup:
Urs Liska <li...@openlilylib.org> writes:I think the attached beaming is wrong. In \relative c'' { \tuplet 3/2 { r4 c32 c c c c c c c r4 } r2 } The beam should *not* be broken IMO. I think the auto-beam-engraver finds the fifth 32th note to be sitting on the beat and therefore breaks the beam. Obviously tuplets have to be treated specially.How? I'm sort-of comfortable with how we deal with beaming in graces (basically beam across the whole group unless interrupted).
Yes, I also think this is adequate behaviour for beamed grace notes (how should an algorithm decide if any division is intended in a grace note group?).
Not sure this will work equally well with tuplets, and particularly it does not answer the question of how to do subdivisions if they are present as well.
I only have a preliminary answer to that, although that is based on having contemplated the issue for two days now. 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.
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.
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.
_______________________________________________ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
