Quirky behaviour when changing blocksize [Ableton | AU]

Audio Plugins
1

Here’s another host quirk, for ableton this time:

It seems like Ableton (tested with 9 and 10) creates new instances of AU plugins when the blocksize is changed and loads the Settings by copying over the memory block. When the samplerate is changed, the same instance is kept and prepareToPlay() called with the new samplerate.

Neither does that happen with VST in Ableton, nor with AU in Reaper, as far as i am concerned.

Has anybody else observed this ? I assume there’s no way to influence that behaviour ? It’s creating some trouble in my case …

2

I assume, since Ableton’s USP is changing these kinds during live play, there is no way around having two instances in parallel for a short period of time, if you don’t want to stop the audio thread.

What kind of trouble is it creating on your end?

3

My plugins aren’t really stateless :frowning: … or, maybe that’s not the right way to put it, but anyway, they have a UUID that they use to register with a background application.

4

I see.
GUI state or DSP state?
Is saving to the AudioProcessorValueTree.state variable an option? I mean outside of the host parameters. You can add anything, that fits into ValueTree there.
And maybe that’s even an additional benefit for the user, to have more persistency for these kind of options.

5

That’s where i store the ID, actually, but that creates another problem.

It’s not possible (to my current knowledge) to decide whether a plugin has been copied (by the user) or moved (when the blocksize has been changed).

In the first case, the two instances should exist in parallel, and the new instance should keep the newly generated id.

In the second case, the plugin should keep it’s old id that is restored from the MemoryBlock.

The behaviour is the same in both cases … the new instance loads the old MemoryBlock.

6

I see where you are coming from. I had a similar setup, where several plugins communicated with each other. In my case it didn’t make sense to have two instances on one track, so I could work around using the TrackProperties name instead of an UID.
I don’t know, if that would work in your case…
I don’t think there is a way to distinguish a user copy from a machine copy, like you said.

Good luck

7

Hmm it seems like the instances don’t exist in parallel, but the change is very quick …