I'd like to welcome you to another Audio Programmer tutorial.

And in this tutorial, we're going to talk about the Juice Audio Processor Editor class.

This is the base class that is used by Juice for any visual elements that you would like to use for your user interface.

That is, what people see when they open up your plugin.

The main objectives for this tutorial are to introduce you to the Audio Processor Editor class and the concept of components within Juice.

To introduce you to the concept of parent and child components.

I'll also show you how to create new source files within the CMake system to create child components.

And finally, we'll dig a little bit deeper into what happens when you load a plugin and how the editor is actually created in the plugin loading process.

As always, I'll also briefly discuss some of the core C++ concepts along the way for those who are just getting started.

If you're ready to take that deeper dive into audio plugin development, I invite you to check out our books.

The Complete Beginner's Guide to Audio Plugin Development and Creating Synthesizer Plugins with C++ and Juice.

These are great resources to get started.

All in all, there's about 900 pages on how to start creating your own plugins.

I invite you to check them out on theaudioprogrammer.com forward slash books.

Link is in the description below.

This video is also brought to you in part by our sponsor JetBrains.

If you're looking for ways to streamline your development process, I invite you to check out their amazing C-Line IDE.

Their tools have helped me to exponentially speed up my workflow and I'm proud to be a supporter.

Be sure to check out more on the link in the description below.

And with that being said, let's get started.

OK, so right now we're in a blank Juice plugin template project.

If you're not sure how to get to this point, be sure to check out our tutorial called CMake vs.

ProJuice or FaceOff, which shows you how to start creating a project that will help you get up and running.

And as I was saying before, we're going to use CMake for tutorials from here on out.

It's the industry standard.

And I think that even though it's more difficult to get started, it will definitely help you in the long run.

So where we are now is in the Audio Plugin Audio Processor Editor class.

So as we can see, we have four files that are over here on the left hand side.

Plugin Editor.cppnh and Plugin Processor.cppnh.

Plugin Processor is what we went through last tutorial where we talked about the Audio Processor class.

And that is where the actual audio processing happens for your plugins.

So not the part that you see, but the actual audio processing.

The Audio Processor Editor class is what you actually see when you load your plugin.

So if I just go ahead and I compile this here, we can see that this plugin is loaded.

We're in standalone mode right now.

And that what we actually see, this is the Audio Processor Editor.

Now, if we dive a little bit deeper into this class, we can see that it inherits from this class called the Audio Processor Editor class.

So what I'm going to do is I'm going to jump into this class now.

And what we'll see is that the Audio Processor Editor class is a juice class.

And this in turn inherits from the component class.

So the component class is essentially any visual element that you have within juice.

So when you load up some type of visual class in juice or you're creating some type of visual element, it will inherit from this component class.

And what I'll do here is I'll actually show you the juice documentation because sometimes it's nice to see it this way as well, which is that we have this Audio Processor Editor class.

And then this is what's called an inheritance diagram, which shows you where in the hierarchy these classes inherit from.

So it says here that the juice Audio Processor Editor class inherits from the juice component class.

So anything that you can do with a component class, you can do with an Audio Processor Editor class because Audio Processor Editor inherits from component.

OK, so now let's just jump back into the source code here.

Here we have four functions that are in this class.

And this is pretty typical for what you would see within any type of component or visual element class.

You would have a constructor and a destructor that are called when the window is created or destroyed.

And you have this paint function, which is more for things that you would do within that component itself.

So if you wanted to write some text, for example, we have the window currently saying hello world.

If we wanted to change the color of the background, if we wanted to change the size of the text, we would do that within paint.

And then we have this resized function, which is where we would actually lay out any type of other components that we want to sit inside of this Audio Processor Editor.

So I'm going to describe that in a little bit more detail here by going to the CPP file, which is the actual implementation of these function calls.

So as I said before, first thing that we have is the constructor.

And I won't go really into what these are because I don't think that they're relevant so much for getting started.

But what we see down here is we have this set size, which at the moment is 400 by 300 pixels.

Right.

So if we just go ahead and build that now, we see that this is 400 by 300 pixels.

And if I wanted to change this, let's say I wanted to change it to a 600 pixel height and then we just rebuild this here, then we will see that now the plugin has got taller.

Right.

So as I was saying before, for people who are just getting started, the constructor is what's being called when the window is first created.

And then the destructor is what happens when the when the window is destroyed.

Now, one thing that I will say that was a common mistake that I used to think about when I was first getting started and one that I see very often for other people who are getting started is that when when we're in a DAW, let's say we're in Ableton Live or in Reaper, that it's very easy to think that if we close out the plugin, that the plugin window is actually being minimized.

That's how I used to think of it in my mind, because when you pull up the window again, all of the parameters and dials and sliders are all in the same place where you left them.

Or at least they're supposed to be if the person made the plugin properly.

So because of that, I used to think that this window was actually being minimized.

But one thing one key thing to think about is that the window is actually being destroyed.

So it actually does not exist anymore.

You'll learn a little bit more about this as we get a little bit further in the plugin development.

But one great example of where this mistake is made is when it comes to sliders that are holding some type of value.

So when it's holding that value, it's very important that the value of the slider that is sitting within this plugin window is able to relay what the value of the slider is over to the plugin processor.

Because if it doesn't, and you're relying on that value to be there, and the plugin window is destroyed, then it doesn't exist anymore.

And you're going to be trying to look for a value that does not exist.

So once again, that gets a little bit, that's jumping ahead a little bit.

But it's just something to keep in mind that as you're going through this journey, that when you're creating this window, that when you close it out, it's not minimized.

It actually does not exist anymore.

Okay.

So jumping down a little bit further, we have this function that's called paint.

So paint, I would think of as what you actually want to happen within this visual component itself.

So as we can see, we have this g.fillall, which is filling the background of the component with this green color.

Now, what I could do is I could actually change this color.

Let's just go ahead and change it to black.

And what I can do is, oh, I need to get rid of this bracket.

And what I could do is I could recompile this.

And then what we should see is now the plugin window is black, right?

And if I wanted to change this text to red, and I wanted to make it a little bit bigger, I would just do that here.

So the size of this text is being set by this g.setfont.

So if I wanted to change this from 15 to 30, and then if I wanted to change the color from white to red, this is where all of that would happen.

So paint, once again, is the place where the things that are actually happening within this component itself are being changed.

Now coming down to the resize function, we see that there's nothing that's happening inside of this at the moment.

And this brings us to another principle of these component classes, which is that components can hold other components.

So when I say component, think a window, like a visual window.

And these components can have other components inside of them.

And the way that you would lay those out is typically in this resized function.

Okay, so what we're going to do now is we're going to create our own component class.

And we're going to include it as a child within this plugin editor class that we have here.

Okay, so if that sounds like a daunting task, don't worry, I'm going to take you step by step.

And I feel confident that if you follow along, that you're going to come out successfully on the other side.

So let's go ahead and get started.

First thing that we're going to need to do if we want to create a component class is we're going to need to create some source files.

So the way that we're going to do that is we're going to go over here to our source folder over here in our Explorer.

We're going to right click and create a new C++ class.

So this is how you would do it in SceneLion.

If you were working in Xcode or Visual Studio, it essentially be a similar type of command.

So now I'm going to go ahead and create this.

And I will just call this, let's just call it square.

And I will create a .cpp and .header file for this new class that we're calling square.

And I'm going to hit OK.

And now we've created those new source files.

I'm just going to hit add.

And now we have some new source files.

And what I'm going to do is I'm just going to get rid of everything just so it's blank.

And we'll start from complete scratch.

The next thing that we need to do is we need to now include this within our CMake file.

So the reason that we need to do this is if we look at our current CMake file, we can see here that the source files that we've included so far are plug-in editor.cppnh and plug-in processor.cppnh.

And so it doesn't know at the moment that square.cppnh are supposed to be part of our build system, part of the files that we want to use and include in our project.

So just to show you here, if I go into the source folder and just open it up in the finder, here we are in our project.

You see cmakelist.txt here.

And there's the source folder.

I'm just going to double-click in there.

And there we see our class, all of our source files, in fact, square.cppnh and all of our other ones.

Now, what we need to do is we need to include this in our CMake file.

Now, the reason that you need to say source slash dot plug-in editor and slash square dot h and cpp is because the declaration that you're making inside the CMake file needs to be relative to where the cmakelist.txt resides.

So here we are in our project.

We see that we have this cmakelist.txt, and then we have this source folder.

So we need to say relative to the cmakelist.txt file, we're going into source and into these files.

If we had another folder that we just, let's say we called it code, for instance, and we put these files in here, then in our cmakelist.txt, it would need to say source slash code slash whatever your source file is.

So that's the reason why the convention is being named this way.

Okay, so now we're going to put our square class files in here.

So we've got square.cpp, source, square.h.

And now those are included.

Now, if you're in Visual Studio or in Xcode, what you're going to need to do to update your CMake build is you're going to need to invoke CMake, which is that normal command that you normally do, which is cmake-bbuilds-gxcode or whatever your command is, right?

If you're here in SceneLine, it actually has CMake integrated into the IDE, and I can just hit this little reload CMake project, and it'll actually run CMake here inside the IDE.

So that's one of the things I really love about CMake here in SceneLine.

So there we go.

So that's run, and now we're all good to go.

So now we have this square.h source file, and we're going to build this from scratch.

So the first thing that we're going to do is we're going to declare pragma once.

The reason that we do this is because what we need to do is we're going to need to include some other source files to be able to give this class that we're creating some functionality.

So right now this source file knows nothing about Guice.

It knows nothing about anything except for basic C++, and what we're going to need to do is include a graphics library from Guice in order to be able to inherit the component class, which allows us to create the window, okay?

If we had another class that was using another include that was using the graphics library, and we included it, what pragma once does is it creates us from having name collisions where you're including source files more than one time.

So it says, okay, he's already included the Guice graphics library, so we don't need to include that again.

So that's what pragma once is for.

So the first thing that we'll do is we'll just create this basic class.

The way we do this is called class.

I'm just going to call this square, and now I've created my class, okay?