I don't want to guess too much exactly what you want to do, but I suggest you think about the behavior, and whether it's the param or the control that you want to return. Typically, we move a control to change a param, but when we aren't actively moving the control, and the param is changing, the param is changing the control (as it does with automation).

This sort of things are pretty easy to manage if you have a "heartbeat" thread, where you can execute some code regularly at a lower priority than the audio thread. Where you force the param back to the default value on mouseUp, you'd start a state machine to perform the change incrementally. There's a idle (separate from the GUI idle) handler in IPlug that seems appropriate, but it's not implemented across all plugin types (maybe not at all, but I think I recall it might be with VST). I think you need to create your own thread, unless someone else knows otherwise.

Ok, needing to create a seperate thread is what I've gathered because my first approach was trying to increment/decrement the param directly in small steps in OnMouseUp() in a while... loop which froze the whole GUI (rather obviously).

Just an idea, but you could also "simulate" the lower-priority thread from inside the audio thread, by only running it every N samples. Of course that would waste some CPU cycles in the audio thread, but it might be simpler.

if this is just a visual effect - an animation, you don't need another thread, and you definitely don't need to use the audio thread.

create a member variable mCountdown in your IControl, initialise it to 0 and on MouseUp/whatever set it to a certain number of frames e.g., if IGraphics FPS = 25 (the default) and you want the animation to continue for 1 sec, you would set mCountdown to 25.

Well, I was alluding to this when I said "I don't want to guess too much what exactly you want to do", but I assumed he most likely wanted the parameter to follow the smoothed control...but not sure...

Quote:

Originally Posted by Tale

Just an idea, but you could also "simulate" the lower-priority thread from inside the audio thread, by only running it every N samples.

I don't think that would be a good place to send a parameter change, no?

Problem is now I can't hold the fader up with the mouse anymore (which also should be possible), because it starts the animation as soon as it detects 'dirty' (i.e. immediately after touching) I think. You can see this in the gif, mouse button is still pressed while fader returns which it shouldn't.

I don't think that would be a good place to send a parameter change, no?

I think that depends on the situation, not?

Anyway, I generate noise and play an animation when my plug-in is in demo mode, and I control this from within the audio thread. While the noise is playing I update a timer value, and let the control know via SetValueFromPlug(). Works for me.

Problem is now I can't hold the fader up with the mouse anymore (which also should be possible), because it starts the animation as soon as it detects 'dirty' (i.e. immediately after touching) I think. You can see this in the gif, mouse button is still pressed while fader returns which it shouldn't.

You should be able to handle that easily with OnMouseUp(). Just start your animation only if e.g. a bool was set true in there.

Anyway, I generate noise and play an animation when my plug-in is in demo mode, and I control this from within the audio thread. While the noise is playing I update a timer value, and let the control know via SetValueFromPlug(). Works for me.

Well, like I said, he's looking to set the parameter, not just the control. When I suggesting the audio thread wouldn't be a good place, it was in regards to setting a parameter.