Dotted tuplet has incorrect duration after save/reload

• Nov 30, 2018 - 17:21
Reported version
3.0
Type
Functional
Frequency
Once
Severity
S2 - Critical
Reproducibility
Always
Status
closed
Regression
No
Workaround
No
Project
MuseScore

Load mtest/guitarpro/dotted-tuplets.gp5 into MuseScore. It will look like this:
dotted-tuplet.png
The baseLen of the tuplet is a dotted eighth. The duration of the tuplet is equal to a dotted quarter. The 1/16th note at the end is outside the tuplet; it is just beamed together with the tuplet.

Saving the score as MSCX results in mtest/guitarpro/dotted-tuplets.gp5-ref.mscx, which when loaded into MuseScore looks like this:
dotted-tuplet-ref.png
The baseLen of the tuplet has been changed to an eighth (without a dot). The duration of the tuplet is now only equal to a quarter. A rest has been created where the third note should be. The rest comes after the tuplet, but the tuplet bracket is drawn across the rest.

The reason for this is that any dots in a tuplet's baseLen are lost when the baseLen is written. This can be solved by writing out the number of dots in the baseLen if it is greater than 0.

Comments

• Nov 30, 2018 - 20:31

Trying to create this tuplet from scratch, I run into difficulties as well. First, I set up my measure like this:
dotted-quarter.png
If I then press Ctrl+3, MuseScore decides that I want a 3:3 tuplet:
3-3-triplet.png
If I instead go to Add->Tuplets->Other... and choose a 3/2 ratio, I get this:
3-2-triplet.png
This tuplet has a duration of 3/8, a ratio of 3/2, but a baseLen of 1/16 when it should be 3/16. This causes a problem when I try to copy it into another measure:
copied-tuplet.png

Reply

• Nov 30, 2018 - 20:46

In MuseScore::tupletDialog() it looks like we are going out of our way to discard the numerator of the baseLen fraction for no reason that I can see. If we just use f as it is, the problem goes away. Of course, this solution depends on the changes I made to Tuplet::read() and Tuplet::write().

Reply

• Dec 1, 2018 - 04:42

Okay, I see what happened. Before this commit, with the way f was calculated, it was necessary to strip away the numerator when setting the baseLen of the tuplet. But with the new way f is calculated, f is already the correct value for the baseLen.

Reply