Holding down Alt/Control/Shift/APPLE/TAB "quick changes" some Orange parameters but not all?

[sense-amr]

Holding down Alt or Shift or Control will enable what i can only call a "quick edit" mode .. for Most of the orange parameters.. It seems to allow quick editing by simply hovering the mouse over the paramater or desired button to be tweaked..

This is good except for two things..
It's not consistently available over all parameters.

It can easily result in undesired parameter tweaks.. with the user not knowing where they came from.

In my testing.
On Windows 10
Ableton Live/Fruity Loops/Bitwig

it works on.. all orange boxes and parameters.. and also Mixer filter assignments (the green switches).
EXCEPT FOR the following:

SCENE A/B
Any of the LFO types
Oscillator 1 2 3
Digital/Analog (on envelopes)

Suggest Fix ..for Holding down Shift key only .. as to not interfere with potential Alt Tab activity on PC .. as this is where i initiallly found out about this (feature/bug?)

Also Suggest some kind of display showing user is in that mode when Shift is held down.. so as to not get confused about what happened to any of the parameters when just moving the mouse around, with Shift held..

[baconpaul]

I have confirmed this yup indeed happens.

For some details for when someone goes and cleans it up (which I agree they should, but I'm not going to get to this evening)

1. CHSwitch2 (which is the class here almost everywhere except the lfo type probably) has an optional constructor argument dragable = false.
2. In onMouseMoved the onDragHandler resets value if dragable & buttons != 0. If you change that at line 66 to dragable && ( buttons & kShift ) it would do the shift-only thing you mention on the ones that are on

So the fix here is

1. Visit the rest of the non working chswitches where they are constructed and set dragable to true
2. modify the above condition
3. build and test mac and win vst2 and au at least

That's not much work but more work than I am going to do on this issue this evening, so leave notes either for a future me, or for a future someone else if someone else wants to! I'll also tag this 'good first issue'.

[sense-amr]

cool ill try and give it a go !

[sense-amr]

ok ive replaced ALL instances of refering to (kAlt | kShift | kControl | kApple) keys with
( buttons & kShift )
if (listener && buttons & (buttons & kShift))
in ChSwitch2 and ChSwitchControl

This results in the "quick edit" happening only when Shift is held down.. ALT CONTROL and TAB are now not active for this function

[sense-amr]

Edited code.. for Shift Key only FIX..

}
CMouseEventResult CHSwitch2::onMouseMoved(CPoint& where, const CButtonState& buttons)
{

• if (dragable && buttons != 0)

• if (dragable && buttons & kShift)

[sense-amr]

OK @baconpaul i noticed now that .. the changing of those parameters affected .. only works .. WHEN holding shift down now .. which means somehow i broke it ? even in the cleanest one line changed version ?

[baconpaul]

Yeah this is the most amazing thing.

in mouseOver changing buttons !=0 to buttons & kShift means onMouseUp behaves differently.

I suspect something odd in the operator overloads on CButtonState is mutating the internal state on the check (which is a bug in CButtonState). This one is tricky to debug. Leave it open for now.

[sense-amr]

curiouser and curiouser!

[baconpaul]

Sigh - so I checked quickly to see if this weird behavior went away with the new vst3sdk and it didn't so still something deep and scary to debug on this issue. Back to the back burner with this one. Too bad I was hoping it would be easy now we did that upgrade!

[baconpaul]

Remember this old gem?
Well I think it is related to #579 and not returning the right value when we handle the event under change of condition.
Just putting this here for my memory.

[baconpaul]

Huh OK it wasn't return value but I figured out what it was. Pul Request coming in.

[baconpaul]

(And: it was me not understanding the API)