GUI Component Instead of Plugin Editor for Audio Plugin

Hi, I am fairly new to JUCE, making my first audio plugin, I was wondering if there was a way to use a JUCE GUI component to create the interface instead of doing it in the PluginEditor.cpp and .h files. I found this post: GUIs for new Audio Plug-in projects
but when I follow the instructions given it creates some errors since the constructor for these two types of classes is not the same.

The errors are being caused by the fact that the plugin editor class takes a pointer to the audio processor object as it’s input, while the GUI component does not. Could I fix this by simply adding this input to the GUI constructor and hooking up the parameters from there, or is there something else I need to do?

Just tried adding the processor pointer as an input to the GUI constructor method. On the following line:

AudioProcessorEditor* ReverbPluginAudioProcessor::createEditor()
return new PluginEditor(*this);

I get the following error:

Cannot initialize return object of type ‘juce::AudioProcessorEditor *’ with an rvalue of type ‘PluginEditor *’

I try changing the return type for the function to PluginEditor*, but this does not match with the superclass that createEditor is inherited from.

It seems that this method will just keep breaking things and I assume there is a better/correct way for doing this. Please let me know. Thanks!

It should still work like that…
The point of AudioProcessorEditor* AudioProcessor::createEditor () is to return a specialisation of an AudioProcessorEditor. The error message suggests, that your PluginEditor does not inherit AudioProcessorEditor.

When you create the new component in the projuces in the Tab “class” change “parent class” from public Component to public AudioProcessorEditor

Hope that helps…

EDIT: sorry, that’s not all, because the new Component lacks the reference to the processor. You don’t need it, if you change the AudioProcessor::createEditor() method, but it is a very handy thing, so I would keep it:

  1. Add a member to the Editor’s header file in that section:

     //[UserVariables]   -- You can add your own custom variables in this section.
     // This reference is provided as a quick way for your editor to
     // access the processor object that created it.
     AudioEffectAudioProcessor& processor;
  2. In the class tab as written before change parent class from public Component to public AudioProcessorEditor

  3. Add Constructor params: AudioEffectAudioProcessor& p

  4. To initialise the base class AudioProcessorEditor with the processor reference add in Member initialisers: AudioProcessorEditor (&p), processor(p)

  5. If you chose a different name for your new AudioProcessorEditors descendant, use that new constructor in AudioProcessor::createEditor:

     AudioProcessorEditor* AudioEffectAudioProcessor::createEditor()
         return new WhateverNameYouChose (*this);

Hope that’s better now…


When you follow the above instructions to link the GUI component to the AudioProcessor, do you have to delete the former PluginEditor .cpp/.h files? I’m not exactly sure why you can’t use the Projucer GUI designer directly on the PluginEditor component itself. Seems like it would be more straightforward. Unless its advised to build the GUI separately from the PluginEditor and link the two? Any thoughts on this issue?

I think the issue is, that the Projucer is not meant to convert an existing Component to be edited in the GUI editor. And the AudioProcessorEditor boilerplate comes up without the hooks to be edited. That’s why you have to tweak it manually.
It would need an extra switch in Projucer on creation of a Plugin project to activate the GUI editor on the ProcessorEditor.

And to answer the question, yes, the original PluginEditor files are obsolete then.


1 Like

Thank you, that’s very helpful. I think that helps direct my workflow to first start by designing the GUI in a separate component using Projucer and then just copying the parts over to the corresponding sections of PluginEditor after the layout is fully designed.

Yep, that will work. Just be wary, when you save the project, the Projucer will overwrite everything outside the [USER_xxx] blocks.
In my workflow I have to use the save project often, to add new classes, to bump the version number etc.