This is weird. I have 13 plugins using VST3 bundles since that change was introduced. They all have had no problem in the bundle format.
I am in the process of recompiling with Visual Studio 2026. Now, some of the plugin bundles function as expected, but some don’t! The ones that don’t are loaded into the DAW, but the editor will not open.
If I use the raw .vst3 file directly without the bundle everything works normally. I have gone back and forth through my settings to no avail. I cannot find a difference between the ones that work as a bundle and the ones that don’t.
Which host(s) are you using for testing? Are the bundles broken in all the hosts you’ve tried?
Given that the plain plugin binaries still work when moved out of the bundle, my best guess is that the problem is related to the moduleinfo.json. If you still have copies of the plugins in bundle format from an older working build, are there differences in the moduleinfo.json between the old and new plugins?
I have tried in my own DAW (JUCE/TracktionEngine), and in Waveform, with identical results. I have examined the json files, and can’t spot any diference, other than the obvious numbers, plugin name, etc.
Have you tried clearing any cached plugin lists and rescanning the new bundles? Maybe some identifying property of the plugin (internal UIDs) has changed and now conflicts with stored plugin metadata cached by the host. It’s conceivable that Waveform is treating the un-bundled plugins as ‘new’, because the path to the plugin binary itself is different.
You could also try checking the old+new plugins in Steinberg’s VST3PluginTestHost, which is part of the VST3SDK distribution: https://www.steinberg.net/vst3sdk
The test host includes an ‘info’ window that shows information about the plugin. I recommend comparing the info for the working and broken plugins to see if there are any differences.
I’ve discovered that the AudioPluginDemo works just fine as a bundle with everything consistent. So I am now going through my code in comparison to see what the difference might be.
I’ll report back once I’ve uncovered what the issue is.
I scrapped the original Projucer project and created a new one. I copied the source files into the new project. Then, after compiling, the plugin ran and opened without issue.
I will know for sure after I do the same on a few more plugins. But, this seems to be a fix.
Its puzzling because I always compile a new Projucer each time I download the JUCE develop files. And you would think the new Projucer would map the existing “.jucer” file to any new requirements. And perhaps it does. But, right now, it is at least a possibility that some detail was missed in the translation.
Anyway, its a good idea at all times to start over fresh when getting strange results.
I’ve created new Projucer projects for two more plugins. All are working as expected after the transplant into a new project. So, the new project method is the one to use for this particular fix. At least, it works for me.
I will include both the previous and new jucer files for on of the problematic plugins. Hopefully, you can see something significant. First is the previous version.
It looks like the preprocessor definition JUCE_VST3_CAN_REPLACE_VST2 is 1 in the old file, and 0 in the new one. This flag affects the unique identifer of the plugin, so this is almost certainly the cause of the different behaviour. So, now we need to work out how this got changed, and make sure that things continue to work properly when this flag is restored to its original value.
Please could you clarify what you mean by “new” and “previous” in your post, since it sounds like there are at least three different project versions (sorry, I was vague when I asked to see the project files)
The original project (working)
That project file loaded in Projucer 8.0.10 and resaved (broken)
A new project file created from scratch in Projucer 8.0.10, copying over settings from the original files (working again)
I’m assuming that “previous” refers to option 1, but it’s unclear whether the “new” file corresponds to option 2 or 3.
There have been a couple of plugins that work unmodified. But I am pretty sure I’ve recompiled them in the past few months. All the “broken” ones were last compiled, I believe, in February.
I build my plugins only for my own use now. All I need is VST3. Backwards compatibility is not required.
When I bump another one and it is “broken”, I’ll first try setting JUCE_VST3_CAN_REPLACE_VST2 = 0. I will let you know how it goes.
Or, …you know what? I bet you are correct. The plugins that are not “broken” probably never had JUCE_VST3_CAN_REPLACE_VST2 = 1 in the first place. I will report back if that is the case.
