Running juce inside a shared library

Hi, I’ve got some juce code in a shared library which I’m loading into a juce application.

When I call into a function in the shared library it looks like the messagemanager is not set up and there’s lots of asserts firing off.

Is there anything that needs to be done to “initialise” the shared library code before it can be called?

I’ve added a call to juce::MessageManager::getInstance() to the init code for the shared library which seems to get rid of the asserts, but not sure if this is the right way to go about things.

Thx

The ScopedJuceInitialiser_GUI serves for that purpose. It is reference counted, so you can have as many as you want of them.

Make sure to compile against the exact same juce version with the exact same preprocessor flags from the application and the library, otherwise mayhem will break out.

1 Like

thx for speedy respone @daniel

Hi - tried this and doesn’t seem to work - the numScopedInitInstances value is already 1 when calling into the shared library so it’s not initialised again in the library.

thx

Well, the use case is not to initialize it again.

It makes sure it is initialized, and when no initializer is around anywhere, it de-initializes, closing the audio devices, stopping the message manager and deleting all singletons in a deterministic order.

What should happen in your opinion?

1 Like

Ok, maybe i’m not explaining the situation well enough, apologies.

I have an audio app - this is the basic app created from projucer.
It has a the base UI which it initialises - all good.

I load a dynamic library from this app and call into a function in the dynamic library. This function call happens to do some midi initialisation in the dynamic library which requires you to be running on the message thread, but these checks fail in the dynamic library, even though the calls originate on the message thread in the calling app.

thx

That is weird. So the JUCE_ASSERT_MESSAGE_THREAD macro fires?

Two things come to mind, first can you check if using juce::MessageManager::callAsync makes a difference?
And then there is a setting setCurrentThreadAsMessageThread(), which should happen during initialization. Maybe something with the libraries memory is wrong?

Maybe somebody with a more fundamental understanding of libraries can chime in

1 Like

Hi, no, that makes no difference - I assume as there’s no message thread it can attach to at this point?

Can’t see anything calling setCurrentThreadAsMessageThread(), even in a normal app.

Thx