JUCE for plugin development

It has come to my attention that there is a C++ framework to build audio plugins called JUCE. It is GPL licensed (sort of) and I’m working with it for a different project.

I noticed quite a while ago, MOD’s very own @falkTX added LV2 as a plugin output destination to the JUCE framework. Unfortunately, it appears the JUCE release manager never merged the code, which is a rather depressing end to this seven year long forum thread.

Is it unreasonable to fork JUCE since the authors don’t seem to care about LV2? I’m new to the framework and I don’t completely understand all its features.

1 Like

AFAIK juce plugins have been problematic to bring onto the mod. There are several synths that were attempted to be brought to MOD by falktx (notably Tal Noiz3M4k3r and Helm) and were not successful. I don’t know the details of why, probably because juce had required dependencies that don’t make sense on a headless system and therefore aren’t installed on MOD.

1 Like

juce based plugins are working for MOD now, and are already on the non-stable part of the store.
My juce fork contains LV2 and non-X11 support for events.
Here https://github.com/distrho/juce

In my juce fork, if JUCE_AUDIOPROCESSOR_NO_GUI C++ macro is defined, GUI stuff (that relies on X11) does not get built.
So the result is a juce static lib that makes no calls to X11, freetype or any kind of graphics stuff.
Your own plugin code will need the same treatment. The createEditor() call needs to return null.

Almost all plugins in my distrho-ports project can build for MOD.
See https://github.com/DISTRHO/DISTRHO-Ports/
Since it was mostly a test, I skipped the plugins that would need a lot of work.

mod-plugin-builder already contains the build-stuff that makes part of the magic happen.
See https://github.com/moddevices/mod-plugin-builder/blob/master/plugins/package/distrho-ports/distrho-ports.mk

Now, if you want to do this yourself… make sure you know juce and making your own project files well (makefiles, waf, cmake or similar). Since the official juce does not support LV2 or MOD, you have to make the plugin build rules yourself - which is what I do in the distrho-ports.

EDIT: @ssj71 noisemaker already runs on the MOD, though you need 256 as buffer size to stop the huge amount of xruns.


ah I’m behind the times. Sorry!

Thanks for the clarification falktx.

HA! You already forked it. Right on. The thread I found was quite disappointing. I gathered some traditional FLOSS flame wars between the LV2 guy and the JUCE guy. I commend your resolve not to engage and keep making great work!

1 Like


I was looking at your fork of Juce and noticed that you have worked on v7 with JUCE_AUDIOPROCESSOR_NO_GUI.

I have cloned your repo and am trying to build a basic plugin with nothing but trouble :slight_smile:

Is this version working? Or is there another version I could try?



1 Like

It works yes, if you have old juce7 branch get rid of it and use the main one. Still same repo, that is https://github.com/DISTRHO/JUCE/

But for dealing with this for MOD it is best to use the packaged juce7.
Which I realize now I never pushed… So this part is unfinished, I think I was meant to do some final validation

Best to use juce6 for now, you can follow these 2 project files as initial setup.

Then replace the juce local subfolder setup for a find-package, like so:

+find_package(JUCE REQUIRED)

Hi @falkTX,

Super thanks for the info.

I got the v7 one building and deploying to mod-host, there was one ifdef missing in juce_audio_processors.cpp:

 #include "utilities/juce_NativeScaleFactorNotifier.cpp"

I’m going to try to get it onto the dwarf now, if I have issues I will have a look at the juce6…


Hi @falkTX

I’m in no end of confusion here!

The issue I am getting with v7 is it flagging up missing includes for Moddwarf, x11 etc.

If I take the Crypt example and build it via the build script everything is fine, if I take the source and build after source local.env moddwarf then I am back to the same issue I have with v7 but it is using mod-workdir/moddwarf/host/usr/include/JUCE-6.0.7:

[ 13%] Building CXX object CMakeFiles/CryptSynthPlugin.dir/home/andrewcapon/mod-workdir/moddwarf/host/usr/include/JUCE-6.0.7/modules/juce_audio_processors/juce_audio_processors.cpp.o
In file included from /home/andrewcapon/mod-workdir/moddwarf/host/usr/include/JUCE-6.0.7/modules/juce_audio_processors/juce_audio_processors.h:56:0,
                 from /home/andrewcapon/mod-workdir/moddwarf/host/usr/include/JUCE-6.0.7/modules/juce_audio_processors/juce_audio_processors.cpp:42:
/home/andrewcapon/mod-workdir/moddwarf/host/usr/include/JUCE-6.0.7/modules/juce_gui_basics/juce_gui_basics.h:299:12: fatal error: X11/Xlib.h: No such file or directory
   #include <X11/Xlib.h>
compilation terminated.

I must be missing something simple here?

1 Like

I guess it is being patched somehow, I changed CMakeLists to add the JUCE_AUDIOPROCESSOR_NO_GUI define in and it gets further.

How is this patching being done?

For crypt the UI code is being put inside that ifdef block so it is never used Changes for MOD build · moddevices/crypt@6dce4dd · GitHub

It is very important to remove add_subdirectory(JUCE)

The mod-plugin-builder package includes extra patches that cannot go into the “generic” DISTRHO/JUCE one. see mod-plugin-builder/plugins-dep/package/juce6 at master · moddevices/mod-plugin-builder · GitHub

1 Like


I had gone back to v7 and managed to get a juce example plugin built and running on the Dwarf.

Need a change to juce_gui_basics.h line 322:


The main issue with it being plug and play is that they build a helper that loads the .so and creates the ttl files.

Its a bit of a catch 22, if you are cross compiling the tool will be able to read the cross compiled .so but you can’t run the tool.

If you build the tool for native you can run it but it can’t open the cross compiled .so.

I put in a PR#22 for those two JUCE_AUDIOPROCESSOR_NO_GUI changes.


Hi @falkTX,

I have removed that PR.

I have changed everything far beyond what you would probably want to merge as I guess it doesn’t fit in with the way you guys do things, useful for me though.

Now nothing would need patching to build for mod gear.

I have updated Projucer to add a new “Mod Linux Makefile” Exporter.

I have also changed the cmake stuff and added a flag CMAKE_MOD_DEVICES.