A VST3 plugin that I developed and released well over a year ago has been working fine in prior versions of Wavelab - including WL 9 - but crashes WL 10.
The VST3 plugin loads, displays and processes audio properly when used in Master FX section but crashes when used in the clip, track or output FX sections. The plugin processes audio and responds to all controls when first loaded until the very first time playback is stopped at which point WL 10 locks up then closes. So it seems it may be something with the VST “OnActivate” or other related call that is triggering the crash.
PG can you please advise if something changed in the interface to VST3 plugins in WL 10? As stated, this plugin works perfectly in WL 9. The VST2 version of my plugin also works perfectly in WL10 so this is a VST3-specific issue.
I will be running the debugger to try and sort this out but wanted to post this in the meantime in case there is a known issue. I see from other threads on this forum that this may not be an isolated occurrence (Melda plugins seem to be having issues as well) so this could be a regression bug in WL 10.
No known issue. You need to find where in the plugin the crash happens, and then maybe I can help.
Note: since later WaveLab 9, 64 bit processing has been introduced. This is not mandatory to support this for a plugin, but at least it should declare it capabilities properly.
The plugin passes all tests of the 64-bit Steinberg VST3 validator tool and works properly in Cubase 10 with 64-bit “Processing Precision” enabled. It also works properly in WL 9.
It also works properly in the Master section of WL 10 but does not work in “clip, track or output” sections. The only logical conclusion I can draw is that something is changed/broken in WL 10.
One of the “new features” advertised for WL 10 is, "Improved third-party VST plug-in support". Not in this case!
“Improved third-party VST plug-in support” should have been titled “Improved VST-3 specification plug-in support”, which is not exactly the same things.
This being said, since you created the plugin, you should be able to know easily where the problem occurs, no?
If you think the crash happens inside WaveLab and not inside your plugin, you should generate a crash dump.
Under Windows, you can generate one crash dump from WaveLab if you do so:
While pressing the Alternate key (press first and maintain), select “Global preferences” from the WaveLab menu with the mouse.
In that case, there is a new tab called “Diagnostics”. There you can activate several functions.
Activate the option “Enable crash report”. Quit and relaunch WaveLab.
If a crash happens, one crash dump is generated.
There is no explicit SetLatency() in the VST-3 spec.
There is, however, a restartComponent(kLatencyChanged) possibility.
But this is only if the algorithm of the plugin changes while it is active (eg. the user changes a “mode”).
If the latency is fixed for a given sample rate, there is no need for the plugin to call this function
(the host queries the delay to the plugin, the plugin does not have to notify it).
The VST-3 spec says:
If during the use of the Plug-in its latency change, the Plug-in has to inform the host by
using IComponentHandler::restartComponent (kLatencyChanged), this could lead to audio playback interruption
because the host has to recompute its internal mixer delay compensation.
WaveLab versions before 10, did not support plugin latency changes while the plugin was active.
When this happens now, WaveLab has to briefly auto-stop/playback, to take this delay into account.
In previous WaveLab versions, the delay was taken into account next time the user would restart playback himself.
OK, so there WAS a change made in WL 10 - why didn’t you say that when I asked at the top of this post?
“SetLatency()” is function in the iPlug cross-platform plugin development framework. I do not know it’s internal workings as I did not write them. Perhaps that code needs to be updated, IDK, but the check I have now implemented seems to solve the problem.
My plugin does not change latency while running - I check the hosts sample rate on playback stop and send the latency info to the host (using “SetLatency()”) in case there were any changes made in the project while the plugin is loaded. That may not be necessary for WL but it is for some other hosts.
OK, so there WAS a change made in WL 10 - why didn’t you say that when I asked at the top of this post?
There have been many changes in WaveLab, and I forgot this one until you mention latency change. Actually, this is not a change but an addition.
“SetLatency()” is function in the iPlug cross-platform plugin development framework.
What framework? I can’t find a trace of it in the Steinberg VST-3 SDK (else, where?)
My plugin does not change latency while running - I check the hosts sample rate on playback stop and send the latency info to the host (using “SetLatency()”) in case there were any changes made in the project while the plugin is loaded. That may not be necessary for WL but it is for some other hosts.
A majority of VST-3 plugins never call restartComponent(kLatencyChanged), hence I doubt any host requires it.
“iPlug” is a cross-platform plugin development tool - like Juce. It takes all of the platform-specific code (VST3, AU, AAX, etc.) and “wraps” it with generic functions.
In some hosts, like Reaper, one can change the project sample rate when the project window and tracks are already open. You can not do that in Pro Tools. My plugins have to work with ALL of these DAWs.