How to use VST3s in SAW Studio

[andy cross]

You will need two (free) pieces of software:

vst3shell - https://www.xlutop.com/buzz/zip/vst3shell_v1.3.1.zip
shell2vst - http://www.xlutop.com/buzz/zip/shell2vst.zip

That's sufficient to create 64-bit VST2 plug-ins from 64-bit VST3 plug-ins. To transform these into 32-bit you will also need something like J-Bridge.

Create a folder to be the home for your new VST2 plug-ins - it doesn't seem to matter much where you put it, but it seems best not to use an existing VST plug-ins folder.

Extract the contents of vst3shell to this directory, followed by the contents of shell2vst (which has 64-bit and 32-bit versions).

Drag vst3shell.x64.dll and vsti3shell.x64.dll (for any VSTi's) onto shell2vst64.exe. All being well, that should create a subdirectory called (slightly confusingly) "VST3", containing 64-bit VST2 dlls for all of your 64-bit VST3 plug-ins (all of them ~5kb).

If you have 32-bit VST3 plug-ins, then dragging vst3shell.dll onto shell2vst.exe should do something similar, though I've not tried it.

You might be able to move the new plug-ins into SAW's VST folder, but I felt it safer to use "ini" files to point to them where they were created.

I've used this to get IzoTope Ozone 11 (64-bit, VST3 only) working in 32-bit SAW (with additional help from J-Bridge).

[Dave Labrecque]

Very cool, Andy. I'll have to try and see if that's better than using metaplugin for VST3s. Should be, ultimately, if it means not having to put a plugin inside a plugin every time I want to use a VST3 (my current need for this is in the case of UADx (native) plugin versions. No VST(2)'s available for those, as you may know.

Thanks for this.

[Dave Labrecque]

Hey, dumb question: how do these puppies know where to find my VST3 DLL's to work their magic? I'm confused (what else is new?).

[andy cross]

Not dumb at all - I wondered the same thing (although it could be argued we're both dumb, I suppose...).

VST3s install by default into Program Files\Common Files\VST3, so I assume vst3shell knows where to find them - even when they install in sub-folders of that folder (which they usually do).

Consequently, it doesn't seem to matter where you put your folder in which to drop vst3shell.x64 onto shell2vst64, and to contain the newly created VST2s. I put a folder "VST3 dlls" on the C: drive, and it worked fine.

You may well be correct that it's a preferable approach to using metaplugins. The new VSTs load in SAW just like any other plug-in, which might make for better workflow.

[mr_es335]

Good day,

i would suggest that all be careful here...'cause...apparently, this application is still in early beta: [Link]
* "GAS" issues may also result in the use of this application!

Also, please be aware that the many....many... of the newer plug-ins are being developed employing JUCE!!!
* Of the forty-three developers that I have recently contacted, thirty-nine were employing JUCE!!
* Also, of possible interest, and without me asking, six were implementing AI into their plugin development!!

[andy cross]

That seems to be a different application that you're referring to there, though from the same developer.

I imagine that the worst that might happen using the approach I outlined is that the VST2 doesn't get created for some reason, or one is created that doesn't actually function properly. Some caution in purchasing an expensive VST3 plug-in in the hope it can be converted successfully is obviously advisable, but in most cases a free demo could be experimented on before getting your wallet out.

[John Ludlow]

I'm just curious. Has anyone besides Dell ever run into a problem with plugins that they could trace back to the JUICE library? And, Dell - not doubting that you are having legitimate problems with it. Just that, if you're the only one, it may be something in your particular setup that's doing it.

[cgrafx]

I'm just curious. Has anyone besides Dell ever run into a problem with plugins that they could trace back to the JUICE library? And, Dell - not doubting that you are having legitimate problems with it. Just that, if you're the only one, it may be something in your particular setup that's doing it.

I believe the juice plug-ins work fine in saw studio, but have a problem in SAC when using scenes. so it would only be the subset of users that are making use of scenes and trying to make changes to the Juce affected plug-ins in the scenes.

[mr_es335]

Good day,

By-the-way, and just for clarification, the application framework is called "JUCE"...and not "juice"!

What Philip is initially stating is true, that SAC displays issues with JUCE applications within the deployment of scenes.

However, and this is an important however, there IS indeed much more going on in the background...all of which I am not able to divulge.

This being said, there are "other" applications out there that do not employ JUCE - and thus, for my money and peace-of -mind, I will go with those.

Hope this helps to clarify some points?

[John Ludlow]

Ahh! 'Juce' then. Sorry.

No, no - not clarified. You say it's not just scenes - there is much more "...going on in the background..." that you're are not at liberty to divulge? By 'the background' do you mean coding processes, or corporate political intrigue? Or is it international political intrigue? Is Spectre secretly measuring all our studios with Juce sonar? Will they send out a signal and fry our studio monitors?

No, that last couldn't be. This is open source software, right? So, anyone can get a copy of the code, read it for themselves, and modify it for their own use? It would be hard to hide something truly nefarious in open source code. I don't ever remember you having a software product so unambiguously on your personal shucks list. You certainly have made me curious. What did they DO to you? Or - when will you be able to tell us?