Best way to share code from plugin project


I’ve a current project where I created a plugin.
Now I will develop an other plugin but only the GUI will change and some values in the PluginProcessor.

I would like to avoid rewritting everything so I’m looking for the most elegant solution to produce 2 different plugins from the same code.

The only way I’ve found for the moment is to create 2 projucers for each skin. But I would have to modify both of them if I found a bug in the common code.

Is it possible to create a library from a common project then use it into 2 projucers where each of them will use specific gui. So the PluginProcessor and PluginEditor will inherit from the CommonPluginProcessor and CommonPluginEditor ?

That way I will end up with 3 projucers, one for the commun backend code, and 2 other for custom skin and specific backend custom code.

I reuse a lot of code across my projects and so I made myself a small JUCE module that holds all my cross-project code (mostly look-and-feel and filters).

Copy the structure of the existing JUCE modules to setup your own module - it’s fairly straight forward if you look through it carefully!

So, if I understood well you have a custom projucer where you create your classes. Then you packages them in a folder with the right structure to create a module then import this module inside your project. Right?

Not sure what you mean by ‘custom projucer’, I assume you mean a custom projucer (.jucer) project? If so, you don’t need a project to create a module - just all your source code in the right file structure (however I do have a testing project in my module).

But yes, I have a folder on my desktop called “MyAwesomeJUCEModule” which I then add to the modules list of all my JUCE projects. If I need to fix or add something for all the projects I only need to make changes in the one place.

|   +---CustomFilters.cpp
|   +---CustomFilters.h
|   +---CustomLookAndFeel.cpp
|   +---CustomLookAndFeel.h
1 Like

By “custom projucer” I meant a project to test your source. So yes it could be optional.

Thank you for the details. I will do that.

1 Like

If the two projects share a lot of common codes, then as Im_Jimmi suggested, it’s better to drop them into a new module.
If it’s really just one or two headers or cpps - I’ve tried including a header from the other project’s directory but that’ll run into JUCE AppConfig.h conflicts. A simple and git-friendly workaround is to create a symbolic link across the source directories.

1 Like

Ah yeah, thanks for the workaround and your insight.

But since I’ve like 90% of the project that is shared I will try the @Im_Jimmi solution.

I am totally on board with this being called “the Im_Jimmi solution” from now on! :wink:

1 Like

What’s wrong with including files/folders like this in your Juce projects?

#include "../../Shared/  (etc)

Yes it’s a good idea too.
But I would have to add this line in multiple file in addition to #include "../JuceLibraryCode/JuceHeader.h".
If I create a custom module, I add it in the projucer and adding #include "../JuceLibraryCode/JuceHeader.h" is enough.
But if my shared code wouldn’t be juce related I would definitely use what you say.

1 Like

I just have a “Common” folder in my main projects folder. Any shared code is there and projects use the appropriate “includes”. Simple, and easy to maintain.