And in this tutorial we're going to talk to you about the Juice audio processor class.

The audio processor class is the way that you can write your plug-in code once but be able to turn your plug-in code into all the different formats that you're able to deploy for plugins such as VST3, AU, and AEX, and also be able to do those plug-ins on separate operating systems such as Windows and Mac OS.

So we have two objectives for this tutorial.

The first objective is that we're going to dissect the Juice audio processor class.

I've been doing Juice tutorials since 2017 and I'm embarrassed to say that I never really took the time until recently to dig into the audio processor class and really truly look at what it does and what each function is doing.

So I'm going to do that with you today and show you some of the insights that I've gained along the way.

The second objective is that I'm going to show you the Juice audio processor class alongside the CMake file that we did in the last tutorial and show you how those two things relate to each other and how the configuration of your CMake file relates to the code that is actually generated for the Juice audio processor class.

When one of my mentors showed me how these two files relate, it really helped me expand my mind map on how build systems and generated code actually relate to each other and helped me level up my skill set in a major way and I hope it levels up your skill set as well.

If you're ready to take that next step into audio plug-in development, I invite you to check out our latest book, The Complete Beginner's Guide to Audio Plug-in Development.

This has everything that you need to know to build your first audio plug-in, over 450 pages, and you can get it both on physical copy via Amazon and via ebook on our website theaudioprogrammer.com.

This video is also brought to you today by our sponsor, JetBrains.

So I've been using their Sealion IDE for quite a while now and along with their great cross-platform experience of being able to switch back and forth between Windows and Mac and being able to find everything easily because the experience is largely the same.

I've also been enjoying their integrated CMake support.

It's been a lifesaver for me because I'm not an expert on build systems and being able to just double click on the CMake file and have it open up my project is a lifesaver.

It also has the ability to be able to debug CMake files, which is really awesome.

I really love that feature.

Be sure to check out JetBrains and Sealion on the link below.

And without further delay, let's get started.

Okay, so here we are in our project and one thing that you'll notice is that I'm in my CMake file rather than having the ProJuicer.

And with that, I'm going to make a very small announcement, which is that moving forward, we're going to be doing our tutorials using CMake rather than the ProJuicer.

Now, I think that the ProJuicer is great if you know barely anything about C++ and about Guice and you're just starting to get off the ground and write some code and write your first plugin.

But I think once you start really getting serious about C++ development that you're probably going to want to start switching towards using a build system like CMake.

This is a challenging step and it's been challenging for me.

However, one thing that I will say is having been around a couple major music tech companies that all of them use something like CMake or another build system for generating their projects.

None of them use the ProJuicer.

Okay, so if you want to get into this and start doing this for a living, I would highly advise or recommend that you start learning build systems and learning at least the basics about them.

And that's what I'm trying to do as well.

So that's why we're working with CMake right now.

So I know that this transition from the ProJuicer to CMake will feel a little bit intimidating for some.

But don't worry, we're going to take it slow and I'm going to try to show you every step of the way how everything is happening.

So first thing I would say is watch the last tutorial because that's how we actually created the CMake file that we're seeing here right now.

So the second thing I'm going to show you is something that I learned when I first started working with CMake that really helped me switch on the light in terms of what build systems do and what their intention is.

So if we scroll down here a little bit, what I'm going to show you is that in this juice add plugin function that we have a couple configuration options.

Okay, so the reason for this is let's just take the code and put it aside for a second.

And let's just say that we were just having a conversation about creating a plugin.

So one of the first questions that we would probably ask is, well, what kind of plugin do we want it to be?

Do we want it to be an audio effect?

Do we want it to be a synthesizer?

Do we want it to be some type of midi effect?

These are some of the first questions that we would ask ourselves, right?

And so this is what I would call or what would technically be called global configuration.

Okay, what do we want this project to be?

So you can see that here with the CMake file that these global configurations are here on the front, meaning on the CMake file itself, that we can change these to true or false.

So think of these as options or buttons that we could switch as developers.

Now, what happens is that these actually affect what happens on the code in the project that's actually generated.

So if we go to skipping ahead a little bit into some of the functions into the plugin processor.cpp, we have this function here that says accepts midi, right?

And we can see that this is currently set to return false, okay?

Because we see that this return true is kind of shaded and that it's currently returning false.

So it's saying that we do not want midi input.

That correlates directly with what we have here.

This option needs midi input.

Now, if I set this to true, and then if I regenerate the CMake file, rerun the CMake file, for people who are not using CLion, you would need to use the CMake command, which I believe is CMake-B, builds-G, and then whatever IDE that you're using.

Okay, so now we come in here into access midi, and we see that that has now returned true.

So we've just kind of hit a button or hit a switch there, and that has actually switched things.

So this is a great way for us to be able to create a convenient interface for the developer to be able to change their configuration of their plugin or of their project in a way that before they actually even generate the project.

So that is what the intention of using CMake really is, okay?

So if I take this and I turn this back to false, and then if I come here over back over here into this, and then I hit this refresh my CMake file, you'll see that this will change back to false.

Okay, and see how that switched?

Okay, so that was something that was very simple, but also a very big revelation for me.

Now, I know what some of you are thinking.

Josh, why can't you just put this option directly in the header file or in the CPP file?

Why can't you just have some sort of option or some sort of bull that you put in here?

And the reason is going back to that architectural question of, okay, these are what we would call global configurations, configurations of the project just as a whole, okay?

And that from an architectural standpoint, it would make more sense to have these options within the CMake file, which is kind of the front interface for the entry point for the developer of what they want this project to be, rather than having it hidden in an individual header file or CPP file, okay?

So that's the reason that it's done that way and why developers choose to do it.

So that, I hope, helps reveal some of the light or shed a little bit of light on why we use build systems like CMake and why we use these global configurations rather than putting them into the code themselves.

So I hope that was helpful for you.

Okay, moving along, here we are in our header file, which is the audio plugin audio processor, and this is inheriting from a juice audio processor.

Now, we have a few pure virtual functions that we've been implementing here, and we can tell that they're pure virtual functions because they have this override keyword, okay?

That's how you know that it's pure virtual function.

If we go over to the juice documentation, the way that you know that it's a virtual function is if the function has this equals zero after the function name, okay?

So that's how you know that this is a function that if you're inheriting from an audio processor class, you need to provide implementations of each one of those functions, okay?

I know that that's a general C++ thing, but I want to try to make this digestible for people who are just getting started, okay?

So be sure to check out pure virtual functions if you're not familiar with that concept.

Okay, so what we're going to do is give you a whistle stop tour of what the juice audio processor is and what each function does.

This is not going to be really comprehensive.

This is going to be very general, but hopefully this should give you some insight into some things that you may not have known about before.

I know that I've learned a lot in creating this tutorial, so hopefully it's helpful for you.

Okay, so let's get started.

So the first thing that we have here is the constructor.

So this is what's called when the plugin is first created.

And what happens is that it creates this juice audio processor.

And then in here is this piece of code with some macros that look intimidating at first, but if you break it down, you can see that it's not very intimidating at all, okay?

So here we have these variables that we created with the CMakeLists.

Let me go back to CMakeLists here very quickly.

So remember, we have these global configurations like needsMIDI input, needsMIDI output, and so on.

So that's all these are here, okay?

So it's just using those configurations to see if it's a MIDI effect or if it's a synth.

And depending on what these choices are, then it's going to create some inputs and outputs and give those to our audio processor to create our audio output and input, right?

So if it's not a MIDI effect, right?

So MIDI effect would take MIDI input and do something with it.

So if it's not a MIDI effect, and if it's not a synth, then it's saying that we want an audio input that would create stereo input, okay?

And that if we wanted a stereo output, that that's what would happen.

So if it's a MIDI effect, obviously you would want it to have a MIDI output.

But if it's not a MIDI effect, then you would want it to have an audio output.

So that's what's happening there is just creating your inputs and outputs for your plugin.

And then of course, here in this function, this constructor function, you would have any type of initialization code that you would need to start up other classes, to start up other things that need to be initialized with some variables.

Next, we have our destructor.

So this is typically what we would use that on destruction of this audio processor, which would typically be when somebody deletes your plugin, then this destructor would clear out any, you would use that to clear out any memory, any resources, any processes that need to be done before your plugin can be destroyed.

Things like that would typically happen here.

These next ones, get name, accepts MIDI, produces MIDI, is MIDI effect.

All of those are direct correlations to those global configurations that we created here in the CMake file.

Needs MIDI input, needs MIDI output, and is MIDI effect and so on.

Okay, so going down a little bit further, we have this get tail length seconds.

So sometimes when you're using a plugin in a DAW, when you stop processing audio through the plugin, when you stop the DAW, then typically sometimes if it's like a reverb or it's the delay, maybe you want that delay or that reverb to continue ringing out until it's finished, until it reaches silence.

Sometimes you want the audio to stop right away when your plugin is stopped.

Okay, so if you want it to stop right away, then you would just leave that at 0.0 seconds.

That means that even if it's a delay plugin or a reverb plugin, that when you hit stop, that the delay or the reverb stops.

If you want it to continue playing after audio is done processing through the effect, after you've stopped the DAW, then you would change this to a different number.

These next few functions like get num programs, get current program, set current program, get current program name, change program name, all of these are referring to presets.

So this is referring to a preset if it's loaded or if you want to get what the preset name is.

So typically your presets will be stored in some type of a vector with what you want each parameter to be set at, and that's how that would be stored.

And so all of these are just referring to loading them, getting them, changing the name of your plugin, of your preset rather, and so on.

Going down a little bit further, we have this function called prepare to play.

So this is one of the more important functions that you have here in the audio processor.

It's probably one of the top two or three most important functions.

So anytime that you're processing a, you're doing some type of digital signal processing, so let's say that you have a reverb or you have a delay and you've created an algorithm or you're sourcing an algorithm from somewhere, typically you'll have some type of function that's called either prepare or reset or prepare to play.

And what this does is it allows you to take the sample rate and the buffer size of where the DA, of what the DAW is processing and pass it into these individual algorithms.

Okay, so for example, let's say that we have a one second delay algorithm, right?

So your delay algorithm needs to know whether the sample rate is 44,100 samples per second or 48,000 samples per second, because that will determine whether that delay algorithm needs to process 44,100 samples or 48,000 samples to create that delay accurately.

Okay, so that's why any DSP algorithm, typically you'll need some sort of prepare or reset or prepare to play algorithm that is implemented here in prepare to play.

Now, another thing is to think about or to know about is when this function is actually called within the plugin.

So depending on the DAW, sometimes these are called at different times, but typically what'll happen is that when you create a plugin in your DAW, it will, I think most of them, all of them perhaps call prepare to play when the the plugin is getting ready to start processing audio again.

So for example, when the user hits the space bar to start playing audio through the plugin.

So let's say, and the reason for this is, let's say that the user has been playing audio through the plugin and the sample rate is 44,100 and they've been playing audio through the plugin and then they stop it.

Let's say for whatever reason, they decide to change the sample rate to 48,000 samples per second.

Then what needs to happen is that that information needs to be passed into all of your DSP algorithms.

So it knows that it needs to recompute those calculations.

Okay, so that's why this prepare to play method is so important.