That’s probably a basic C++ question, but when the host loads several instances of the same plug-in,
why do they have to share the same classes in memory?
And just to make sure, my instances will share their singletons as well as all of their static members, right?
What do you mean “share”? When you load a plugin twice, the second instance is completely different from the first one. It has its own globals, stack, thread(s), etc… the two do not know about each other. The only way for plugins to see each other is to use some kind of operating system interface for communicating between processes. Since a plug-in is a DLL (or whatever they call shared libraries in your target environment), all of the rules which apply to DLLs apply to plugins:
I don’t think that’s true. The globals are shared, at least on Windows. The same plugin DLL is only loaded one time, even if you have 10 plugin instances, and therefore, globals are shared among all plugin instances. I used this property in one of my plugins to create some kind of inter-plugin communication.
I checked it on Windows and both the singletons and the static members of the functions are being shared between the instances.
I know that in Java you can load classes using different class loaders and they will be considered different classes, donno if something like that exists for DLLs.
Did someone solve the problem?
I have the following issue: I change some colors according to the tab in the plugin. If I now run multiple instances in the same DAW (tested with AU Lab) and change in one instance to another tab, some colors in the other instance change as well. Furthermore, some text is not drawn anymore. It seems to be a very strange problem and I have no clue how to solve it. Have anyone an idea?
Check you are not using global or static variables...TheVinn's reply suggesting the globals and statics are not shared for the same dll (when it's loaded into the same process) is not correct.
I think Jules himself has been quite careful in Juce to not have surprising globals and statics in the code, so it's most likely your code that has some unintended sharing of variables.
I had the same issue. Make sure you do not use the static function LookAndFeel::setDefaultLookAndFeel(&this->talLookAndFeel); to set the look and feel. Just call this->setLookAndFeel(&this->myLookAndFeel); on your main component.
A bit stuck here. What if you have something like this declared globally:
int gate = 0;
then in the process block:
processedMidi.addEvent (m, time);
and elsewhere in a different function where you are controlling the gate:
how can you share "gate" within a single instance of a plugin without sharing it in ALL instances of that plugin (if there are multiple instances in the DAW)
Just make gain a member variable of your AudioProcessor class. Pass a pointer to your AudioProcessor to any other classes that need access to this variable. For example JUCE's AudioProcessorEditor always has a pointer the AudioProcessor via the getProcessor() method function.
hi - thanks for the reply - i have been banging my head against this for a few days now.
I see how it works int the AudioProcessEditor but can figure out how to set it up outside of there. If you post a brief example to get me started, I'd be much obliged!
Suppose you have a type called MyType:
static int myStaticMember;
When you modify
myMember, it'll only change the value for that instance. On the other hand, when you modify
myStaticMember, it'll affect all instances. For example:
// create two instances of MyType
MyType instanceA, instanceB;
// make sure myMember starts at 0
instanceA.myMember = 0;
instanceB.myMember = 0;
// change the value of instanceA's myMember
instanceA.myMember = 1;
// at this point:
// - instanceA.myMember is 1
// - instanceB.myMember is 0
// change the value of instanceA's myStaticMember
instanceA.myStaticMember = 3;
// at this point:
// - instanceA.myStaticMember is 3
// - instanceB.myStaticMember is 3
So, if you need something to seperate for each instance, just use a normal member variable. The same applies to global variables as does to static member variables.
Hope this helps! :)
Thanks for the reply!!!
Unfortunately - this doesn't seem to work - I suspect because I am using it in a plugin?
In order to reference the same instance (InstanceA) I have to create the object globally so that it can be used in the AudioProcessor as well as my class instance. I think that's the rub, because that instance is global, it seems to be the same for all instances of the plugin.
The goal I'm trying to achieve is to send or mute midi messages in the process block when certain OSC messages are received. For that to happen, I am trying share a "gate" variable, and that's where I'm stuck.
The way I have it now - the if the gate opens in one plugin, it opens in all of them.
any ideas or pointers would be greatly appreciated!
You can't use static variables in a plugin. Otherwise it exists in the memory only once for all instances.
that's exactly the problem. Haven't figured out an alternative that works!
Maybe invest some time in learning basic C++ skills? This has nothing specifically to do with plugins or JUCE, it's just basic knowledge of how the language works that you seem to be lacking.
I am new to C++, I am indeed studying up. In the meantime, this plugin is a compenent of a larger project in another language. apologies if i wasted anyone's time.
No need to apologise, we like beginners!
We just don't have time to help everyone with problems that aren't juce-specific, and there are other basic C++ sites and books where you'll get a better explanation of how variables work than we could give you here in a post!
Don’t be so arrogant, and be polite. Not everyone starts as early as you and we all know Juce has so many problems, and it could be so much better if someone else takes the lead to develop this framework
There’s nothing “arrogant” about encouraging beginners to spend time learning basic C++ skills - that’s a message that we’re all constantly repeating, because we see so many people trying to run before they can walk and it’s just not a good way to learn. Not really sure what bit of my replies triggered you there, TBH, they seem perfectly polite to me.
Anyway, this thread is from 2012 so needs locking. If you want to criticise me, please start another thread for it.