Hello!
I know that there is a demo audio plugin coming with Juce. But if I remember correctly, Jules advised not to use his demo as a good example.
Therefore I wonder: Does anyone have a good audio plugin template, that he wants to share?
Also it would be interesting to have an example, that does not use the timer in order to update the GUI.
And maybe even something that implements “undo” functionality 
MarC’s solution is very thorough and flexible and well worth a look.
I am currently in the process of updating my old plugins, trying to unify them and improve the coding style. In a somewhat similar fashion to MarC I have also created a parameter class, it doesn’t yet deal with non-linear mappings but does have some other advantages. I have nearly completed this procedure for my Tremolo demo app which you might want to take a look at.
It uses juce::Value’s internally so parameters can easily be connected to UI objects. To avoid the Value::Listener callbacks interfering with the audio thread I have created a small parameter-queue type class that gets added to from the message thread and then dispatched from the audio thread. This does use a CriticalSection for adding and removing values to/from the array but I don’t think this will be an issue for a relatively small number of parameters and if they are not being thrashed. The lock is not held for very long. In any case I have thought about changing this to a lock-free, AbstractFifo based queue which would avoid the locking all together.
Because the Value’s are encapsulated by the PluginParameter class, creating and managing a set of parameters is almost entirely automated. There is a config page with a few arrays that specify the parameter’s names, values etc. but after that they are all managed in loops. Adding a parameter is as simple as defining it in the “Common.h” file.
In your editor you can then simply get a reference to the Value object and hook it up to sliders etc. to automatically control the parameters. Changing the parameter will add it to the parameter queue and then you can respond to it properly on the audio thread via the parameterUpdated callback if you need to update internal variables such as phase increments etc. all in a thread safe way. Obviously its not wise to do anything too time consuming in here, the filling of buffers in the Tremolo demo is borderline and could be implemented on another thread.
How you update your UI will depend on your exact needs but generally I use Values (and their internal ChangeBroadcaster/Listener implementations) to update parameters and Timers to update constantly changing things like scopes or meters.
Some improvements will need to be made to the JUCE wrappers and AudioProcessor class to properly represent parameter ranges and values in the hosts and this is discussed here.
Hope this offers some potential ideas.
Thanks Marc and Dave,
This is really helpful
Hi again,
Right now I am going through Daves tremolo plugin. It looks very nice and well structured. I think I will implement a similar parameter handling
But so far I can give feedback on the compilation. It all worked fine except an ambiguity in PluginEditor.cpp. There you have the line
Visual Studio 2008 does not like that, because Rectangle is defined both in namespace “juce” and “drow”.
So I added the prefix “juce::Rectangle” and then it was OK.
Hello Dave,
More feedback on the tremolo plugin.
A feature is missing: Parameter automation is not working. I just tested with loading the VST in “Sonar”.
The reason is I think, that you are not using “setParameterNotifyingHost”. Therefore the host is not aware, that the user is changing the paramter.
Thanks, its probably that nasty #define I have in there to avoid explicit namespaces all over the place. Was always a bit of a hack but I don’t think you can use typedefs for template classes like that. Might be able to add some using directives to sort it out and if not I’ll definitely undef Rectangle at the end of the header, it was a bit silly not to in the first place. I’ll tidy it up next time I’m in a Windows build.
Ah yes, I didn’t get as far as sorting automation out. But as far as I can remember calling sendParamChangeMessageToListeners in valueChanged should work, or I might have to add that only if the value is changed from the UI. It will also need calls to begin/endParameterChangeGesture on UI changes.
Thanks for the pointers.
