Changing velocity of one note also changes the velocity for notes sharing a beam

[NicolaRulli]

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

1. create a score
2. create a triplet
3. select a note in "box"/area mode by shift clicking it, or by clicking it then pressing shift right followed by shift left
4. open the playback submenu in the properties panel
5. change the velocity value
6. click on any of the other notes, which you hadn't selected until now
7. 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

[NicolaRulli]

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)

[zacjansheski]

Got it now, looks like the notes need to be beamed together

video1696877519.mp4

[NicolaRulli]

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.

[NicolaRulli]

Update: it's actually ONLY a matter of beam, not of tuplet. The same happens for any two beamed eighth notes, for example.

[cbjeukendrup]

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.

[NicolaRulli]

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.

[NicolaRulli]

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.

[mathesoncalum]

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?

[cbjeukendrup]

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.

[bkunda]

Agreed. At least conceptually, beams don't trigger playback events – but noteheads do.

[Jojo-Schmitz]

Apparently a regression vs. Mu3