|
10-15-2015, 05:34 PM
|
#1
|
Human being with feelings
Join Date: Apr 2012
Posts: 279
|
UnserializeState trouble
Hi all,
the initial version of my plug uses chunks for serializing arbitrary data.
The current update of the plug got some additional params which i added at the end of the previous parameter enums. I once tested that approach and it appeared to me that it worked well. However when testing again now i had to discover that i'm proofed totally wrong in my assumption - at least partially (no idea how i could have missed that ).
Though AU plugs are doing fine with that method VST plugs are not. So i'm in big trouble now...
While AU plugs are serializing the saved params and defaulting the new ones the VST plug is set to the default preset instead, totally ignoring the saved state.
After reading thru some postings and doing some own research and debugging the reason behind that seems to be that VST plugs are calling UnserializePreset when reloaded which ends in restoring the default preset if the parameter size goes to far.
I just tried some dirty hacks with IPlugBase::UnserializePresets just to see if i could get it running somehow but only with partial success.
What can i do to rescue my plug update setting the right values from the old plugin saved state?
I don't need/use VST preset system if this makes a workaround easier.
Any help is (very much) appreciated!
|
|
|
10-16-2015, 06:50 AM
|
#2
|
Human being with feelings
Join Date: Apr 2012
Posts: 279
|
After some testing it turns out that unserializing works fine even in the VST version if i comment out RestorePreset() in IPlugBase.cpp.
Since i don't need any VST preset functionality i hope that goes without any other disadvantages. So far i couldn't notice any malfunctions.
But i'm always a bit concerned when altering basic WDL code.
So if anyone has any remarks...
|
|
|
10-21-2015, 02:27 AM
|
#3
|
Human being with feelings
Join Date: Apr 2012
Posts: 279
|
Request for confirmation:
After some more testing in different hosts i discovered a problem with the VST3 build in the new Reaper version. It seems that UnserializeState() never gets called and hence arbitrary serialized data won't be restored.
I tried to find out what Reaper calls when setting up the plug and placed breakpoints all over the place but got no hit. Is this some kind of improper implementation on Reaper side or did i screw it myself?
So far every other VST3 host seems to work.
|
|
|
10-21-2015, 09:36 AM
|
#4
|
Human being with feelings
Join Date: Apr 2012
Posts: 279
|
nice self-talk
... i found a solution for this in the wdl-ol thread.
I uncommented setState(IBStream* state) and getState(IBStream* state) and everything seems to work now.
However the question remains if there was a special reason for commenting out these functions? Is there any information on that issue or did anyone make some testing already?
|
|
|
10-21-2015, 11:18 PM
|
#5
|
Human being with feelings
Join Date: Jul 2008
Location: The Netherlands
Posts: 3,645
|
|
|
|
10-22-2015, 12:36 AM
|
#6
|
Human being with feelings
Join Date: Apr 2012
Posts: 279
|
Thanks Tale,
that's where i got the infos from. So the important part is this:
Quote:
I ended up using get/setState() but without setComponentState(). Now lets hope that works.[..]
Maybe it's still a little early to tell, but this seems to work (i.e. no complaints so far).
|
Did you receive any complaints?
|
|
|
10-22-2015, 02:38 AM
|
#7
|
Human being with feelings
Join Date: Jul 2008
Location: The Netherlands
Posts: 3,645
|
Quote:
Originally Posted by stw
Did you receive any complaints?
|
No. So I guess it works, although I don't know how many users actually use VST3 of course...
|
|
|
10-26-2015, 05:07 AM
|
#8
|
Human being with feelings
Join Date: Apr 2012
Posts: 279
|
...and another one
I noticed that i got a wrong parameter after unserializing. The reason seems to be that my actual plug has more params than the previous saved state.
The wrong value was set on the first additional parameter. The reason is:
The UnserializeParams loop steps one index too far since the break condition ('pos >= 0' in this case) is hit after setting the undefined value.
I can prevent that with changing
to
Code:
if (pos > 0) pParam->Set(v);
in int IPlugBase::UnserializeParams(ByteChunk* pChunk, int startPos).
So my questions are:
Could that break anything i can't think of right now, and second - if not - shouldn't that be the default code since the last positive 'pos' value contains actually the position after the last serialized parameter?
|
|
|
10-26-2015, 05:54 AM
|
#9
|
Human being with feelings
Join Date: Jul 2008
Location: The Netherlands
Posts: 3,645
|
I would simply not call UnserializeParams() from UnserializeState(), but instead roll my own, customised parameter unserialize code.
|
|
|
10-13-2019, 10:33 AM
|
#10
|
Human being with feelings
Join Date: Dec 2015
Posts: 331
|
Quote:
Originally Posted by Tale
I have now tested with only get/setState(), only get/setEditorState(), and with both. Studio One and VSTHost seem to work with any combination (although VSTHost still resets to defaults after loading state), but REAPER needs get/setState(), although it does also call get/setEditorState(), but only if you also implement get/setState().
I am about to release a beta version of a plug-in suite including VST3. I am leaning towards enabling both state and editor state, and then see what comes up from feedback from beta users.
|
Quoting from the long wdl-ol thread, since it mentions all the details.
The VST3 implementation isn't quite right in IPlug1 (IPlug2 looks fine, though), and it causes issues with Reaper in particular. You can see this by building IPlugEffect, and setting breakpoints in IPlugVST3.cpp's process function at case kPresetParam (RestorePreset) and the default case that follows (where individual plugin parameters are set). Save a preset (Reaper's default format). Load it. You'll hit Restore preset. This is wrong, because that's a factory (baked in) preset request. Not only that, but the preset number requested will be garbage (maybe NaN, maybe a huge negative number...). Continue, and next you'll break at the default case, which sets the single parameter for IPlugEffect. But if it's your plugin with more parameters, it will set each in order.
This happens whether you set PLUG_DOES_STATE_CHUNKS or not. In other words, if you want chunk handling, you'll get a bogus factory preset request (probably failing with a bad preset number), then serial parameter restoration (no setState/UnserializeState).
I'll elaborate on the cause and fix in the next message...
|
|
|
10-13-2019, 11:03 AM
|
#11
|
Human being with feelings
Join Date: Dec 2015
Posts: 331
|
The problem in IPlugVST3 (besides some other problems I pointed out in the past that cause factory preset menu problems with Reaper):
IPlugVST3 implements a SingleComponentEffect. Key questions many have hit over the years are why setState, getState, and setComponentState are commented out, and whether set/getState should be substituted for set/getEditorState.
First, a SingleComponentEffect shouldn't implement setEditorState and getEditorState. If you check the VST3 SDK docs, it doesn't mention those as member functions, and if you look at the code you'll see that setEditorState and getEditorState are compile-time renaming of setState/getState as a "work around for the name clash of IComponent::setState and IEditController::setState" with SingleComponentEffect's setState and getState. In other words, setEditorState and getEditorState are not members that you would expect to call or be called from the host. And with setState/getState comments out, the host will receive kNotImplemented, the default implementation for SingleComponentEffect.
But VST3 hosts try to do their best, so anything that happens next is host-dependent. It appears that Reaper's backup plan is buggy. Cubase 9 works fine because it appears to try everything—it calls setState, setComponentState, and setEditorState.
The fix is to rename setEditorState to setState, getEditorState to getState, and you can delete the commented-out code.
|
|
|
03-18-2020, 08:47 AM
|
#12
|
Human being with feelings
Join Date: Apr 2018
Posts: 396
|
Quote:
Originally Posted by earlevel
IPlugVST3 implements a SingleComponentEffect. Key questions many have hit over the years are why setState, getState, and setComponentState are commented out, and whether set/getState should be substituted for set/getEditorState.
The fix is to rename setEditorState to setState, getEditorState to getState, and you can delete the commented-out code.
|
I have been building plugins for over a year now and just discovered this problem in Wavelab: https://forum.cockos.com/showthread.php?t=232840
Has anyone come to understand WHY this code was commented out?
Also, what would be an example of a plugin that is NOT a "SingleComponentEffect"?
|
|
|
03-20-2020, 11:56 AM
|
#14
|
Human being with feelings
Join Date: Apr 2018
Posts: 396
|
Quote:
Originally Posted by olilarkin
|
If all iPlug plugins are based on the SingleComponentEffect why were setState and getState commented out in iPlugVST3.h? Will study this some more.
So is the "distributed" approach what some developers, like Izotope, are using to communicate between different plugins and instances - or is that something else?
|
|
|
03-21-2020, 04:15 AM
|
#15
|
Human being with feelings
Join Date: Apr 2009
Location: Berlin, Germany
Posts: 1,248
|
yes, some manufacturers will do what steinberg recommends and make a distributed plugin. in iPlug2 you can do either.
There were numerous issues with the VST3 wrapper in wdl-ol/iplug1, which we have addressed/are addressing in iplug2
|
|
|
Thread Tools |
|
Display Modes |
Linear Mode
|
Posting Rules
|
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts
HTML code is Off
|
|
|
All times are GMT -7. The time now is 02:27 AM.
|