In which order are prepareToPlay/releaseResources called? Why are they called twice?

Audio Plugins
1

Hi,

I recently ran into some troubles with my VST plugin. Hopefully someone can shed a light on these problems.

Until now, I used AudioMulch 2.2.4 to develop my plugin (VST2). In AudioMulch, I’ve figured out, that when I load the plugin, the functions are called in the following order:

prepareToPlay();
setStateInformation();
releaseResources();
prepareToPlay();

I do not know, why it is necessary to call prepareToPlay() twice, but at least, releaseResources() is called inbetween.

Now I wanted to upgrade my plugin to VST3. Since AudioMulch does not support VST3, I’m using the AudioPluginHost for development. Here, the functions are called in the following order:

prepareToPlay();
prepareToPlay();
setStateInformation();

Again, prepareToPlay() is called twice, but releaseResources() is not called inbetween. Since I’m loading a lib in prepareToPlay() that’s only allowed to be instantiated once, I’m running into trouble here.

Furthermore, when the plugin is deleted from the filter graph, I’m running into a second problem. Here, releaseResources() is also called twice. Which means that my already released memory is released again.

Can somebody tell my, why the hosts need to call the functions twice? What would be a proper way to implement the memory management here?

Can every host call the functions in an arbitrary order? Or is there some kind of standardization?

Thanks in advance,

Philipp.

2

It’s completely “normal” prepareToPlay can be called multiple times by the host. Use a flag variable to check if you have already loaded your library in prepareToPlay.

1 Like
3

Plus beware prepareToPlay is in general trustable regarding sample rate but a lot less regarding buffer size i.e. processBlock buffersize might differ from prepareToPlay samplesPerBlock

1 Like
4

And the same applies to releaseResources(), I assume? I hoped this would be better (ore more standardized) with VST3…

Yes, this is really annoying. In AudioMulch the blocksize varies from time to time in processBlock(), especially if the buffer size set in the sound card is not a multiple of 64. It took me quite some time to solve this problem, since we’re working with filterbanks that require a fixed block size.

5

The buffer size given to prepareToPlay is the maximum size the host will use, not one that will necessarily be used for the processBlock buffer.

6

prepareToPlay serves two purposes, that often go hand in hand:

  • report the rendering parameters
  • give the chance to allocate resources

It makes sense to use that together, because allocating resources often depends on the parameters, e.g. the size of a delay line depends on the sample rate.

Whenever the routing of a plugin changes, many hosts will call prepareToPlay, because the parameters might have changed. In case of the AudioSource you can observe, that the ones that have an input source will forward the call to the input source to be safe.

releaseResource() is not often used, because nowadays you should use RAII methods to manage your memory, and the resources are usually held until the plugin is destroyed anyway.

TL;DR: don’t think of the pair as prepareToPlay as a place to new raw pointers (you shouldn’t do that anyway) and releaseResources() to delete. Those calls have no place in modern projects.
But rather to setup your coefficients and AudioBuffer sizes, set the latency and similar things.
Memory management is not meant to be implemented here.

7

Thanks a lot. I’m afraid, that’s the point. By including a library, written in C, I maybe used some old-fashioned, non-RAII techniques. (Tut, tut.)