The selection is lost when changing the length of the rest of an empty measure

• Apr 9, 2022 - 10:44
Reported version
Ergonomical (UX)
S4 - Minor

Steps :
1) enter some notes in a measure of any staff
2) select an empty measure of any staff (select the measure not the rest of that measure)
3) press one of the duration key (e.g. "5" to split the measure in two Half rests)
4) start entering some notes by pressing a note key (e.g. "A" to enter a A)

The first of the two new Half rest gets transformed into a A note

The last note that was edited (in whichever measure or staff) gets transformed into a A



I can't reproduce this in MU4, not exactly. The selection is still lost, but the algorithm used to determine where note input should start if there is no selection appears to favor the recently-selected measure.

Frequency Few Many

I believe this following issue has the same cause, so I am adding it here rather than making a separate post. Let me know if I should instead make another post.
As this is impacting more behaviours than the original post I have changed the frequency to 'many'. Please revert this if it is not the correct procedure.

When changing the length of notes in multiple voices, the selection is lost after every change and the notes must be reselected.

Steps to recreate:
in the attached example score,
select all whole notes (click top note, shift-click bottom note)
change the length to a quarter note (e.g. press 5)
change the length to a dotted quarter note (e.g. press period)

Expected behaviour:
Selected notes change to quarter notes, remain selected and then to dotted quarter notes which remain selected.

Actual behaviour:
The selected notes change to quarter notes, the selection is cancelled, pressing period then enters 'Notation mode' without making any change to the score.

The workaround is to do the selection after every change
This type of work comes up for me when revising choral scores, which often have homophonic parts that I want to change, e.g. to notate breaks for breaths.
Up until the current version this has worked as expected and the erroneous behaviour is disruptive to the flow of composing and arranging for me

macOS 10.15,7 Arch.: x86_64, MuseScore version (64-bit):, revision: 3224f34

Attachment Size
error_example.mscz 5.58 KB
Reported version 3.6 4.x-dev

just tested the behaviour in MuseScore Nightly and it is the same as in the stable 3.6.

Bug reporting procedure can be a bit opaque But this may help.

If you are reporting a newly discovered bug then, indeed report the version you experience it in, but with existing reports, only change the version if you can demonstrate the bug in an earlier version to make the hunt easier.