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â?
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.
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.
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?
