Non-compliant DAWs

Developer VST 3 SDK
1

I spent quite a bit of time trying to figure out why a plugin that I would build would load fine with the VST3 Plugin Test Host but would not load in Maschine 2 or Reason Studio on Windows.

It turns out that it was a matter of naming:

foo.vst3/
  Contents/
   Resources/
     moduleinfo.json
   x86_64-win/
      foo.vst3

and

# moduleinfo.json
{
  "Name": "foo",
  "Version": "1.0.0.0",
...

You must use the same name (foo in this example) in the 3 locations: name of the bundle, name of the plugin (inside moduleinfo.json) and name of the executable.

In my case I had the name of the bundle different (outside folder) and that is causing issue (although VST3 Plugin Test host is fine with it).

1 Like
2

The name of the bundle and the name of the executable needs to be equal according to the specification.

1 Like
3

Can you point me to the specification that states this?

4

We just saw that it is not explicitly written down, but if you look at the technical documentation, you will notice that the folder name and the name for the executable are identical. If you think about it, there’s no way for the host to know how this file is called as on Windows there’s no “Info.plist” file where you can specify an alternative name for the executable. The moduleinfo.json file is optional (and came after the folder structure), so it can be used to hold this information.

5

Thank you very much for the explanation. That does make sense (for Windows). What threw me off is that the VST3 Test host that comes with the SDK works fine with a plugin where the name of the folder and the name of the executable are different, so I assumed that was the golden standard…

6

Could you please update the specification to make this explicit? I’m a developer for a fellow DAW company and we had to implement workarounds to deal with plugins in the wild that don’t conform to the (currently-undocumented) naming convention. It would be nice if we could point plugin developers to this and encourage them to make fixes so we could remove the hacky workarounds in our own DAW. Thanks!

7

Absolutely! We’ll update the specification and add a check to the validator to ensure this is taken care of when the plug-in is validated.

1 Like
8

@Arne_Scheffler Thank you so much!