Thread: AAX and knobs
View Single Post
Old 11-18-2017, 01:21 PM   #28
earlevel
Human being with feelings
 
Join Date: Dec 2015
Posts: 331
Default

At the risk of sounding insistent, I'll try to recap the important points:

1) If you don't fix the fundamental AAX parameter problems, you will at some point have automation quirks, if you don't already.

2) If you fix the double-call of OnParamChange via AAX / Pro Tools, compared to other plugins, you won't have to do funny things elsewhere to stop its effects due to double calls.

3) I think the best way to handle discrete steps is as I described. It's not a hack—"it works a lot better when I do this"—there is a logical reason it is more natural.

The first two are about fixing AAX, which is a must if you support AAX. This thread is about different knob behaviors with AAX, and mostly covers hacks to get acceptable behavior. Why not fix AAX? (I understand that part of the thread is not necessarily isolated to AAX, but that's covered in my point 3, universal for all plugin types.)

I don't know what everyone is using, but in the current wdl-ol master, for bool/enum parameter types, IPlugAAX calls AAX_CLinearTaperDelegate—it should be AAX_CStateTaperDelegate, and I think you can understand that from the names.

For #2, I already mentioned PT's different behavior that requires an override to not call OnParamChange twice. It's a simple fix, better than adding code to guard against it in individual controls.

I also rewrote GetDisplayForHost, which was a mess (yes I could have removed sprintf, wasn't trying to save the world here). I think that it affected automation display in PT in some cases, IIRC, but caused problems in general anyway.

See my long-standing pull request for wdl-ol. The commits are independent.

As for #3, you can do your control any way you want, but please take the time to understand what I'm doing. It's not a hack to make things acceptable, it's a logical way for such controls to work, and it behaves exactly like a similarly-stepped GUI control that you'd been using for decades behaves—the pop-up menu.

Let's say you want a knob with five step positions. A natural behavior is to have it switch at a certain drag distance—say, 1 cm, for each next step. Mousedown on the control (the controls saves the current x,y and value—"the anchor"), drag—onmousedrag gets called repeatedly, each time looking at the current x or y and seeing how far it has moved from the anchor, and changing the value/SetDirty if needed, pinned to min/max. On mouseup, you don't need to do anything. Same as rolling down a menu, going too far, going back. The regular knob mouse behavior is wrong for this type of control because it's not anchored on the original click, so the switching is not consistent. You don't notice on continuous controls, but it's a killer with limited steps.
earlevel is offline   Reply With Quote