CMake .vst3 is a folder (Windows)

1

Hey – Quick question.

During the process of switching to CMake I’ve noticed that on windows my .vst3 files are now folders.

This seems like a recent change as my VST3 used to just be Plugin.vst3 on windows without any folder or contents.

I’m not seeing any other plugins in my vst3 folder deployed in this manner (all are binaries) – I’m wondering if others are shipping .vst3 in this way and if we’ll have issues? It appears they load fine in Ableton but I’m not sure if this is the case with all DAWs?

2

I can say in REAPER .vst3 folders load also fine.
While quickly checking my Common Files/VST3 folder I noticed SonoBus installs as SonoBus.vst3 folder, that’s the only one I have there that’s not only a binary though.

3

An excerpt from Plug-in Format Structure - VST 3 Developer Portal :

In particular, see the note at the bottom

image
image815×584 48.1 KB

2 Likes
4

This is a great change but I’ve run into compatibility issues in Reaper 6.56, which is not that old.

It does not get detected as a plugin when it’s a VST bundle folder. However, I can create a bunch of regular, nested folders in my VST3 and after placing the binary inside, it gets detected.

So what’s different about the .vst3 bundle folder vs a regular folder and why is does it present compatibility issues?

5

To this, only Reaper developers can give a definite answer, but my guess is that usually folders don’t have “.vst3” extension, thus when an old Reaper version does the scan for VST3s, it might do something similar (pseudo code):

for all entries in VST3 search path
{
    if (entry.get_extension() == ".vst3")
        try_to_load_it();
    else if (entry.is_directory())
        recurse_into (entry);
}

With this kind of code, any directory that has “.vst3” extension, gets ignored because it cannot be loaded as a VST3 binary file and is not recursed into for searching binaries inside it.

You could try renaming your bundle folder and give it any other extension to see if my guess is correct

6

The plugin works fine even if I name my nested folders with a .vst3 extension.

Here is one of the tests I did:

  1. Copy myplugin.vst3 bundle into the VST3 dir - not detected
  2. Delete the bundle and create a regular folder named myplugin.vst3 in the VST3 dir, then copy the contents of the original bundle inside - plugin detected.

So it seems like the bundle container on Windows is having issues but I can’t figure out why it’s different than a regular folder.

7

I found the issue. The myplugin.vst3 bundle created by CMake has a ‘system’ attribute on the folder. Once I remove it, the bundle gets properly detected.

Is this a Cmake flag that I am missing in my configuration or is there a reason for marking the bundle with a system attribute?

1 Like
8

The recent folder structure of VST3 is really ugly and a step backwards. Apart from incompatibilites with hosts it allows users to mess around in your plugins and make them crash or edit them in an unwanted way.
It’s another bad design decision made by the Steinberg guys.

It is still possible to build them in the classic way. I remember when I built a project with the VST 3.7 SDK (without JUCE) had to do some changes to the VST3 SDK to bring back the old behavour. If there is interest i can check out what I did.

9

Well, the actual layout is not their invention. It’s just consistent now with the bundle format on mac platforms and as it was for AAX plugins on windows for a while.

See also this thread:

I forgot the source but I read recently that the vst one file format is to go away in future hosts (latest Cubase already started?)