Noise Gate Pt. 8
We’re puttering along pretty smoothly at this point, with the ability to actually use our Noise Gate finally coming to fruition. On the JUCE “tutorial” side, this is where it ends.
It’s all up to US now!
So what! I bet we can build a purty looking GUI.
If you’re looking for the Project up to this point, you can find it here.
This is where we’ll diverge once more from the way we regularly do things, by creating a basic GUI that doesn’t take a lot of work.
There are two ways to look at generating GUI in JUCE (that I know of).
There’s a great talk on it here;
Julian talks all about the wacky and wonderful things you can do with the GUI in this, and in part 2, which i’ll link below.
And you can learn how to make a house here;
I don’t know exactly why you’d do this, but hey, what do I know.
For this, you can also look at Martin Robinson’s book, How to do everything in JUCE except audio, or “JUCE for Beginners”.
Much of the way we make GUI in larger projects are with the sort of things Julian talks about here. We’ll see if we can make it in two different ways, the original, basic way, and the more advanced, purtier way.
We start with the basic way.
The Basic Way
If we go to the Documentation and go to GenericAudioProcesorEditor, this one does what it says it does on the box. It creates;
So we can use this to take anything that we added to the AudioProcessor, and spit out a basic enough GUI to check functionality. While we can definitely add to this, it’s a good enough start to check that everything works the way that we want it to. For instance, in our version currently, we don’t actually have any control over any of the levels. They are set and are not able to be changed in most instances (some DAWs give you a generic audio editor by default, but I’m in logic and tools so it won’t currently do that work for me. This is the way the tutorial does their graphics.
For debugging, this is probably the way you want to start. In our instance, I don’t think anybody would be particularly interested in leaving it here. I’d like to look into creating a custom editor, to learn how to map sliders and such so that we can control it, and change all the colours and such ourselves!
The Better Way
Our graphics start here in the paint function. This will draw shit all over the screen.
We’ve got g.fillAll (the g is for gRaPHics), and it will paint the entire window. A good way to start, as the JUCE GUI is layered, meaning we can paint, and then paint something else, somewhere else, in another colour (or the same colour) if we want to.
We’re painting our “getLookAndFeel.findColour” which has to do with a specific sort of template code that you can set. getLookAndFeel is super useful to use when painting lots of elements, as it lets you essentially set your own defaults for buttons, text and whatnot, and simply refer to the template rather than have to re-write the RGB or whatever colour code you use each time. Which can be a pain if you’ve got difficult functions, unlike me, Mr. Primary Colours.
Once we’ve painted everything, we change our colour with setColour (and set it to the JUCE white)
Then we change our Font size to 15. I’d LOVE to show you how to implement a font at some point, when I work out the bestway to do it.
Then we drawFittedText, which is text that fits inside a particular textbox. If you’ve used Adumbo Indesign, this’ll help you to imagine it. We don’t have to drawFittedText, as there are plenty of other ways to write text detailed in the documentation here.
So that’s our basic model. We’ll get rid of this crud so we can start anew.
Here’s the reason that our GUI looks the way it does. If you’ve got the proper version of JUCE, you won’t get that splash screen that fades up for the first few seconds when opening, but I’m too cheap to splash out for it at this stage. My oh my I can’t wait till I can get it though!
This code says that we paint our editor with a particular sequence (g)
We can use the Graphics object to make lines, change colours, fill the screen, draw shapes and much more.
The simplest use of this is to redraw some stuff ourselves. Delete everything within the brackets so your Paint function looks like so;
Painting Graphics to the Object
Looking in our PluginEditor.h, we have;
With that, we can see that we have declared a paint function (the one we’re using) and a resized function, which we aren’t really using, but we’re abstracting it nonetheless. If we check out the paint component…
This has more to do with the actual computer than it does our plugin, as it’s how the plugin is actually conveyed. We also have some cool functions in here like Mouse Enter and keyPressed and what not, we’ll explore that as soon as we get it all working.
As we’ve got paint and resized going, let’s use paint for now.
We start in our paint method by writing g. (as this was the parameter from the Graphics pointer in the documentation). We can actually use any of these Public Member functions from the Graphics class, it really depends how we’d like our text to look.
To stick as close as we can to the basic version, I’m going to go with drawFittedText, just like the original text, which takes a string, the area, the justification, and as a 1 line string.
When that’s completed, with getLocalBounds setting my draw size to the entire Plugin window, and then being centred in the middle of that, it should read as follows.
Now our plugin looks like this;
Pretty gorgeous, no? Now we could fix the text, make it white, change the background and do any number of crazy things. Again, this is just one way to write text. You can probably imagine how we want to build our GUI now. You’re probably thinking that you’d just use some photoshop PNG’s to paint the whole look of the GUI, and that’s true too, but these are the fundamentals, and it’s also a pretty robust form of the GUI. You can get away with a lot more than you think with this!
To finish up this part, I’m going to get it to match my regular sort of branding and colours, with the Yellow background, with black and white font.
Colours and Branding
If we Command+Ctrl click on colour, we’ll get taken to the JUCE documentation of their implementation of Colour. There are a number of different ways to define a colour, whether using RGB or using JUCE’s own colour system (which isn’t half bad!).
If we use setColour, then the next actions we take (until we change colour) will be using our colour. I want to fill the background, then write the text, so we’ll setColour to yellow, and then setColour to Black, and then finally setColour to white. It’s somewhat tedious, but hey, we learn this way.
For now, let’s use the JUCE colours for the text, and then I’ll go in and grab the RGB for the yellow if it looks shit.
For ease of use, I’m going to use fillAll, with the current brush. That means I first set the colour, then I fill all, then I change the colour again if I want to write something else.
Sweet baby gebus.
So it looks absolutely horrible. I mean we could probably look into making sure the yellow isn’t so awful, and the font is different and better. There’s a lot really…
You can see I’ve just Justification::centredRight, to sort of mixed levels of success. As far as I’m aware, you can’t actually change colour halfway through some text, so this might be the best we have right now.
In terms of justification, it’s another good one to have a look at in the documentation. In terms of using it, you’re probably thinking that using pixels for exact positions is better, and it CAN be, but justifications and getLocalBounds sort of allows us to make it so that if the user resizes the window it still looks good. I’m yet to work out just how much of this kind of positioning is used, though I know splitting the window into boxes and drawing your positioning from that is incredibly popular.
Who knows. We can at least improve it by beefing up the size a bit, changing that yellow and the font.
The Right Yellow, and Font…and Size.
To change our size, we can call a couple of different functions, depending on whether we just want the next text to change (kind of like setColour) or whether we want the default drawing text to change.
We can use this implementation to change the size. Let’s do dat. In this part, I’ve used setFont(60.0f) because setFont takes a float in this implementation. I’ve also moved the Justification to centredLeft and Right, AND changed the size of the actual window to something a little better than a plain ol’ square.
And here’s the pain code now. I thought I’d try goldenrod, but I’m also going to do the RGB in a moment.
While that looks a bit better, the colour is really killing me. Jumping into the colour with Control + Command and clicking on Colour, I find what I’m looking for.
So I can use this by typing;
Now we’re starting to look pretty damn good! All we’ve got to do now is get the spacing right, and the font! We’re so close!
I think I will in fact separate out the font element, as it involves diving into the projucer quite a bit to get it all working. Well, you’ve got to drop in a file and set a look and feel and whatnot. But I think to begin with, we’ll look at sliders, and making sure we can send across those values to get something that pretty closely resembles a working, actual plugin.
If you’re diggin’ this, or if you had any errors, shoot me a message and I’ll pretend I can help you (I will try!).
See you next time!
For those of you that are interested, here’s the JUCE pt. 2 of the Graphical User Interfaces with JUCE.