UI parameter automation time compensation

A VST 3 host has to send all automated parameters to the edit controller. This allows for time-compensating them, so the UI is in sync with what you hear. This can be a value the audio processor processed half a second ago, for example.

Unfortunately, many plugins update their edit controller themselves, so its UI knobs show the values at the time the audio processor processed the data. If the host sends time-compensated values the UI knobs will jump between the processor time and the UI time. This looks bad, so I’m more or less forced to remove the time compensation from my host.

Perhaps it would be a good idea to add a way for the plugin to say “Sorry, I still update the UI myself, please don’t send parameters at all, or at least don’t time-compensate them” or “I do this correctly, please send time-compensated parameter values”?

Which plug-ins are you talking about? In Cubase we always compensate parameter changes and we never heard about such an issue with plug-ins.

Thanks for your reply.

Schope, Surge, FuzzPlus3, OldSkoolVerb…

Ah OK. Now I see.
They all implement the VST3 spec in a wrong way as they don’t have a different representation of their state in the realtime thread and the UI.

I don’t know which host you’re talking about, but maybe you can make this an option per plug-in as plug-ins who do this right will look as poor as the ones who do it wrong if you stop to compensate for all plug-ins.
I will discuss this internally within Steinberg how we will deal with such plug-ins.

Thanks for bringing this to our attention.

Thank for looking into this.

Good point, I didn’t think of that.

On a related note:
I think there’s a similar issue in the opposite direction: the host has to pass parameters from performEdit to the audio processor. Many plugins do this themselves. The two values may arrive in two different processing blocks, which can cause jumps in the parameter value. This will probably go unnoticed, but still.

In both directions the host is doing something that’s useless and only makes things worse AFAICS.
It would be nice if a plugin could tell the host it doesn’t need the host to do this.

We had a first discussion and we will as a first result add a test to our validation suite which will check the plug-ins for this behaviour and will flag the plug-ins as non-conforming.
Your idea about an interface where the plug-in tells the host that it does not want this behaviour will also only work if the plug-in developers are aware of their issue and implement this interface. I think most of them just don’t know that they are doing it wrong. But we will be more discussing this in the coming weeks internally.

1 Like

What about single component effects - they probably need to be an exception here?
How does the host detect whether a plug-in is a single component effect?

I don’t think that single component effects should be treated as exception. It’s just very bad design of the plug-ins to not show the state the user is currently listening to. It would look like a host issue if you have an automation of a plug-in and this automation is shown half a second before you hear the automation.

VST2/AU plugins have ignored ‘presentation latency’ properties like forever. The VST3 versions of these plugins are likely the same code (and same design) with a different plugin API. I doubt that’s going to change anytime soon.

But then I’m not a plugin developer, so what do I know? :wink: