MuseScore
MuseScore copied to clipboard
musescore
Changing velocity of one note also changes the velocity for notes sharing a beam
Issue type
UX/Interaction bug (incorrect behaviour)
Bug description
If using box (shift) selection to change the velocity of one note, all the other notes in the tuplet will also adopt that change.
Steps to reproduce
- create a score
- create a triplet
- select a note in "box"/area mode by shift clicking it, or by clicking it then pressing shift right followed by shift left
- open the playback submenu in the properties panel
- change the velocity value
- click on any of the other notes, which you hadn't selected until now
- check the velocity value: it will be equal to that you have set for the other note, instead of being the default
Screenshots/Screen recordings
No response
MuseScore Version
OS: Windows 10 Version 2009 or later, Arch.: x86_64, MuseScore version (64-bit): 4.2.1-240230937, revision: github-musescore-musescore-d757433
Regression
I don't know
Operating system
Windows 10 home x64
Additional context
No response
Could you possibly share a screen capture of what you are doing? If you make a range selection, all selected notes should change velocity.
I make a range selection of ONE note (or chord, or vertically aligned notes/chords across different staves) and the whole tuplet gets affected, even though only ONE of its elements is selected (in actual user selection, in box size, and in blue highlighting)
I haven't been able to reproduce this. Could you possibly make a screen capture showing the issue?
https://github.com/musescore/MuseScore/assets/69917893/0c7d2900-314d-4c3d-aabf-4c9438daa59e
Got it now, looks like the notes need to be beamed together
https://github.com/musescore/MuseScore/assets/69917893/215dab88-37d6-4ffb-83ba-2e5a65a1b58c
That's an interesting discriminating factor. Next time I encounter a bug on notes beamed together, I'll make sure to check whether it also applies to beamless notes.
Update: it's actually ONLY a matter of beam, not of tuplet. The same happens for any two beamed eighth notes, for example.
Yes, when you select a beam, the Properties panel will pretend you have selected all notes under that beam. That's partially by design, but also has unexpected consequences, like this one.
I just found that the beams also prevent mass-adjustment of Y position, even if all notes on the beam are selected. I'll make a separate issue later if I have time, but this makes me think it's the same underlying problem, and it's probably a regression because I imagine I should have noticed this one earlier (when finnicking with the slash notation cues) if it had been present.
Additional interesting interaction between two bugs: Selecting an area that includes beams will prevent editing the Y position field even thought there may be non-beamed and non-note contents, however changing any of the other fields will still reset all Y positions to default due to the bug that causes all other fields to reset to default upon mass edits to one field, so the beam just disables input in the UI field but it doesn't protect the underlying value from changes from other sources.
Like you say @cbjeukendrup this seems partially by design. My suggestion would be to only apply playback changes to notes whose heads are currently selected. The "trade-off" is that selecting stems/beams only will return a greyed-out playback button (see below) but, to me at least, this actually makes more sense than the current behaviour.
@bkunda any thoughts?
That makes much more sense to me too. When the user selects a beam or stem specifically, they are probably doing so on purpose, and a beam or stem doesn't really seem to have any association with playback.
Agreed. At least conceptually, beams don't trigger playback events – but noteheads do.
