I am an experienced Java developer with a love for music and a desire to work in audio plugins.
I have downloaded JUCE and I am getting started with the demos and getting back into C++ etc…
I was wondering is this platform the right one to be learning in 2019?
There are many ways to write audio software. You can always use the various SDKs independently, be it to talk to audio backends or to DAWs as audio plugins.
But I am not aware of an alternative, that lets you write once and run it in so many platforms at once…
So yes, it’s a good choice, and it is well established in the audio industry IMHO.
I am going to focus on audio manipulation plugins such as compressors, eqs and other ideas I have because that fits with my work as a music producer/engineer and studio owner.
I am sure you will see me around here asking dumb questions very soon
If you only want to write a plugin (i.e, not a standalone or mobile app) you could also look at iPlug2. I think it’s more flexible in terms of graphics. But JUCE might be more friendly for beginners. @olilarkin might be able to comment further
…and if we’re being exhaustive, you may want to look at Will Pirkle’s RackAFX and ASPiK packages that are a companion to his books on DSP and Synth design
I think the opposite is probably true, iPlug is more limited, and perhaps therefore easier. Regarding the OP, juce is the most commonest audio plugin framework for sure, but juce does a million other things as well as plugins and is more comparable to QT. In the land of plugins, iPlug, VST3SDK+VSTGUI+steinberg wrappers, ASPIK, DPF, DPlug are the public domain alternatives with quite a few companies using their own closed frameworks
Hi, new to this. Is ASPiK widely used in the industry? Is it reputable?
EDIT: Asking because I’m starting his book and curious if I should continue learning JUCE, or if I can accomplish just as much switching over to his framework (from the perspective of being a good candidate for audio programming jobs down the line)
I think JUCE is by far the most mature and most used framework when it comes to commercial plugin development. While some of the bigger plugin manufacturers have their own company internal frameworks and don’t use JUCE there are also quite a few bigger names in the industry along a major share of the medium sized to one-person companies that use JUCE. Things might look different in the Open Source software world and you might even find a few commercial plugins that are built on one of the frameworks mentioned in this thread, but I wouldn’t call any of them widely used in the industry – at least that is what I get from conversations with other developers e.g. at the ADC and reading job offerings from the plugin industry.
So if your goal is to become a good candidate for audio programming jobs, I would encourage you to learn JUCE first to get an idea of some basic concepts of audio and plug in programming and then try to understand what’s going on under the hood of JUCE to find out how the APIs JUCE abstracts look like. This might help you adapting your understanding to other possible (in house) frameworks a certain company might use while getting some solid experience on how to get stuff done in the most widespread framework.
I think ASPiK (as well as his previous RackAFX and SynthLab) was created by Will Pirkle as a way to simplify the teaching of plug-in development (as he was a professor at the time he wrote his books and these libraries), but not necessarily to be an industry-strength alternative to JUCE or iPlug.
I wouldn’t say it is widely used in the industry. I don’t know if it’s reputable or not but the most recent commit to the GitHub repo was almost one year ago. Pirkle also no longer works in education and may not have much incentive to keep working on it.
You can read Pirkle’s book and implement his examples in JUCE just fine, and it will in fact be a good exercise to do so. His book will still be very valuable even if you use JUCE.
you can easily spot which ones of your favourite plugins were made with juce by simply turning a knob. those are typically made with juce::Slider. if sensitive drag is implemented on ctrl instead of shift and for some reason doesn’t work for mousewheel, even though the mousewheel interval is too big, then it is a juce plugin. if not, then it might still be a juce plugin, but with custom parameter components or a smart edit of juce::Slider. it’s a shame that i can’t think of something positive that gives juce plugins their special character of the top of my head. but you gotta see it like this: if so many developers use juce, even though the major component for user interaction feels like that, then the framework obviously has a lot of other things to offer that might not be so obvious at first, and i’m sure you’ll quickly run into them.