Hello,
Im new to Juce, have scattered knowledge of C++ and I’m keen to learn how all this works. Alot of the tutorials focus alot on the code, I’m wondering if there are anymore conceptual tutorials out there that foucs more on why and how this all works.
I guess this is more directed at audio programming concepts - but it would be cool if there were some resources that tied that in with Juce
TLDR: Good resourses for fundamentals of DSP and audio programming for beginners
The book that I found helped me the most when I started was “Designing Audio Effect Plugins in C++” by Will Pirkle, It does a good job of explaining the fundamentals, and you get to make a large selection of effects. There is plenty of maths if you are that way inclined, I skipped a lot of the maths on my first read, made some fun stuff, and then as I progressed went back and learned a lot of the theory. It also contains references to many additional papers when you want to learn more. I still regularly refer to this book 10 years later.
I have found a review on youtube
Free resources…
I wrote a “getting started” post on my blog with various resources: Getting Started with Audio Programming
In addition, I wrote an entire book about using JUCE to write a synthesizer, which doesn’t just show the code but also explains the why behind it all: Creating Synthesizer Plug-Ins with C++ and JUCE | The Audio Programmer
Thanks everyone! this all looks super promising
I’ve created this personal cheat sheet (Juce Plugin Flow and Framework) while learning Juce. It’s about the flow of fundamental things going on behind the scene and also about how VST3 and other plugin formats work in general (AU, AUv3, AAX and LV2).
That helped me a lot figuring out how to code in the framework and what classes and methods to use depending on what you want to achieve because Juce is a huge framework and you need to understand these core principles to figure out which classes and methods you’ll need depending on what you’re trying to achieve.
Hope that help, enjoy!
JUCE’s architecture aligns with the dual-component model used in the VST3 standard, which separates the processor and editor component
I think this is misleading/incorrect. IIRC, whilst JUCE has a separate C++ base class for the plugin (the processor) and another class for the UI (the editor), the JUCE VST3 implementation follows the SingleComponentEffect approach. VST3 introduced the idea of a distributed set up where there are two “components” that communicate via a messaging system. It’s explained here. You don’t have to use that though, and most plug-ins, especially those built with JUCE are not.
Thanks @olilarkin for your comment.
Based on the code in JUCE/modules/juce_audio_processors/format_types/juce_VST3PluginFormat.cpp, it seems JUCE supports both single-component and dual-component models.
if (! holder->isIComponentAlsoIEditController())
editController->initialize (holder->host->getFUnknown());
and
if (! (isControllerInitialised || holder->fetchController (editController)))
return false;
suggest that JUCE is designed to handle both single-component and dual-component models. The check isIComponentAlsoIEditController() indicates that JUCE can work with a single object that acts both as the IComponent (audio processor) and IEditController (editor). This flexibility allows JUCE to support plugins that use either model.
The framework is flexible enough to handle cases where the IComponent and IEditController are either separate or the same object.
This supports the idea that JUCE aligns with the dual-component model conceptually but also can function in a single-component mode depending on the plugin implementation.
I guess the framework is choosing one over the other at build time depending on the OS or/and some settings in the Projucer, but can’t confirm so far.
I fixed the infographic accordingly.
I believe this is only when hosting VST3 plugins.
You mean the HOST is making the decision of which model to use during the loading phase?
No, JUCE plugin hosting code can host single component and distributable VST3 plug-ins. When you build a plug-in (see the JUCE plug-in client module) You are building a single component VST3.
ok I see. This means that while JUCE can host both types of VST3 plugins, it itself builds single-component VST3 plugins.
I’m not sure that distinction is really something you need to worry about when writing plugins in JUCE. Part of the point of using JUCE is that the framework abstracts away the plugin format wrappers, so you just need to write your AudioProcessor and AudioProcessorEditor classes.
I agree
Indeed, you don’t need to worry in JUCE, because you have no choice anyway.
So it would make sense for the graph to not mention it at all, rather than stating something wrong.
But it is no biggie either…
The two component effect has interesting use cases. For instance when putting the processing on a different machine than the controller(editor). Imagine a mixer rack on the stage with an FOH controller. I don’t know, if in that case a singleComponentEffect would simply not work, or maybe they have then two instances somehow coupled…
Interesting, I didn’t know use cases like that were supported directly by VST3, I thought the product would have to support it by offering a “remote control” mode or something…
