The selection is lost when changing the length of the rest of an empty measure
Reported version
3.6
Type
Ergonomical (UX)
Frequency
Many
Severity
S4 - Minor
Reproducibility
Always
Status
active
Regression
No
Workaround
Yes
Project
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)
Expected:
The first of the two new Half rest gets transformed into a A note
Actual:
The last note that was edited (in whichever measure or staff) gets transformed into a A
Comments
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.
Workaround: rather then selecting the entire measure, select (click) just the rest
Came up again in #332969: Inserting a rest makes the insert point jump
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.
Issue:
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.
Impact:
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
System:
macOS 10.15,7 Arch.: x86_64, MuseScore version (64-bit): 3.6.2.548020600, revision: 3224f34
In reply to I believe this following… by bosworthdk
.
just tested the behaviour in MuseScore 4.0.0.1053140094 Nightly and it is the same as in the stable 3.6.
In reply to just tested the behaviour in… by bosworthdk
The first report of the problem is still version 3.6 though. If you change the reported version to to a later one, someone looking for a code change between v3.6.2 and v4 that might be the cause of the problem will be looking in the wrong place.
In reply to The first report of the… by SteveBlower
thank you. I thought I was reporting the error to also be present in 4.x 👍
Bug reporting procedure can be a bit opaque But this may help. https://musescore.org/en/node/309537
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.