Building VST3 plugin as a bundle on Windows?

Audio Plugins
1

So I have a cross-platform VST3 plugin that, on MacOS, builds as a folder containing a ‘Contents’ folder which in turn contains a ‘Resources’ folder, the plugin executable, the code signature, etc. On windows, the same plugin builds as a single .vst3 file, but here on Steinberg’s website it describes Windows VST3 Plugins as bundles containing subdirectories similar to the MacOS equivalent. Is it possible to set things up in the Projucer or Visual Studio such that the plugin is built as a bundle? Any help appreciated!

1 Like
2

Hi. What version of JUCE are you using? Think this was implemented as part of Juce 7, or a point release there-after.

Cheers

4

Thanks for the reply- I’m using 7.0.3.

1 Like
5

Hi - not sure then I’m afraid, I’m getting folders created. Maybe an option somewhere??

6

Are you using Projucer or CMake?

7

CMake - thinking about it now, this might be only implemented in that rather than projucer.

8

Yeah I don’t see any options for it in the Projucer. May need to bite the bullet and make the switch over.

9

Ok it looks like I will use CMake- would you mind showing or describing how you set up the VST3 target in CMakeLists.txt?

1 Like
10

In the juce_add_plugin section, I have:
FORMATS Standalone VST VST3 AU
VST3_COPY_DIR “${USER_ROOT}Library/Audio/Plug-Ins/VST3”

11

The Projucer’s MSVC exporter now builds VST3s as bundles. You’ll need to build the Projucer from JUCE’s develop branch in order to make use of this new feature.

4 Likes
12

Is it possible to opt out of this? kinda breaks existing plugins. Or is it mandatory for vst3 going forward?

13

Not using bundles is deprecated, but to ease a transition to a world where we are distributing VST3 as a bundle I think it would be helpful if this could be an option in Projucer rather than default behaviour so we can adopt this at our own speed. Changing where things land in a folder structure is a breaking change for many post-build systems.

2 Likes
14

FYI there is still a single “flat” file in the bundle that you can pull out or use exactly as before.

eg. if before this change you had the flat file at Release\MyAwesomePlugin.vst3,
now Release\MyAwesomePlugin.vst3 is a directory and your post-build script will blow up, but you can find the flat file at Release\MyAwesomePlugin.vst3\Contents\x86_64-win\MyAwesomePlugin.vst3, which (if you made use of variables throughout the build script) should just be a one-line change. Even if not you could just add another tiny little script before to pull the flat file out and place it in the spot where your post-build scripts expects it.

15

It would have been nice if this was mentioned in breaking changes txt.

3 Likes
16

Sorry for the disruption. We removed bundle support in version 7.0.5, released yesterday. We added bundle support back on the develop branch, and also added an entry in the BREAKING-CHANGES doc:

17

I have concerns about what happens during updates of existing plugins that have the “not bundled” version of the VST3 file. If the old file will be safely replaced, it’s would be perfect, but I haven’t tried yet.

Anyone already tried and can share his experience?