I’m working on a plug-in that can make use of different sound paths, each with a different number of latency samples.
I’m correctly changing the number of latency samples in the AudioProcessor via setLatencySamples (), but that does not seem to be notified to the host.
In particular, I’ve noticed that the callback method getLatencySamples () in the RTAS format is called by the wrapper only once when the plug-in is instantiated, because the host calls GetDelaySamplesLong.
How can I notify to the host (ProTools in particular, but I will need this information for the other formats as well soon) that the latency has changed and (in this case) GetDelaySamplesLong had to be called again?
I’ve not added anything to the wrapper to notify the host of latency changes - I suppose it’s possible, but it’d take a bit of research to find out how each api would handle it.
I’ve sent an email to digidesign support, but they replied that dynamically changing the latency of an RTAS plug-in is not currently possible but it’s on their todo list. This said, it would still be useful to have such feature for the remaining formats.
I have a VST plugin that scans incoming audio for some short time window and then makes a decision based on the results of the calculations done on that window. The plugin is currently implemented with the pure VST and VSTGUI classes, and I am now converting it over to the Juce audio plugin framework.
In my old VST setParameter function, I am doing this for that particular parameter (the parameter determines the window length and thus the introduced latency):
if (index == kVelocityScanTime)
{
setInitialDelay(m_Model.GetParameter(theIndex)*sampleRate);
ioChanged();
}
I would like to know where in AudioProcessor I should do something similar. I guess that would also be in AudioProcessor::setParameter, right?
Questions then:
What is the Juce equivalent to setInitialDelay() and ioChanged()?
What is the expected “sequence of calls” for changing latency due to a parameter change?
Sometimes it is suggested to just declare the plugin’s latency as a fixed latency being the maximum latency that can occur (in my case the maximum value for that window duration parameter), and then internally do the necessary time compensation. However, this may be good enough in offline processing, but for a real-time situation, you really want the reported latency as low as possible…
