fix #222181, fix #269998: Dotted rhythms within tuplets

[mattmcclinch]

See issue 269998.

[MarcSabatella]

The basic idea is sound, but I predict it won't work if there are "holes" in the tuplet anywhere to the right of the selected note. By "holes" I am referring to the fact that voices >1, we allow the deletion of rests. Which also leads to problems like https://musescore.org/en/node/270043. And a possible solution there will be to disallow these holes within tuplets in the future, and maybe fix existing scores by filling them with invisible rests on read, so maybe this won't be end up being an issue. But we probably need to consider these together.

[mattmcclinch]

What if this:

Fraction rest = tuplet->elementsDuration();

were changed to this:

Fraction rest = tuplet->baseLen().fraction() * tuplet->ratio().numerator();

That would make it the same way I calculated Fraction f in Score::setRest().

[mattmcclinch]

No, that's no good. Holes to the left of the selected note would cause problems.

[mattmcclinch]

Doesn't version 3.0 solve the problems with holes with the _gap property in class Rest?

[MarcSabatella]

Probably so. Haven't really looked into that.

[mattmcclinch]

If I understand correctly, the issue with this is that once a hole is created inside a tuplet, there will be no way to "fill in" the hole by lengthening the duration of the previous elements. And the real problem is that the user was allowed to create a hole in the tuplet in the first place. I agree with you and anyone else who says that deleting rests within tuplets simply should not be allowed. Rests within tuplets are like rests in voice 1. They are required for completeness.

[lasconic]

With this PR and with #3549 we solve all problems for newly created files in MuseScore 2.2. Unfortunately we don't solve import (in particular MusicXML) or old MuseScore 2 files. I think I will merge them both and then let's roll an RC.

[mattmcclinch]

I have done some work on correcting tuplets with missing elements when loading from a file, and it actually works pretty well. The tricky part is figuring out whether to insert a hidden rest into the tuplet before the first known element, and if so, what the duration of that rest should be. This is only tricky because the size of the gaps to either side of the known elements of the tuplet may be larger than what is required for the missing elements. Filling in gaps in the middle of the tuplet is not a problem. Care should be taken to ensure that the tuplet starts on a sensible tick, and that the elements of the tuplet are of a sensible duration. Once we know where the tuplet really starts, the rest (no pun intended) is easy.

I believe a reasonable guess for the start of the tuplet is something like

expectedTick = elements().first()->tick() - elements().first()->tick() % duration().ticks();

Then, if expectedTick == elements().first()->tick(), we should probably not insert an element before elements.first(), and no more guessing is required. If they are not equal, we need to take into account the first available tick and the number of ticks required (inside the tuplet) for the duration of the missing elements. This is easily done. If we can still use expectedTick for the start of the tuplet, we do so.

Of course, a tuplet can be created that starts on a tick that is not divisible by the duration of the tuplet. If such a tuplet is encountered that needs correction, this may figure an earlier start tick for the tuplet, giving the first and last elements a weird duration. But how often is that going to happen?