Enabling instrument envelopes causes unwanted piano roll triggering

[StakeoutPunch]

OS: Windows 10
Version: Public 1.2 RC3
Steps to reproduce:

1. Open an instrument to the env/lfo tab and enable any envelope (volume, cutoff, or reso).
2. Open instrument in the piano roll and place down any chord you wish.
3. Select one note using CTRL+drag or select tool.
4. Drag the note's volume slider around. This will cause every note occurring at the same timeline position in the piano roll to trigger every time the slider is moved.

[musikBear]

confirmed win 32 xp

[StakeoutPunch]

More information on bug: Clicking the volume slider and moving the cursor to the side (out of vertical alignment) will not trigger all the notes when changing the slider value.

[SecondFlight]

I can't reproduce on master, can someone confirm this before I close?

[zonkmachine]

It's doesn't seem to be as prominent in master as in stable-1.2 but it still happens.

4. Drag the note's volume slider around. This will cause every note occurring at the same timeline position in the piano roll to trigger every time the slider is moved.

Also affects panning.

[musikBear]

Very important that a fix, does not remove chords being played, if mouse is being left-pressed on the column-end.

Pressing this area, is the only way to hear a chord, without playback!

[zonkmachine]

Bisected. The commit where this triggering started is f403299
@tresf

[tresf]

Bisected. The commit where this triggering started is f403299
@tresf

Nice find. I don't have time to own this one, so marking it as good first issue and hoping someone else does.

[zonkmachine]

I don't see at a first glance why the triggering affects only sounds with envelope. I think the real bug could be somewhere else and this commit just made it surface.

[zonkmachine]

I think I've fixed the issue in #5271

[zonkmachine]

Q - I have selected one note in the chord to the left. I now get a bit naughty and try and move the fader for the note to the right. What should the outcome be?

[zonkmachine]

In 1.1.3 when you have an active selection, the other notes faders are unresponsive. In 1.2.0 when you try and move another fader than of the selected note you will trigger that note but the selection fader will move instead. I see no use case for this behavior and am looking into a fix for it.

[Spekular]

I think only the actively selected notes should have editable velocities. Imagine you have a strummed chord, so the notes are delayed by 1/64th or something. If you select one note in the chord to edit its velocity, you don't want the other notes to change. This should also be simpler to code than making an exception for notes at a different position. So in your example, the velocity for the note on the right should stay fixed.

One could argue that notes that are far enough from the selection should be editable, but this could end up being confusing, and you would need to take zoom into account.

[zonkmachine]

I think only the actively selected notes should have editable velocities.

I agree and this is actually how it works in master now so this part seem fixed already.
Edit: No, the issue is still there...

This should also be simpler to code than making an exception for notes at a different position.

Yes.

[zonkmachine]

So in your example, the velocity for the note on the right should stay fixed.

And this is how it works today but the sound still plays. It just gets a bit confusing because the fader of the selection moves. It's a bit of an edge case though and the current behavior is acceptable to me. #5271 should be merged.

[zonkmachine]

Closed in #5271