[MU4 Issue] Offsets behave erratically when modified

[oktophonie]

Describe the bug

box-220908-1341-14.mp4

When adjusting offsets, it seems the initial origin point is lost and the item jumps to another position. Thereafter, further offset adjustments will be relative to that point, and even resetting the offsets to their original values (via the Properties panel) does not always correct this. Ctrl+R does, however.

[MarcSabatella]

I can tell you exactly why this is happening - it's exactly the same in MU3 - but not what the "right" thing to do about it is.

The real default position of the element is rather lower than what you are seeing here. It's only autoplace that is pushing it as high as it is, to avoid the fermata. When you force the text down to collide with the fermata, MuseScore automatically decreases the "minimum distance" (making it negative) to allow the collision. When you reset the offset, the minimum distance remains at the negative value, so the collision remains allowed. In MU3 it's marginally more obvious what is happening because minimum distance is right next to offset in the Inspector, but you have to know what it is and what it's for. Ctrl+R resets both offset and minimum distance, which is why the text jumps back up to avoid the fermata again.

This is "by design" but certainly, it's possible to revisit. One obvious possibility is, since adjusting the offset automatically adjusts minimum distance, resetting offset could also reset minimum distance.

I should mention that the original 3.0 implementation of autoplace would simply not have allowed you to move the text onto the fermata without disabling it. The screams of pain from users were pretty intense, which is why we ended up implementing this scheme of automatically reducing minimum distance to allow you to force collisions without needing to explicitly disable autoplace. It works well enough overall but definitely has lots of little quirks like this.

[oktophonie]

So if there is indeed a bug here (and if we don't fancy totally rewriting this system right now - which we certainly don't), is it just that the 'Minimum distance' doesn't update in real time as this happens? (or is that also intentional? MU3 is the same).

And how about this:

box-220908-1423-37.mp4

It seems unclear to me why the text suddenly jumps all the way under the fermata rather than overlapping it.

[MarcSabatella]

I'm having trouble understanding how the offset got set to 2.5 in the first place - positive offsets mean lower than default position, so the situation you are showing at start shouldn't normally be possible. Any action that set the offset to 2.5 should have also set minimum distance to a negative value so the text would already have been on the staff.

Aside from that, though, the behavior in the original scenario in the first video is not a bug, but yes, the minimum distance should be updating in real time, and that is indeed a bug. That happen in MU3 due to a design restriction in the Inspector that prevented fields from being updated as you changed other fields (which is also the source of some other Inspector-related bugs). I'd like to think the new Properties panel would allow this to finally be fixed.

[oktophonie]

The plot thickens. 2.5 is the Y-offset for stave text below, but this was definitely set to above. I'll keep an eye on this to see if that ever happens again.

[MarcSabatella]

Believable for sure, perhaps even as part of the same bug where an update to one field does not immediately show the corresponding change in another.

[rgreen5]

(BTW, the video files have somehow got corrupted and won't play back.)

Similar to #11637?

[oktophonie]

Closing this one; will spin off more targeted issues as I pin them down.