VST 3.6.10 Plug-in format change

Audio Plugins
1

Looks like Steinberg have changed the packaging for VST3 to be like AAX…

Plug-in Format

For the macOS platform

On the macOS platform, VST 3 Plug-in is a standard macOS bundle, its file extension is “.vst3” and has the following folder structure:
MyPlugin.vst3/Contents/Resources/ => folder contains all additional resource files useful for the Plug-in
MyPlugin.vst3/Contents/MacOS/ => folder contains the Plug-in’s macOS universal binary (Mach-O)
MyPlugin.vst3/Contents/Info.plist => the Plug-in’s property list
MyPlugin.vst3/Contents/PkgInfo => specifies the type and creator codes of the bundle (optionnal)

For the Windows platform

On the Windows platform a VST 3 Plug-in is organized as a bundle like package format (simple folder), its file extension is “.vst3” and has the following folder structure:
MyPlugin.vst3/Contents/Resources/ => folder can contain resource files useful for the Plug-in
MyPlugin.vst3/Contents/x86-win/MyPlugin.vst3 => folder contains the Plug-in binary (32 bit dll for the i386 architecture)
MyPlugin.vst3/Contents/x86_64-win/MyPlugin.vst3 => folder contains the Plug-in binary (64 bit dll for the x86_64 architecture)
MyPlugin.vst3/Contents/arm-win/MyPlugin.vst3 => Proposal: folder contains the Plug-in binary (32 bit dll for the arm architecture)
MyPlugin.vst3/Contents/arm_64-win/MyPlugin.vst3 => Proposal: folder contains the Plug-in binary (64 bit dll for the arm64 architecture)
MyPlugin.vst3/desktop.ini => used to set custom icon in Windows Explorer
MyPlugin.vst3/Plugin.ico => customized Plug-in icon

In previous SDK’s the Plug-in was defined as a single dll file with the vst3 extension. This is deprecated since version 3.6.10.

The file desktop.ini should contain:

[.ShellClassInfo]
IconResource=Plugin.ico,0
and you should then change their attributes with this command line (s for system to make sure that Windows will use it for the folder/bundle, r for read-only and h for hidden (optional)):

attrib +s +r +h desktop.ini
attrib +r +h Plugin.ico

I guess you’ll update the scanner code…??

Cheers,

Rail

1 Like
2

Is there any information how this will affect backward and forward compatibility? On first glance this looks like it can’t be used until all hosts have updated. What is going on?.. does Steinberg have “the week of breaking changes”?

3

I can’t even get the new VST3 bundles to build in the latest VST3 SDK on windows. I’m using

cmake ..\VST3_SDK -G "Visual Studio 15 2017 Win64"

but the resulting solution fails to link at the very end and I’m just getting bundles with no code inside them. Anybody have any ideas?

4

does Steinberg have “the week of breaking changes”?

They call it “minor version release.” And you wonder why devs didn’t flock to VST3.

3 Likes
5

For what it’s worth I’ve been checking most of the major VST3 hosts (Cubase, WaveLab, Reaper, Studio One) and they all seem to support this layout without any issues, not sure about Waveform though!

1 Like
6

I haven’t tested it yet… but I thought it’d be like AAX where you just have a post-build step to copy the .vst to the correct folder.

Cheers,

Rail

7

It shouldn’t matter much. Unlike aax there’s no signing. It’s just a folder hierarchy. You can already see vst hosts should support recursive scanning. And unsupported arch would simply fail / ignored.

1 Like
8

Yes what I was worried about was that the plugin would show up in a plugin list something like…

v MyPlugin.vst3
  v Contents
    v x86_64-win
       MyPlugin.vst3

… which is just ugly for a user. However in the DAWs I tested recently that’s not the case. They show up that same regardless of being nested.

2 Likes
9

Yes but I can’t even get it to link anymore…

10

My concern – and I haven’t tested yet – is that if there are multiple .vst3 versions in the different folder (x64 and Win32) is the scanner smart enough to deal with it without filling the blacklist with the one which doesn’t match…??

Rail

11

They don’t seem to care what sub-directory they are in they just find the plugin recursively and organise it by the vendor or type as reported to the host by the plugin dll. So none of that should matter as far as I can tell - at least with the DAWs I have tested.

1 Like
12

I’m talkin’ 'bout the JUCE PluginDirectoryScanner

Cheers,

Rail

1 Like
13

:cough: iLok protection :cough: