Super cool you went and did that, @zebra. 
What do you think of the JUCE library?
What do you think of the JUCE library?
hm, i’ve been using juce for about 10 years, a little ambivalent throughout.
pros:
- by far the fastest way to get a cross-platform c++ project set up doing GUI and audio.
- if there’s a function you need w/r/t multimedia, probably has it
- it’s easy to learn and hides a lot of complexity from the user
- promotes good practices (RAII, &c)
cons:
- its big and kind of bloated
- hides a lot of complexity from the user
- its like learning a different, higher-level language than c++ per se, esp. since RAII and other practices are enforced by the framework.
- GUI stuff is quite slow compared to QT or native frameworks.
- ROLI wants your money now
so in a nutshell, i use juce a lot for prototyping and when Good/Fast/Cheap favors Fast+Cheap.
when Good (read: efficient) is prioritized, and for larger projects, i use other libraries and tools. most importantly boost and cmake, other stuff as required. when it’s ok to spend longer setting up.
for this little project i would have used libsndfile and magick++, but thought maybe targeting windows off the bat would be helpful… ah well.
in a nutshell: juce is cool and extremely helpful. but also, c++ standard libs and boost have largely caught up with it; i generally prefer those options within code modules implementing internal functionality, and use juce modules for convenience when interfacing with the “outside world.” e.g. prefer std::unique_ptr to juce::ScopedPointer. i use juce out of habit, but not professionally very often - this would be different if i was working on audio plugins mostly since that is the primary use case.
and i guess that’s that!
2 Likes
Thanks for the detailed breakdown, @zebra. For DSP, I’ve always mostly rolled my own stuff for maximum flexibility. However, seeing such a well packaged library has me very intrigued. I appreciate your insights!!
not to beat this dead horse, but
as it happens i have never found much use for the DSP parts of juce. either they implement stuff that is just really basic anyways (IIR filters, ramps, whatever) and/or they are too inefficient for practical purposes (FFT.) by the time you have implemented pretty much anything in music-audio world you probably have your own wavetable oscillator and so forth.
no, i keep using juce because its a very convenient collection of cross-platform utilities for interfacing with the outside world, especially media-related I/O and most especially UI. stuff like:
- audio device management
- midi
- OSC
- UI widgets
- image processing
- openGL
- build system abstraction
- plugin API wrappers
you’d need like 5 other libraries for that stuff and it’s annoying to set up for a quick prototype.
lower level stuff that i’ve weaned off of, preferring boost and std:
- timers
- threads and IPC
- sockets
- memory management
those are all available out of the box on any modern c++ platform.
and there are a few things that i would use from juce if the APIs weren’t godawful/broken (JSON.)
honestly i don’t give it the full endorsement that i did a few years ago. its getting too baggy and stale, linux is undertested, some of the new support staff has no idea WTF they are talking about, and i most especially don’t like ROLIs new licensing shenanigans.
ok, derailed the thread enough i think.
2 Likes
Sorry to derail this a bit further (should we create a new topic maybe?) but have you ever tried DPF?
Would be interested in your opinion on it vs JUCE.
I’ve been looking at building some simple plugins but didn’t like what I saw when looking at JUCE mainly because it felt way too big and complex for the task and they keep refusing to merge LV2 plugin support.
i haven’t worked on plugins in ~10years, so haven’t seen that one. looks awesome! maybe i’ll give it a spin next time i need to prototype something.
Cool! If you try it out please let us know!
We use JUCE for everything related to interface and wrappers in our Unfiltered Audio code. We use our own stuff for DSP, though, but the new DSP classes do look pretty solid.
If you want to share, what is the reason/were the reasons to choose JUCE?
We started when we were grad students with not a lot of programming experience. JUCE is straightforward to use, and it has a team that actively fixes a lot of low-level wrapper gremlins and other things that would be awful to spend development time on.
Even now (after many more years of experience), it’s great to write one codebase and have it automatically compile for all major plugin types on Windows and Mac. We haven’t upgraded to JUCE 5 yet, but it looks like most of my major complaints were addressed (weird UI scaling in certain hosts or formats, annoying Windows compilation paths.
Cool, thanks for the info!