I think AudioProcessor::getLatencySamples() should be made a virtual function, and VSTPluginInstance::getLatencySamples() should look like this:

int VSTPluginInstance::getLatencySamples() const noexcept { return effect->initialDelay; }
Because there are some plugins that change their latency when you twist their knobs. Example VST: IL Maximus.


Well that’d make sure that getLatencySamples always returns an up-to-date value, but that wouldn’t really make much difference. Hosts can’t adapt very easily to dynamic latency, and will probably only check the getLatencySamples value when they are told that a plugin’s properties have changed. Wouldn’t a better approach be to catch the ioChanged callback and then call setLatencySamples to update the value?


That would work as well. Another problem: How does the host know that the latency of a plugin has changed? For the moment, I’m polling all the time, and checking if the latency has changed for any plugin, but it would be better if the AudioProcessor just told the host that the latency changed.


One could maybe just call AudioProcessorListener::audioProcessorChanged() after receiving audioMasterIOChanged?


Yes, that sounds like a good idea, thanks!


In fact, I think it just needs to do this:

case audioMasterIOChanged: setLatencySamples (effect->initialDelay); break;


Indeed, even better.


What about AU plugins hosting, do we also need some code being added, or is it ok there?