Dragging the ends of trills causes measures to move around erratically

• Jul 12, 2021 - 06:56
Reported version
3.6
Type
Functional
Frequency
Once
Severity
S3 - Major
Reproducibility
Always
Status
closed
Regression
No
Workaround
No
Project
MuseScore

1) Select one of the last two trills in the linked score
2) Click and drag the end of the trill left and right
The measures in the score rearrange themselves erratically, making it impossible to position the end of the trill where you want it. A work around is to copy the measure into a different score, adjust it there, and copy it back.

edit:
I just noticed that this seems to only happen because I have a hidden staff at the top of my score.
(I added a new staff to the score, right clicked on it, clicked "Staff/Part Properties...", and changed "Hide When Empty" to "Always")
I was able to reproduce it on a different score by adding a hidden staff, then adding notes until the measures could rearrange themselves.

Attachment Size
trill-bug.mscz 20.15 KB

Comments

• Jul 12, 2021 - 07:08

Not sure if related but you can easily make MuseScore crash by dragging the end of basically any line towards the top of the page, investigating now (so far it doesn't seem to be related, that's actually a relatively easy problem to fix anyway).
Adjusting any of the trills in the attached score causes redraw/layout issues that shouldn't happen. The problem still exists in v4.0 too.

Reply

• Jul 12, 2021 - 07:59

As a workaround, and as a clue that might help track down the bug, it doesn't happen when using the keyboard arrows to adjust the grips.
But it is fascinating (and odd) that it only happens when you have hidden staves - showing the hidden staff also allows adjusting with mouse just fine. And the problem still occurs if both the empty staves are hidden.

Reply

• Jul 12, 2021 - 12:31

Made some progress figuring this out but it's a tough one - basically the hidden staff has an instrument name that it initially uses to calculate the left margin, but once it's determined what measures can fit on that system, it might end up hiding that staff on that system, which would make that margin calculation incorrect.
I don't know exactly why this doesn't trigger other problems TBH, or why it causes such erratic behaviour while moving the mouse - it's just that sometimes before laying out that system it seems to think the staff with the instrument name should be invisible to start with, whereas other times it doesn't know yet.
BTW removing the key signature change prevents the problem occurring too, again, no idea why!

Reply

• Jul 12, 2021 - 22:18

Ok, so when this is first laid out after loading, it seems to think measure 26 can't fit on the previous system. But if you make almost any change then undo, it changes its mind! And stranger, if you save the score, then reload, it goes back to the previous layout.
This sort of makes sense - when it first loads the score it doesn't know ahead of time whether the staff with the instrument name will be shown or not, so assumes it is, and allows room for the instrument name. With this, measure 26 can't fit into the system, so is moved to the next system. After that point it determines that the staff with the instrument name is in fact empty and should be hidden.
But when it recalculates the layout at a later point it has this cached information about the staff being hidden and doesn't use the instrument name in determining how many measures can fit on the system.

I'm actually not exactly sure what the correct algorithm should be here, but the simpler logic is definitely the case when it first opens the score, and must allow room for the instrument name. In principle after determining a staff was empty and thus hidden it could recalculate the layout, but then that might bring a non-empty measure onto that staff and mean it shouldn't be hidden after all!

Reply