I have a released instrument plugin and quite a few users are asking for an additional FX plugin that’s basically just the amp/speaker simulation. Obviously it would use much of the same code as the main instrument but there would obviously be some project differences.
I’d love it if everything used the same version number and Projucer file. But then again, there would obviously be 2 separate editors and 2 separate processors…but then using all the same audio code classes.
Has anyone tackled this kind of thing? Something tells me this will get more complicated than I’d like.
If you’re adventurous enough, I can help you convert that plugin to using JUCE.cmake (https://github.com/McMartin/JUCE.cmake) instead of Projucer, and then adding the second plugin should be easier.
My simplistic take on this is to have Juce Modules for the different layers that build the plugin.
I use this to create one-off VSTs that test parts of a whole plugin. Of course there is a manual part of creating the new projucer project and some boilerplate processor/editor code every time.
This can go as far as you want it to go, my current setup is :
(1) core custom module : licensing+logging+ binary data (font icons etc.)
(2) core dsp module : basic reusable dsp blocks (LFOS/filters oscillators etc)
(3) core plugin module : basic reusable plugin blocks :Parameters,attachments, credits page, presets page …)
(4) module for the specific plugin dsp custom code + UI custom code
I think you could go as far as creating a module also with your “base” plugin Processor/Editor, so you have only the CreateFilter method in the main projucer files, and maybe play with inheritance with your module’s Processor and Editor to have them create the “partial” processing you need. Honestly Did not go that far.
I think splitting a project up into modules is a good approach, and one I’ve been meaning to do for one of my projects where I want to have different UI for e.g. desktop, plugin and mobile.