An array of identical plugins

Hello.
I shelved this idea for some time, but I’m coming back to it.
I want my plugin to be able to open a set of other plugins, all identical, and to pass info to and from them in order to achieve microtonal tuning abilities in plugins that weren’t designed for this. It should be mostly invisible to the user.
There should be one main plugin instance with which the user interacts and which never goes away. The others would receive all the same messages that the main one receives except pitch bend, note on and note off messages, which will be sent selectively.
So I’m working with some wrapper code I’ve been modifying, and the problem I’m running into is that both of the createPluginInstance methods of AudioPluginFormatManager work with unique_ptr . One returns the unique_ptr and the other passes it to the callback function.
If my intention from the beginning is to copy this instance and always have several of them, what’s the safest way to do it? What I have thought of:

  1. release the ptr? I haven’t looked into how this is done…
  2. deep copy?
  3. request as many plugin instances as I need from the same AudioPluginFormatManager, and keep that object and the plugin description in memory the whole time. Instead of copying the plugin instance, I request as many as I need.

My intuition tells me this last one will be the most efficient and safe. Any suggestions?
Thank you.
Chuckk

  1. sounds like the best approach (if I understand the problem correctly)

AudioPluginInstance is not a copyable type (which makes sense, as it would mean all classes inheriting from it would have to implement copy semantics).

  1. is your only option really. An AudioPluginInstance should not have a big memory footprint (at least not until you have called prepareToPlay()), so really there is no harm in having a bunch of those instantiated.

Looking at it again, it seems a no-brainer. I need multiple instances either way, as I will pass them different notes and pitch bends. There will be one main instance that always exists, and then a group of them that could be more or less depending on what the user wants. So - I think - if the user finds they use too much of the available resources, they could reduce the number.
I instinctively guessed that the whole idea could be impractical because of the resources; if someone uses a sophisticated, powerful plugin, having 6 of them running per instrument automatically increases all resource usage x6. But a few composers have told me they regularly experiment with hundreds of running VST plugins without any problem, so I decided to at least pursue it. My computer might not be able to handle everything I’d like to compose, but at worst, this would be one option that doesn’t exist as of now.