One juce project with two plugins


I am currently working on a vst project, that is supposed to have two different plugins. These plugins share some data(audio and some info). The data would be implemented as static so that both plugins can share the same instance. And given the fact that both plugins are in the same memory-space, this should work.

However, I am not sure how to get two plugins inside one juce project, is this possible at all? Or do I have to think about putting the shared data in a third shared library that can be reached from both plugins?


The way to do this is to build your shared code into a JUCE module and include it in both projects (or as a static library, or whatever shared method you choose). There’s no way to have two plugins build from the same Projucer project.

Thanks for the clarification. What I tried till now, was to build a common shared library(.dylib) and link my two plugins with the same library , but I definitely missing something big here, because the static data(sharedresourcepointer) I am using to test the scheme with , still get its own copy on every plugin. How can I make these plugins share the same data?

The first answer to this question is a pretty good overview of what you can do:

from the answer on stack

In the case of Unix-like environments (like Linux), the dynamic libraries, called “shared objects” with extension .so export all extern global variables (or functions). In this case, if you do load-time linking from anywhere to a shared object file, then the global variables are shared, i.e., linked together as one.

somehow this is not the behavior I am getting, my plugins are both linked against the static library, and the variables I am sharing are marked extern in both plugins, with a single definition across the plugins and the static library.

Did you mean to say “dynamic” instead of “static” in your last message?

So if you compile your shared functionality and data into a dynamic library and link it at compile time with both your plug-ins, then you should be able to access the shared data if your plug-ins are actually loaded into the same address space. However, there’s no guarantee that a host will do this and there’s a move towards hosts loading plug-ins in separate processes.

VST 2.4 provides the kPlugCategShell category (that allows multiple plug-ins per dynamic library) plus a bit of hack of the JUCE VST2.4 wrapper you may end up with what you want. VST3 provides an equivalent as a factory. Other plug-in formats: not explored.

@t0m thanks for the answer, Yes I meant i linked them dynamically(dylib). But found my problem, somehow xcode wasnt linking the libraries at all and was only using the header declaration.

So back to the to topic of separate processes, how serious is this issue? I have been reading it in a couple of other threads, but I havent seen any actual evidence for this. In case this is true, do I have to use some kind of mpi? or are there any built-in message sending implementation in JUCE that would tackle this problem?

@fbecker thanks I will look this one up,

Bitwig loads all VSTs in separate processes, Reaper certainly has the option to do so but I don’t know if this is the default.

Logic Pro loads AUv3 plug-ins in separate processes.

If you just want to pass messages you could use the OSC module in JUCE: