Combining juce with c#

Being proficient in c# and learning c++ just to do audio coding with juce I wonder if it would make sense to combine a juce c++ project for the audio processing and c# project for other things like the gui?

It is going to be difficult and there won’t be many, if any, online resources to help you with that.

1 Like

The closest I can think of with C# and Juce, is the Unity support.
I haven’t tried it myself so i can’t comment on it.

1 Like

If you’re brave you could attempt to generate bindings via swig this would possibly expose JUCE to a bunch of langues c#, python, etc.

Although it’s going to be tough or nearly impossible to get this working realtime safe and with good performance.

Another approach would be to write the DSP in c++ and then bridge only parts to C#, but then: what’s the point? Modern C++ isn’t that bad - I don’t even recall the last time I had any of the typical pre-C++11 problems like double deletes, dangling pointers or memory leaks. And the non- memory related classes of annoying problems you’ll have in any langue: priority inversions, deadlocks, race conditions, logic bugs, etc.

So why not pick up a copy of “effective c++” or any number of other good books on the language and go native. Common over to the dark side, it’s pretty nice here :wink:

1 Like

are you thinking of plugins or standalone apps (eg mobile) ?

in case of standalone apps, perhaps this can be of interest.
On IOS and Win32 it was not that hard to interface a C# GUI with a headless juce audio engine. Android used to be doable as well but alas the sample got broken with Juce 4

Also no idea whether this still works with more recent Juce versions - this material is quite old now… So YMMV!

The best design pattern I’ve seen with this pairing is to use C# to accelerate front end development but to keep the runtime DSP pipeline in pure C++. This is a good forum post to understand the pattern, since even Unity does it themselves:

So whenever this type of wish comes along, it’s probably best to ask yourself exactly what you’re trying to do. If not careful you can run into the same issues you’d face if you misused the Android JNI, for example, and kept going back and forth over the managed/unmanaged language boundary instead of pipelining your DSP entirely natively without interrupting it from the managed side.

1 Like