As an audio programmer, I’ve been using the JUCE framework for professional, personal, and academic projects, for about four years now. Over the past couple years, I’ve heard plenty of negative comments about JUCE from the community and from my colleagues. While many of these complaints are valid, I wanted to take some time to outline some of the reasons why I use JUCE.
When I started out as an audio programmer, my first framework that I tried was the VST SDK. As a relatively inexperienced C++ programmer, I had a lot of difficulty getting started, and ended up spending close to a year spinning my wheels, not to mention that even after having made a plugin, I had no way of sharing it with friends who used different platforms and different plugin formats. So when my brother pointed me to the JUCE framework in summer of 2016, I was beyond relieved! Programming with JUCE allowed me to write portable code with relative ease, allowing my plugins to be compiled cross-platform and cross-plugin-format.
I should mention that while JUCE allows you to write portable code, it doesn’t guarantee that the code you write with JUCE will be portable. I’ve heard several frustrated users complain: “my JUCE plugin compiles fine on my machine, but not of machine X”. At the end of the day, you’re still writing C++ code, and it can be very easy to write non-portable C++.
That said, JUCE is not the only cross-platform plugin framework. Notable contenders include Filipe Coelho’s DISTRHO Plugin Framework (DPF) and Oli Larkin’s iPlug2, each of which have their own advantages (DPF supports more Linux plugin formats, and iPlug2 supports Web Audio Modules, Faust, and more). I think it’s important to have alternatives to give developers options to choose the right framework depending on what features they need for a given project.
Another important point is that JUCE is much more than a plugin framework. JUCE is a wonderful tool for building cross-platform applications and mobile apps, that rely on advanced audio functionality. To my knowledge, no other frameworks offer this level of flexibility.
The next great feature about JUCE is how much support it provides for both new and advanced users.
For beginners looking to start a new project with JUCE, the JUCE tutorials provide easy-to-read explanations of how to write JUCE code to accomplish specific tasks. These tutorials were invaluable when I was getting started, but I still often refer to them today. The example code that comes with each tutorial is often a great way to get started with an implementation of some new feature related to the tutorial.
The JUCE documentation is as good as any that I’ve worked with. While most of the API documentation is generated with Doxygen (similar to many other C++ tools), the JUCE docs often give very clear explanations of the available classes and functions, as well as useful code examples. Finally, the documentation contains an immense amount of self-reference, helping readers to find exactly what they’re looking for.
Another important part of the support that JUCE provides is the vibrant community of JUCE users. The JUCE forum is an indispensible resource for learning from bugs that past developers have dealt with, learning about new JUCE features, and even finding JUCE-related jobs. More recently, The Audio Programmer community has also been a wonderful resource, hosting JUCE tutorials on YouTube, and leading regular developer meet-ups.
The JUCE framework is dual-licensed: users can either use JUCE under the open-source General Public License (GPL), or pay a licensing fee for a proprietary license. As a regular open-source contributer, having the free open-source licensing option is crucial, but even for proprietary projects the JUCE licensing fees are pretty reasonable. There have been some concerns for the future of JUCE’s open-source status, given their recently being acquired by PACE, but the JUCE developers have maintained that their open-source support will not be diminished.
I also wanted to mention how extensible the JUCE framework is. JUCE uses a series of libraries known as modules, letting users pick and choose which JUCE modules their project requires. However, JUCE also allows users to create and use their own custom modules. Several of my favorites include:
Recently, JUCE has become even more easily extendable with full CMake support introduced in JUCE 6. I took advantage of this feature in a new project, where I integrated DSP code written in Rust into a JUCE audio plugin.
Having used JUCE for several years now, I’ve also had the opportunity to see JUCE improve. Both performance improvements and new features have made my life as a programmer significantly easier, and I’m excited to see what improvements JUCE continues to make in the future. Perhaps most important of all, JUCE listens to their users when making improvements. About once a year I fill out a developer survey telling the JUCE folks what features matter to me, and where I’d like to see them spend their time and energy.
These surveys can be a double-edge sword however. Recently I was looking at porting one of my plugins to the LV2 format for Linux users. Unfortunately, JUCE does not currently support building LV2 plugins, and doesn’t have plans to add LV2 support due to low scores in their user surveys. Luckily, the extensible and open-source nature of JUCE came to the rescue: with the help of Konstantin Voinov’s JUCE fork (part of his LV2 Porting Project), I was able to successfully add LV2 support to my tape emulation plugin. That said, if you want JUCE LV2 support, please let them know in their next user survey!
At the end of the day, JUCE is a tool just like any other, and the ultimate goal of any tool is to help achieve peace of mind for the user. In your work, you should use whatever tool brings you and your collaborators peace of mind, whether that’s JUCE or something else. Everything I’ve said here is my own opinion, and you should feel free to agree/disagree as you see fit. That said, I hope I’ve helped to give some explanation as to why I (and many other audio developers) so often use JUCE.