Hi PG,
I was always using VST2.4 version of this plugin, but tried VST3 and it gives strange results, the rendered file becomes much louder and settings are not saved on VBC. Loading them up brings VBC in its initial state.
Is this a but from Slate VST3 plugin or something in WL8? I use all latest versions.
Cheers
Denis
WaveLab does not know what happens inside the plugin. Please report to the plugin manufacturer.
I can’t offer a solution, but I can tell at least what is happening.
The OP describes the, what is currently known as, so called “Audio Forward Bug”. This is happening in WL7 and WL8. I can’t check if it’s the case in WL6 as well - don’t have it installed on my rig anymore.
What is happening, is that the audio stream is processed in realtime with the VST3 version, but while rendering, nothing happens. Slate Digital is just as puzzled as I am as user. The VST3 versions work fine in Cubendo and S1 in terms of rendering, but not in WL. Forcing WL into “run as admin” (as it is needed for IK Multimedia Plugins) didn’t solve this issue either.
Slate Digital and I had the impression, that it got something to do with the iLok routines. But the same issue popped up with plugins by Klanghelm - and that company doesn’t use copy protection schemes.
So yes… Unfortunately, Slate Digital aren’t the only people suffering from that strange bug, that nobody can explain so far. Eiosis and Klanghelm joined the ride. These companies are already in touch with the VST SDK team, but currently, there is no suitable solution.
Regarding the GUI recall issues - this is also already known to Slate Digital, and they are working on it. Actually a current software update should fix this, but unfortunately not the “Audio Forward Bug”.
When wavelab renders, it uses a new instance of the plugin, and copies the plugin parameters from the playback plugin instance to the new plugin instance. If the parameter copy function has a bug in the plugin, one could imagine the problem you describe.
Hm… this would clear why the IKM Plugins jump from “full version” to “demo mode” on rendering if WL is not run as admin. I’ll definitely foward that to the devs. Thanks.
But is there a reason to use “new instances” rather than the existing ones?
Wavelab is multitasking: you can playback while rendering happens. Hence different plugin instances need to be used.
That makes sense.
Still - it doesn’t clear why “cloning” of VST3 plugins in Cubendo and S1 works, and they do render fine. But not for Wavelab.
Either way, thanks for the input, Philippe. I forwarded this to the affected developers. Maybe they can work with this bit of information.
Not sure that plugins are cloned in Cubendo.
Cloned/copied with ALT+Mousedrag from Insert Slot to Insert Slot… and it keeps the settings from the copied VST plugin. Don’t know why this is happening in WL either (the bug that is). But I hope the devs can now make some sense out of it.
Again, thanks for the input.
My plugin has the same bug in WL: render does not work.
Debugging into my code shows that the problem is that wl does not call the “setstate” method of the controller, it just does call the “setstate” of the component. This is strange, because for this new plugin instance (that is used for rendering) to work correctly it should have a controller and a processing component that are in sync. Also, the vst3 doc states that when the host sets a new processor state this state is always transmitted to the controller as well (by using setComponentstate) but this is not the case in wl.
I hope that people at steinberg will fix this soon.
Debugging into my code shows that the problem is that wl does not call the “setstate” method of the controller, it just does call the “setstate” of the component. This is strange, because for this new plugin instance (that is used for rendering) to work correctly it should have a controller and a processing component that are in sync. Also, the vst3 doc states that when the host sets a new processor state this state is always transmitted to the controller as well (by using setComponentstate) but this is not the case in wl.
You make a false assumption: WaveLab does not (need to) instantiate a controller when rendering, as there is no GUI. Look at this note from the VST-3 SDK:
A host does not need to instantiate the Controller part of a Plug-in for processing it. The Plug-in should be prepared for processing without having the controller part instantiated
Your plugin should be prepared to this scenario.
So setstate is not called on my controller because wl thinks there is no controller. but there is one, because my component is a single component effect. so its both a controller and a processor because when creating a processor a controller is also created. As stated in the doc, the host can detect with “if (processorComponent->queryInterface (Vst::IEditController::iid, (void**)&editController) != kResultTrue)” that tells if the processor is also a controller or not.
So in this case wl should call setcomponentstate on the controller after setstate on the component. I think vst3 plugins always expects that to be called.
Thanks for the answer
You don’t understand the concept: in VST-3, there is a full separation between processing and UI (this is a modern architecture, btw). This is why the SDK says:
A host does not need to instantiate the Controller part of a Plug-in for processing it. The Plug-in should be prepared for processing without having the controller part instantiated
This is not about (to quote you):
wl thinks there is no controller
this is about: “wl only does processing hence does not create any UI related module”
I have understood this but I think you did not understand my last post. please allow me to explain myself better. since wavelab does not need a controller it creates onyl a processor, I think we agree on that. But, if the plugin is a “single component plugin” (in the sdk doc they say
“Plug-ins which did not succeed to separate component from controller”
), then it means that the plugin’s controller class and processor class is the same, so when wavelab creates a processor, it also creates a controller, since they are both the same class. Even if it does not need it.
So I think that when doing setstate in the processor, every vst3 host should check if there is a controller with the code snippet from the sdk that I posted in my last post, even if it chose not to instanciate any controller. If it appears that there is a controller it should at least call setcomponentstate to keep things in order and well syncrhonized.
The SDK snippet you mention is "for Plug-ins which did not succeed to separate component from controller "… as the sentence implies, this is not the good behaviour. WaveLab does not support this case. Since there is no way to know if a controller is needed, WaveLab would need to do it for all plugins, only to support plugins with the bad approach. Not good. This eats ressources.
Not good maybe but 100% compliant with the vst3 spec. Moreover this behavior is very necessary for plugins with strong link between GUI and process like an fft realtime analyzer. Many vst3 plugins from many companies behave like this. If wavelab chooses not to support them, I think it would be better to detect it at instanciation (and prevent instanciation or display a warning) instead of allowing them to instanciate but then taking the risk that some features do not work. this is bad for the reputation of both the plugin and wavelab.
I don’t know how to detect this. Any idea?
After the creation of the processor, you can ask to the vst-ma system if the created object is also a controller, like this:
Vst::IEditController* controller;
processor->queryInterface(Vst::IEditController::iid, (void**)&controller)
If it returns true it means that the processor is also a controller so the plugin is a “single component effect”. Otherwise it is a vst3 distributable plugin.
Also, there is a flag called Steinberg::Vst::kDistributable that is documented in the “basic conception” chapter of the sdk doc, but I don’t know how to read it from the host.
I’ll see what I can do in next WaveLab update.
What is your plugin, so that I can test it?
Thank you. my plugin is still in development and I would like not to diffuse it for now, but there are a lot of “single component” plugins around. I will find them and tell you which they are. also in the vst3 sdk samples there is a project called “againsimple” which is a “single component effect”. you can build it and see.