When I convert over my Amplitude 4 to VST3 all my existing preset banks are cleared out. I tried an export from the VST2 and import into a VST3 version, but errors out, dialog says it’s a “different plugin”…
The import works properly if it’s just another instance of the Amplitude 4 VST2.
Is this a bug (part of the work in progress), or do I need to start rebuilding the bank of 30 plus presets one by one?
Thanks guys… yep these issues I’m aware of and looking into today.
No, but I think I should add one!
Hard to say right now. There’s a number of factors that can affect the success of this - I’ll look into it.
Brad
Just a quick observation with 3617: replacing VST2 plugins looks broken: I just tried to replace Blue3 (VST2) with Hammond B-3X (also VST2), and this is what things look like now:
All routes are broken; the plugin stays Blue3 - something is pretty messed up here - @brad ??
BTW: this isn’t specific to Blue3 and Hammond B-3X - I just tried to replace Korg M1 with VB3-II - similar experience (except for the fact that M1 is actually replaced):
Something is weird about the output ports: this is the VB3 audio output after the replace
Inserting a fresh VB3 instance looks like this:
Looks like a bit of work in progress on the plugin audio port plumbing…
Cheers,
Torsten
Hi @Torsten
Thanks for reporting. I actually fixed this yesterday but I didn’t get a new build out with the fix yet. Hopefully new build today…
Brad
I’ve looked into this - Amplitude 4 doesn’t support upgrade from VST 2 to 3 (which will be more obvious in the next build of Cantabile - stay tuned for details). You’ll need to check with IK about how to update your presets.
I’ve just put up a new build with some more fixes and improvements.
Besides bug fixes there’s also some UI changes.
Upgrading a plugin is now done via a dedicated right click command.
Upgrade plugin will attempt to upgrade a VST 2 to 3 plugin maintaining the plugin state. Replace plugin will now always replace the plugin with a new instance and discard any previous plugin state.
If the plugin doesn’t support upgrading the command will be disabled. If the plugin says it supports upgrading, but really doesn’t you’ll get an error message and the plugin will be left in a failed state.
Note that it appears all (or perhaps most) Arturia plugins fail to upgrade. I’ve reproduced this in Cubase Elements and forwarded relevant details to Arturia and they’re looking into it.
You can now undo a plugin upgrade. This is particularly useful for plugins that fail to upgrade.
You can now right click on a plugin and choose “Properties” to see detailed information about it.
I’ve also made a couple of fixes to the VST 3 hosting. There are still known issues which I’m working on but wanted to get the above changes out before investigating further. I’m also in discussion with several plugin developers about other issues and will continue working to get this stable asap.
Stay tuned and thanks everyone for your help with this.
Brad
I will just create a list of presets in the bank and rebuild it in the VST3 version. I will wait until things are solid on the release.
I presume that the import bank feature cannot be “tweaked” to accommodate the fact that it is the same plugin and just the presets need to be referenece. The same problem will be applicable to rebuilding VST3 preset effects.
Hi
Have had some time to play with the update, and apart from a few crashes when changing plugins, the following seem the be working as VST plugins on my setup.
I haven’t tried replacing/upgrading plugins in my files yet. Maybe another day…
The problem here is that the saved data from a plugin is opaque to Cantabile and can be in any format the plugin desires. If the plugin developer changed that format between VST 2 and VST 3 versions of their plugin then Cantabile can’t do anything about that. Even if they didn’t change the data form, Cantabile can’t assume they didn’t.
The VST 3 spec does define how a host can upgrade plugin data from VST 2 plugin to a VST 3 but it requires support from the VST 3 plugin. If the plugin doesn’t support it, or if it fails then there’s nothing that can be done to upgrade that data except to petition the plugin developer to support it.
Brad
Build 3619 is now up which addresses the last known issues with VST 3 plugin hosting - most importantly the issues with Waves and FabFilter effects has been resolved.
Let me know if you’re still experiencing problems with any VST 3 plugins.
Hi @Derek… did you send crash reports for these, I haven’t received them. Let me know if these issues still happen in the latest.
Thanks Brad for 3619. I have tested it for 30 minutes this morning and seems to work ok.
All previous reported VST3 issues I had before seem ok now. Waves, Fabfilter and iZotope VST3 effect plugins following a VST3 instrument work ok now.
the VST3 version of GSi-VB3-2 is also working ok now
Also, CPU usage with VST3 seems improved and faster now than VST2. This is only a quick impression, not based on in-depth tests. Not sure if you have addressed it specifically or if it is due to the other fixes you made.
Will keep on using and testing, but I am a happy man already.
I’m working on 3619 now. I’m upgrading PianoTeq 6.4.0, with preset model ‘Use Plugin’s programs’ with Upgrade Plugin. This works fine except my plugin presets won’t be upgraded.
The only way to get my presets working is to define them using the ‘Entire Plugin Snapshots’. So for testing purposes, I reverted the rack, so I’m on VST2 again.
Next I tried to first set the plugin model to ‘Entire Plugin Snapshots’. I was hoping my current presets in VST2 mode could be migrated to a different plugin mode, before upgrading to VST3 (it won’t unfortunately).
Next step is to ‘Upgrade Plugin’. Then I’m getting an this error:
Thanks for the comments on the upgrade issue Brad. It’s too bad they leave it to the developer to build or not build the update feature for plugins.
Let us know when you have firmed things up and it’s worth starting to manually rebuild.
Hi, Brad
No crash reports were generated.
Thanks for reporting… I’ll look into these issues but probably not in time for today’s build.
If you can still reproduce these crashes in the latest build it’d be great if you could capture a crash report as described here.
Brad
Hi Brad
Lots of problems have been solved (VB3-II, Fabfilter, U-he, Lustrous Plates) , except :
Still some routing problems with softube vst3 version plugs : when i insert a softube vst3 plug after anything there is no sound. I open the audio ports… window of the plug, then close it, the sound is back. Then after some time (not always the same amount) the sound stops again and come back if i re-open the audio port window and again and again… If i look at the plug’s audio ports there’s still the weird thing at the Stereo Out ports : “L / Plugin Output - Stereo Out - #1, Plugin Input - Stereo In - #1” and the same for the R port. Even if I delete the Inputs frome the Stereo Out, the sound still disapear some times.
And for Izotope Vst3 plugs : create it it works normally, but Cantabile Crashes when deleting or replacing it, no crash report window. @Brad do you need me to create this report with the Microsoft Debug tool ? I don’t have time left today but I can Try later this week.
Anyway good work !! 
It would be great if we could do some proper analysis on this at some point - comparing the Cantabile load from the same plugin in VST2 and VST3 forms, especially with some of the more heavyweight plugins.
Neil
I actually experienced the same: When using Izotope Vst3 (Neutron elements and/or Ozone elements), they work normally, but Cantabile Crashes when deleting them. No crash report window generated.
Great. Pleased to see this finally starting to stabilize.
I’ll look into these issues today.
Yep that’s correct way for audio ports to be configured for effect plugins. Output channels with both input and outputs to the plugin mapped are controlled by the wet/dry knob and adjust the balance between input/output.
