Shouldn't bundle identifier be unique per plug-in format?

Audio Plugins
1

If a plug-in project compiles to different formats (AU, VST, …) wouldn’t it be advisable to use a unique bundle identifier per format?

com.company.plugin.vst
com.company.plugin.vst3
com.company.plugin.au

If the id was used only at the highest application layer (preferences, last used files, etc), a single id would make sense. If it’s used to identify a particular bundle at the system level however, it might be advisable to use unique ids.

Ans insights?

2 Likes
2

I know this is an old topic, but this would be a great idea. It would certainly help debugging a user’s crash since half the time they have no idea which format they loaded.

3

While we are at it: Optionally separate bundle identifiers (and plugin names) for development and release builds would be great too. This way we can actually use our own products for making music.

4

Is this at all possible now, using CMake?

We’re migrating some old plugins over to JUCE and setting the BUNDLE_ID property in CMake, but similar to @ans’s suggestion, the original plugins (not made in JUCE) use a different ID per format. This means when upgrading from the old version to the new version, hosts aren’t recognising it as the same plugin and so users’ projects will break.

I guess a workaround would be to just manually change the info.plist entry after they’re built… would that work?

5

If I search through the AudioPluginDemo Xcode project for “com.JUCE.AudioPluginDemo” I find it is used for the following…

#define JucePlugin_CFBundleIdentifier

  • The only place I can find where this is used in the codebase is in CoreMidi for creating a new device with a unique ID, I can’t see any reason this needs to be exactly same as the actual bundle ID.

#define JucePlugin_AAXIdentifier

  • The is required for AAX plugins and is used to give your AAX plugin a unique identifier, you can set this manually using AAX_IDENTIFIER in the juce_add_plugin CMake function.

#define JucePlugin_ARAFactoryID and #define JucePlugin_ARADocumentArchiveID

  • These appear to be required for ARA plugins, but again you can control these to a degree by setting ARA_FACTORY_ID in the juce_add_plugin CMake function.

The rest are just the info.plist files.

You might find you can set these using the CMake Property MACOSX_BUNDLE_GUI_IDENTIFIER? Alternatively you could try setting the Xcode attribute PRODUCT_BUNDLE_IDENTIFER for each of the targets? If this still doesn’t work you could try setting BUNDLE_ID to ${PRODUCT_BUNDLE_IDENTIFER}.

6

Thanks for the pointers! Sadly this turns out to not be an issue with the bundle IDs - even when I set the BUNDLE_ID in juce_add_plugin to the one used by the legacy plugins they still don’t load.

Digging a little deeper using the Audio Plugin Host example, it appears to fail to load the updated plugins due to the unique ID’s being different. The JUCE-made plugins include the plugin manufacterer and plugin codes in info.cid, but the iPlug-made plugins seem to contain contain something completely different.

7

Hmm I might be wrong but I think VST3 might possibly have a way to declare old plugins that should be replaced by the new plugin :thinking:

8

Ah what I was thinking of was for replacing VST2 plugins see VST3ClientExtensions::getCompatibleClasses() not sure if that can be used to achieve the same result? probably not but that might be a nice quick fix if it can be used.

9

Yeah sadly that doesn’t seem to work either!

I did find this thread from someone who seemed to be able to fix the problem but annoyingly they never posted what their solution was! [Solved] How to set unique ID of VST3 plugin dynamically? - VST 3 SDK - Steinberg Forums

There was some mention about editing the DEF_CLASS_IID macro but I don’t see an obvious way that JUCE expects that so I assume it’s not at all recommended, or even possible?

The FUID appears to be defined here: https://github.com/juce-framework/JUCE/blob/22df0d2266007bccb25d6ed52b9907f60d04e971/modules/juce_audio_plugin_client/juce_audio_plugin_client_VST3.cpp#L2487 which also doesn’t appear to have any way of providing a custom one, it’s very much fixed.

I guess the safest approach at this point would be to install the updated JUCE plugins alongside the existing iPlug ones and just inform users to manually migrate their projects across.

10

That might be a tough ask for some customers. You could try hacking JUCE to get there first just to figure out what is absolutely needed then report back and maybe we can see what we might be able to support in the library - no guarantees obviously.

You’ll also need to test in a lot of DAWs. I recall WaveLab used to ignore all the identifiers and just use the filename to recognise if the plugin was the same!