Singleton instance shared between plugin instances

In regards to a singleton, keep in mind that in addition to BitWig. AUv3 plugins are by default loaded in separate processes (unless the host specifies otherwise), and Reaper can be configured to load plugins in separate processes too.

1 Like

I’ve a similar question with Singleton in a plugin.
I would like to add Analytics but the Juce Analytics class is a singleton.

@dave96 would you recommend to not use this class?
If yes, what will be your approach to do some analytics in a plugin?

I used it in two commercial plugins in combination with mixpanel and never had issues across all hosts/os

1 Like

Singletons are useful for sharing immutable data.

For example I use a singleton to hold bitmap and font resources. A knob composed of a large strip of images (individual animation frames) can consume a lot of memory. So it’s an advantage to store such images only once, even when multiple copies of the plugin are instantiated.
It’s also the same advantage with huge sample libraries. We can load the same samples into multiple instances of the plugin, but share the data. Another advantage is that loading the samples into the second instance is instant (because it’s merely taking a reference to the first copy).
If the DAW chooses to load plugins into separate processes, then the singleton is less effective. Because each instance gets its own private singleton. But there’s no harm done either. The plugins work fine.

So it’s not correct to say that singletons are ‘wrong’ in a plugin because it depends on what you are using them for.

Back to OP’s question: Singletons are not an obvious solution for sharing mutable data between the UI and Processor of an individual plugin, because they are also shared across all instances of the plugin.
You can make it work by having each instance hold a unique identifier, so that when an instance looks up the data it can specify e.g. “give me a pointer to the shared data for instance #7”.
This is useful in advanced scenarios, like when a plugin uses a preset-specific wavetable that needs to be shared with it’s own GUI, but not with the GUI of other instances.
Mip-mapped Wavetables can be expensive to calculate, so storing them in a singleton also has the advantage that they can be persistent when the processor has to restart (you might choose to delete and re-allocate your DSP whenever say the sample-rate, buffer-size, or routing needs to change). So in that scenario, you can just quickly grab a reference to the stored wavetable without having to calculate a bunch of FFTs all over again).

Hope that makes sense.

4 Likes

Thanks @moritzsur for your feedback. Could I ask you if you would have some exemple to share (not your commercial project of course but maybe some open source you found during your investigations) ?

Thanks @JeffMcClintock for the details your shared. Really useful and I didn’t know this kind of usage too :slight_smile: