If an entire tuplet is moved to a different staff, the number collision algorithm doesn't work properly - it will avoid the original staff when it doesn't need to, and won't avoid the staff it was moved to.
Complications include the fact that the elements we are looking at aren't necessarily notes or rests but could be other tuplets. Which is, I assume, why they are declared as DurationElement rather than ChordRest. And then handling all the various cases of partial moves.
I think the "easy" fix is to disable the staff avoidance if any part of the tuplet is cross-staff.
I think that's a reasonable fix - most cross-staff beams won't need to avoid a staff, since the stems would be pointing toward the original staff (causing the tuplet to be placed above it, away from the staff it was moved to). The only situation I can think of that would result in collision is where the cross-staff pitches are so extreme that the stems (and thus the tuplet number) would be moved within the staff - I think this would be uncommon as clef changes would be used instead.
I may or not be able to get this in today, but I do basically have this fixed. I'm fixing the staff avoidance for the case where both endpoints have been moved, disabling it for the case where one only one has.
I apologize - I haven't been able to contribute much because of exams, and I just happened across this bug when using MS for a project. I do plan on submitting more PRs after my exams are over =)
Comments
FWIW, the relevant code is here:
https://github.com/musescore/MuseScore/blob/master/libmscore/tuplet.cpp…
and
https://github.com/musescore/MuseScore/blob/master/libmscore/tuplet.cpp…
(stem up & down cases)
Complications include the fact that the elements we are looking at aren't necessarily notes or rests but could be other tuplets. Which is, I assume, why they are declared as DurationElement rather than ChordRest. And then handling all the various cases of partial moves.
I think the "easy" fix is to disable the staff avoidance if any part of the tuplet is cross-staff.
I think that's a reasonable fix - most cross-staff beams won't need to avoid a staff, since the stems would be pointing toward the original staff (causing the tuplet to be placed above it, away from the staff it was moved to). The only situation I can think of that would result in collision is where the cross-staff pitches are so extreme that the stems (and thus the tuplet number) would be moved within the staff - I think this would be uncommon as clef changes would be used instead.
You want to give it a shot?
I wouldn't be so sure there won't still be a fair number of collisions, but they can be resolved manually if one wishes.
I may or not be able to get this in today, but I do basically have this fixed. I'm fixing the staff avoidance for the case where both endpoints have been moved, disabling it for the case where one only one has.
https://github.com/musescore/MuseScore/pull/1955
I apologize - I haven't been able to contribute much because of exams, and I just happened across this bug when using MS for a project. I do plan on submitting more PRs after my exams are over =)
Fixed in 8ee6861d34
Automatically closed -- issue fixed for 2 weeks with no activity.