Redundancies & right time to initialize

Audio Plugins
1

One thing that in every plugin project needs to be resolved newly is the right time to initialize its algorithm. To do so the plugin need to know at least

  • what channel configuration
  • what sample rate
  • what IO processing block size
    the plugin has to deal with. There is not a singular place that gets called when ultimately everything is set, so it needs to be re-setted at various places whenever the plugin announces one of these parameter has changed. Unfortunately not all of these have a distinct announcement either. I learnt one place is prepareToPlay.
    Now, when instanciating my plugin as VST3 I receive following sequence with varying configurations:

virtual void processor::numChannelsChanged()
virtual void processor::numChannelsChanged()
virtual void processor::numChannelsChanged()
virtual void processor::numChannelsChanged()
virtual void processor::prepareToPlay(double, int)
virtual void processor::prepareToPlay(double, int)
virtual void processor::numChannelsChanged()
virtual void processor::prepareToPlay(double, int)
virtual void processor::prepareToPlay(double, int)

until finally the configuration matches the host expectation. Whenever the blocksize, the number of ins/outs, or the sample rate changes the plugin has to reconfigure its whole processing, which takes a while because of its complexity.
Would it be possible for JUCE to just call each of these functions once, whenever something actually has changes. I don’t see any reason for my plugin to reconfigure its I/O five times because somewhere there is a confusion if the plugin is instantiated in a mono or stereo track. The plugin ignores the call if nothing has changed, but usually the host seems to request to set the configuration in a mono,stereo,mono,stereo,etc. sequence.

2

… and of cause, prepareToPlay seems to be fine for VST3 and others, its not even called when instantiated as AAX. I think if such a platform abstraction where to makes sense it should take care about a transparent interface. I.e. hide as much of the platform details as possible from the plugin and deal with those differences at a lower level.

3

Can you be more specific about your plug-in? I’ve just tried the JuceDemoPlugin and that seems to be getting a prepareToPlay call.

4

Thanks, fabian,

I was wrong here, its releaseResources() thats not getting called under AAX.

sorry,
raketa

5

The AAX calling prepareToPlay multiple times and not release resources should be fixed now on the latest tip of the develop branch. I’ll also slowly update the other plug-ins to stop excessive prepareToPlay calls.

6

Thanks, fabian,
that are good news!
Reducing the de/initialization sequences will help improve loading times for our plugin!

Thanks,
raketa