Working on a project that’s both an aumu and aumi AU Type (shares 99% of code).
What’s the best way to setup a project like this?
My initial thought was to just create a copy of the .jucer project change the required attributes and the target project folder to something like Builds/MacOSX/aumi. This is a little messy because I’d have to keep both .jucer files in sync when adding deleting source/resource files etc.
Next idea is to just write a little utility (.sh) that creates a copy of .jucer file, modifies the xml then uses Projucer cmd interface to save out the project followed by an xcode build.
All I really need is to create the binary before making a release, all testing debugging can be done on the aumu version.
Just want to get some thoughts/ideas on how to manage this sort of thing and if anyone has done something like this before so that I don’t have to re-invent the wheel here. Really wish aumu(s) could send out midi and or just be able to get loaded as a midi effect (same binary) in Logic X, but that doesn’t seem like it’s going to happen.
Thanks
You could create two configurations (say release_aumu and release_aumi) and define JucePlugin_AUMainType in each configuration in the preprocessor definitions. Then depending on which configuration is built will determine which plugin is built.
Another method is to create a JUCE module that contains all the shared code and have two projects both pulling in the same module. Reduces some of the repetition that would be repeated by simply creating two projects. i.e. adding / removing source code, libraries, etc. can be done in the module which will be reflected in both projects.
In the past dealing with similar things I have to say I’ve always just used a script - I made a python module that allows easier editing and re-saving of the JUCE project. So I would loop through make a change then build until all the builds are done.
@hhit Sorry for being late to the party. I hope you have found something that works for you, but in case you haven’t, I invite you to have a look at FRUT (I’m the author), a set of tools that make it easy to build JUCE projects using CMake instead of Projucer.
I made a simple example to explain how you can use FRUT to have a project that’s both an aumu and aumi.
- I started by making a new “Audio Plug-In” project in Projucer called
TwoAUsInOne, and tweaked its settings to make it an aumu: TwoAUsInOne.jucer.txt (3.2 KB)
- Then I used
Jucer2Reprojucer (a utility executable from FRUT) to convert TwoAUsInOne.jucer into a CMakeLists.txt file: CMakeLists.txt (4.5 KB).
- Finally I modified the
CMakeLists.txt file a bit:diff --git a/CMakeLists.txt b/CMakeLists.txt
index 6772ca1..70ba967 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -11,2 +11,13 @@ include(Reprojucer)
+if(AUMI_VARIANT)
+ message(STATUS "Configuring aumi variant")
+ set(plugin_characteristics "MIDI Effect Plugin" "Plugin MIDI Input" "Plugin MIDI Output")
+ set(plugin_au_main_type "kAudioUnitType_MIDIProcessor")
+else()
+ message(STATUS "Configuring aumu variant")
+ set(plugin_characteristics "Plugin is a Synth" "Plugin MIDI Input")
+ set(plugin_au_main_type "kAudioUnitType_MusicDevice")
+endif()
+
+
set(TwoAUsInOne_jucer_FILE
@@ -38,5 +49,3 @@ jucer_audio_plugin_settings(
"AU"
- PLUGIN_CHARACTERISTICS
- "Plugin is a Synth"
- "Plugin MIDI Input"
+ PLUGIN_CHARACTERISTICS ${plugin_characteristics}
PLUGIN_NAME "TwoAUsInOne"
@@ -49,3 +58,3 @@ jucer_audio_plugin_settings(
PLUGIN_AU_EXPORT_PREFIX "TwoAUsInOneAU"
- PLUGIN_AU_MAIN_TYPE "kAudioUnitType_MusicDevice"
+ PLUGIN_AU_MAIN_TYPE ${plugin_au_main_type}
PLUGIN_VST3_CATEGORY
to make the plugin characteristics and the AU type configurable: CMakeLists.txt (4.8 KB)
- Now I can call
cmake .. -DAUMI_VARIANT=ON to make the aumi plugin
This might seem quite complex, especially if you are not familiar with CMake, but I think it will scale way better in the long run than having 2 .jucer projects.
I hope this helps, and if you have any questions, or are looking for ideas, feel free to ask me!
