Can someone please explain me what are the four sources of JUCE and how they interact with each other (I’m talking about PluginProcessor.ccp, PluginProcessor.h, PluginEditor.ccp, PluginEditor.h)?
1 Like
The simplest way (for me) to think about it is as a few ‘rules’.
The processor is the plugin & the editor (which is created/destroyed by processor) is a representation of the processor’s data.
Anything you want to do with sound goes in the processor, and anything you want to do with the GUI goes in the editor.
You should not make changes to sound directly from the editor.
You should not make changes to the GUI directly from the processor (the editor should periodically get data from the processor to represent).
I hope that helps.
check out the cherno’s c++ series on youtube to learn more about the difference between .h and .cpp files
Ok thanks a lot
Thanks. Can you tell me the difference roughly in a few words?
“The convention is that .h files are declarations, and .cpp files are definitions.”
The PluginProcessor is the class describing the actual sound processing or the sound generation in case of a generator or instrument. The actual class inside that file has a generic name formed of your PluginName you supplied. It inherits juce::AudioProcessor to function correctly.
The ProcessorEditor contains the class describing the GUI. It is generated in a factory function, that was also autogenerated using your PluginName and inheriting juce::AudioProcessorEditor.
The ProcessorEditor is optional. You can either supply none, in which case a host might show a generic control panel, some hosts just show nothing.
Or you can return a juce::GenericAudioProcessorEditor, which shows all parameters, so you can already interact with your plugin (highly recommended for prototyping).
Or you can use a third party GUI engine, like my PluginGuiMagic or Blueprint (JavaScript).
Always code so that processing works with no PluginEditor present!
My understanding might also still be incomplete but I see it like this:
Every C++ program starts with a main.cpp
You don’t see that when the projucer makes a new project for you because it’s somewhere in the JUCE files or so.
Then whenever you want to outsource some information from this main.cpp you make a header file with your new information, like if you want to make a file that only deals with audio buffers and you call it Buffer.h
Then you might go ahead and include it along with the other things in your pluginProcessor.h at the top of the file.
#include “Buffer.h”
That copy-pastes all the stuff from Buffer.h at exactly that point.
At this point you are already pretty much settled. You can make everything in a header-file, namespaces, classes, variables, and you can create instances of those objects from your pluginProcessor.
But you can potentially also make a cpp file called Buffer.cpp if you want to.
Then you’d have definition and declaration seperated. I personally don’t see which advantage we gain from doing that because I don’t like to jump around between files when I write functions, but it’s useful for something I guess. However you can just look at pluginEditor and pluginProcessor’s h and cpp files to get an example for that
There is a lot of confusion around.
It depends what you mean with “program”. An executable indeed starts at the so called main entry point, which is defined as int main (int, char**) { ... }.
A plugin is not a program in that sense. It is a library offering additional functionality to the host. The interface how the host will call the functionality is the API. Instead of a main function (which is already running as the host’s main) there is a factory that creates the plugin. You find it at the end of PluginProcessor.cpp:
// This creates new instances of the plugin..
juce::AudioProcessor* JUCE_CALLTYPE createPluginFilter()
{
return new MyFooAudioProcessor();
}
Hope that helps
1 Like
that was unexpected! 
thank you. i really always thought the main.cpp was just not exposed to the juce-user