Dotted rhythms within tuplets

• Mar 4, 2018 - 16:57
Reported version
3.0
Type
Functional
Severity
S4 - Minor
Status
closed
Project
MuseScore

Can't make three dotted eight rests within nontuplet.

Steps:
1) Select a measure of 4/4, make it two half notes.
2) Use CTRL+9 to make a nontuplet.
3) When dividing it into 3 equal beats, only the first two beats can be turned into dotted eighth notes.

This problem comes up with 16th note nontuplets and 64th note nontuplets, but not with eighth note nontuplets or 32nd-note nontuplets.

Comments

• Mar 5, 2018 - 18:01

See also #222181: Changing the duration of rests doesn't work consistent inside tuplets via toolbar. Different specifics, but the same basic issue - unable to lengthen something within a tuplet. Presumably due to roundoff error - we're probably calculating the necessary length as being one tick too long. Similarly, you can't change second-to-last sixteenth of the nine-tuplet into an eighth.

Would be interesting to see if the pending tuplet change has any bearing on this, but I'm guessing not, especially since master shows the same result.

Reply

• Mar 5, 2018 - 18:17

When you create a tuplet such as this, exit note entry mode then change durations of the rests, you get the same result as if you start with a 1/2 note and create a tuplet. The final rest cannot be incorporated into a previous rest (such as an 8th rest or dotted 8th rest in this example).

Reply

• Mar 5, 2018 - 18:26

For 2.2 at least, the relevant code is in Score::splitGapToMeasureBoundaires(). If I try selecting the second-to-last sixteenth of the nine-tuplet and changing the duration to eighth, we calculate - based on the current tick position of 749, which is only approximate since 9 doesn't divide into the total tuplet length of 960 - that there are 211 ticks left in the tuplet. But there are really, hmm, 960/9 * 2 = 213.33. We then go through the motions of converting 211 to a fraction and doing the "right" thing by comparing fractions rather than ticks. But since the initial tick calculation is wrong, so is the resulting fraction (we get a remainder of 1899/15360, which is shy of 1/8 in the same way 211 is shy of 213.33.

These tick calculations are killing us, and I know the plan is for this to be revisited in 3.0. I am not sure what the best solution is for now. Elsewhere we use a "fudge factor" to allow comparisons based on ticks to succeed even if off by a little. But here, we are actually comparing fractions, not ticks. I hate to build a fudge factor into fraction comparisons. Maybe better to actually change this one into a tick calculation and do the fudging there? Because based on our current implementation, there really isn't a foolproof way I know of to get at the information that would say "this is the second-to-last sixteenth of a nine-tuplet" rather than "this is tick 749".

Reply

• Mar 8, 2018 - 18:31
Status (old) active ⇒ patch (code needs review)
Status active ⇒  

As kuwitt points out in #222181, it is possible to create the third dotted eighth rest with the "0" key. But turning it back into an eighth rest (removing the dot) results in another rounding error with the remainder of the tuplet. The relevant code is in Score::setRest(). I believe that I have found a solution to the problem by removing ticks from the calculation. The patch for 2.2 can be found here.

Reply