Use Juce's audio engine as a non-gui library?

General JUCE discussion
1

Hi Jules,

I needed to integrate a third-party Android GUI with Juce’s fantastic audio engine. Alas I didn’t control the android startup activity here, so using an introjucer-generated Android build was no option.

After some hacking I got it to work, but alas it can’t be done without modifying juce and it’s a bit ugly. For instance, the JNIClassBase stuff fails when juce can’t use its own startup activity. Also the JNI_OnLoad() implemention needs to be removed. And I need to call the AndroidSystem.initialise() / shutdown() methods somehow from the third-party startup code. And all the stuff dependent on juce_gui_basics needs to be excluded as well, which is a bit painful since the non-gui part of AudioProcessors is still useful, but can’t be used

That being said, all in all, it wasn’t such a big change to implement.

so I was wondering, wouldn’t it be feasible to refactor Juce slightly so that its audio engine can be used as a library out of the box? And not only on Android but on all supported platforms?

If it were, you could probably expand Juce’s market, by positioning it as a rich x-platform audio/midi engine. This would be great for gaming toolkits and other apps that come with their own GUIs. For example, people might be interested in reusing their VST implementations for sound generation in a gaming audio back-end. No other audio engine is capable of this AFAIK, but I imagine a “head-less” Juce could easily do just that.

What do you think?

PS given some other debate that is currently going on, this is not a request about refactoring into a dll or .so or anything. The current practice of dropping module source files into a project works well IMHO and I’ve grown rather fond of the introjucer. I’m just looking for a an option that would let Juce avoid bootstrapping the GUI on each platform, and still being able to use most of the audio functionality.

2

TBH I think it’s only Android where the startup code is entangled with the library itself, and that’s because of the java integration nastiness. On any other platform there’s no issue at all, it’s just a bunch of c++ classes that you add to your app, and many people do use it inside other frameworks.

I guess it could be refactored so that the library is given some other kind of object rather than the startup activity object, but it’d require a bit of unpicking and there would need some kind of java object involved… Sadly no time to address that at the moment, it’d be more than a 10-minute job to do!

3

ah, good to hear only Android requires work then :smiley:

about that java object, couldn’t we just drop Juce’s generated activity class into the 3rd-party java folder, next to the 3rd-party activity? But keep the 3rd-party manifest to make sure that the 3rd-party activity gets launched instead of Juce’s? That would perhaps still allow the Juce callbacks to your activity for the non-GUI stuff we still need. All the rest seems to be just a few lines of C++ code here and there (I can show what I did if you like)

4

Well, I don’t know much about writing normal android apps so am happy to take any suggestions!

5

great, will write up suggested mods and come back to you later

6

I am using JUCE exactly in the way intended by mucoder on iOS and it works fine. Having this possibility on Android would great.