I’m working on a JUCE app which is using tracktion engine. I’d like to have a plugin version of the app so I can load it in DAWs as well. I’ve reading this post Using the Tracktion engine within a plugin? and I actually implemented a plugin version of the app which seems to work. Running tracktion engine inside a plugin still seems to have some limitations (see post), so I’d like to keep the normal standalone version and the plugin version. However I did not find the proper way to structure the code so that I can re-use it properly. I need some advice on how to do that
What I tried so far:
I have the code in two separated project folders at /root/project/ and /root/projectPlugin
I guess I should have a common code folder at root/common_src/ and import files from there. However, the files I’d put in root/common_src/ need to include JUCE header (normally would be #include "../JuceLibraryCode/JuceHeader.h") and I can’t do this type of relative import because for the two projects the header would be different.
If I have the code in one project /root/project/Source/ and then in the other I import source files from the first one (dragging the folder in projucer), then for the files in /root/project/Source/ it imports the header of the normal project instead of the Plugin project.
Also I’d like the binary files to be in sync for the two projects. Have no idea how to go about that.
Maybe there is a way to have a target for the plugin version in the normal app project. That’d be the best case but I don’t know how to do it (and using the standalone-plugin app version is not suitable because remember I want to keep a normal version of the app because running tracktion inside plugin seems to have some limitations).
Maybe a solution would be to write a script that will generate on the fly a projucer project for the plugin version, copy source files from the original app in some temp folder, and compile it. How would I deal with binary files in this case. If that’s possible, that would also be a solution for me.
This is (one of) the biggest limitation(s) of using Projucer: you can’t manage several projects as one.
If you don’t mind moving away from Projucer, you can have a look at FRUT (I’m the author), which allows you to build JUCE projects using CMake. You’ll be able to convert your .jucer files into ready-to-use CMakeLists.txt files, then combine them into a single CMake project.
If you have any question about FRUT (and CMake), or about building a JUCE project (even with Projucer), don’t hesitate to ask me (here or via PM), I’m always happy to help!
So the only remaining problem now is how to share the binary data across the two projects. Ideally I’d have binary data on the first project and include it somehow from the second one. I’ll do some experiments.
I’ll also have a look at FRUT to see if it can help me.
I managed to do it
The trick is to not include binary data in the juce header (untick option in Projucer) and then manually include binary data when needed like #include "../JuceLibraryCode/BinaryData.h" (use relative path so files from project A will include binary data from project A). Then I also need to add BinaryData.h and BinaryData.cpp in projucer file for project B (which reuses from A) and in this way it gets compiled.
I think this setup is enough for my needs right now. Thanks for your feedback!
Glad you got it working.
Just another thought, would using a single “Plugin” project and then the “Standalone Plugin” target be suitable for this? I think you can create your own “StandalonePluginWindow” class to act as your top-level component.
Thanks, according to the info in this post Using the Tracktion engine within a plugin? I should assume that using standalone target of plugin would not be equivalent to the normal app because apparently using Tracktion engine inside a plugin still has some limitations. It could be that these limitations are not a problem for me, but I can’t be sure so far so I prefer to keep the two versions of the app (as a plugin and as a normal app).
