Multiple versions of the same plugin

Audio Plugins
1

It's giving me a headache even contemplating it, but I want to do multiple versions of a plugin.  The code itself will just be different with some #ifdef stuff.  But I'm going to need two binarys, presumably two jucer files as well?  Has anyone done this, is there any sane approach?

2

I have defined a BETA_VERSION to control different parts of the build as well as giving my plugin a different name and pluginID in AppConfig.h

 

On Mac I get away by looking up the preprocessor macro in the post-build script and adding a "_beta" to the final bundle name.

 

I haven't looked for a similar procedure on Windows yet

3

We have almost the same problem when we want to provide both 32bit and 64bit versions of the same plugin. This still requires two different .jucer files on Windows platform. So pretty much same questions. How do you best approach this?

4

Oh, so at least I don't have that problem.  I do two versions of the windows build but with two MSVC targets in the same jucer file. 

5

I seem to be up and running with my two version system now:

  • I've created a subfolder of the main project
  • Symlinked everything from the folder above into it apart from the build folders
  • Added a pre-processor called gpp to some of my configuration files to create alternate versions
  • and for now manually edited the jucer file into a new version though it'd be nice to automate that.

onqel - how do you give it the new plugin id information when you build the beta version? manually or some magic?

6

In AppConfig.h you have a user code section that won't be overwritten by the Introjucer,

there you can change the plugin information depending on your preprocessor definition.. 

Note: for AU versions you also need a script to make a custom .plist file for your alternative version..

 


//==============================================================================
// [BEGIN_USER_CODE_SECTION]
// (You can add your own code in this section, and the Introjucer will not overwrite it)
#if defined BETA_VERSION
    #define JUCE_DONT_DECLARE_PROJECTINFO 1
    #define JucePlugin_Name                     "TSE X50 BETA"
    #define JucePlugin_Desc                     "X50II_beta"
    #define JucePlugin_ManufacturerCode         'TSEb'
    #define JucePlugin_PluginCode               'B502'
    #define JucePlugin_AAXIdentifier            com.TSEAUDIO.X50IIBETA
namespace ProjectInfo
{
    const char* const  projectName    = "X50IIB";
    const char* const  versionString  = "2.4 RC4";
    const int          versionNumber  = 0x20400;
}
#endif
// [END_USER_CODE_SECTION]
7

Ah - cool - that might be a better solution in the long run !  Cheers!

8

I almost have this working, except it looks like VST hosts look in the bundle id to get the plugin name, is there a way to create different plists for each build?

9

@jules … could this ‘user section’ of AppConfig.h be moved to an optional include file in the user Source directory? I don’t really want to check the AppConfig.h file into source control…

10

Just add another exporter in Projucer

11

xcconfig and props files are your friends here! (for mac and win, respectively)

2 Likes