COCKOS
CONFEDERATED FORUMS
Cockos : REAPER : NINJAM : Forums
Forum Home : Register : FAQ : Members List : Search :
Old 10-15-2015, 05:34 PM   #1
stw
Human being with feelings
 
stw's Avatar
 
Join Date: Apr 2012
Posts: 279
Default 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!
stw is offline   Reply With Quote
Old 10-16-2015, 06:50 AM   #2
stw
Human being with feelings
 
stw's Avatar
 
Join Date: Apr 2012
Posts: 279
Default

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...
stw is offline   Reply With Quote
Old 10-21-2015, 02:27 AM   #3
stw
Human being with feelings
 
stw's Avatar
 
Join Date: Apr 2012
Posts: 279
Default

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.
stw is offline   Reply With Quote
Old 10-21-2015, 09:36 AM   #4
stw
Human being with feelings
 
stw's Avatar
 
Join Date: Apr 2012
Posts: 279
Default

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?
stw is offline   Reply With Quote
Old 10-21-2015, 11:18 PM   #5
Tale
Human being with feelings
 
Tale's Avatar
 
Join Date: Jul 2008
Location: The Netherlands
Posts: 3,645
Default

Yeah, read here:

http://forum.cockos.com/showthread.php?t=91811&page=13
Tale is offline   Reply With Quote
Old 10-22-2015, 12:36 AM   #6
stw
Human being with feelings
 
stw's Avatar
 
Join Date: Apr 2012
Posts: 279
Default

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?
stw is offline   Reply With Quote
Old 10-22-2015, 02:38 AM   #7
Tale
Human being with feelings
 
Tale's Avatar
 
Join Date: Jul 2008
Location: The Netherlands
Posts: 3,645
Default

Quote:
Originally Posted by stw View Post
Did you receive any complaints?
No. So I guess it works, although I don't know how many users actually use VST3 of course...
Tale is offline   Reply With Quote
Old 10-26-2015, 05:07 AM   #8
stw
Human being with feelings
 
stw's Avatar
 
Join Date: Apr 2012
Posts: 279
Default

...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
Code:
pParam->Set(v);
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?
stw is offline   Reply With Quote
Old 10-26-2015, 05:54 AM   #9
Tale
Human being with feelings
 
Tale's Avatar
 
Join Date: Jul 2008
Location: The Netherlands
Posts: 3,645
Default

I would simply not call UnserializeParams() from UnserializeState(), but instead roll my own, customised parameter unserialize code.
Tale is offline   Reply With Quote
Old 10-13-2019, 10:33 AM   #10
earlevel
Human being with feelings
 
Join Date: Dec 2015
Posts: 331
Default

Quote:
Originally Posted by Tale View Post
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...
earlevel is offline   Reply With Quote
Old 10-13-2019, 11:03 AM   #11
earlevel
Human being with feelings
 
Join Date: Dec 2015
Posts: 331
Default

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.
earlevel is offline   Reply With Quote
Old 03-18-2020, 08:47 AM   #12
Nonlinear
Human being with feelings
 
Join Date: Apr 2018
Posts: 396
Default

Quote:
Originally Posted by earlevel View Post
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"?
Nonlinear is offline   Reply With Quote
Old 03-20-2020, 08:54 AM   #13
olilarkin
Human being with feelings
 
Join Date: Apr 2009
Location: Berlin, Germany
Posts: 1,248
Default

all iPlug1 plugins are based on the VST3 SingleComponentEffect class

https://steinbergmedia.github.io/vst...entEffect.html

VST3 SDK recommends implementing "distributed" plugins with a separate controller and processor.

https://steinbergmedia.github.io/vst...ces/index.html
__________________
VirtualCZ | Endless Series | iPlug2 | Linkedin | Facebook
olilarkin is offline   Reply With Quote
Old 03-20-2020, 11:56 AM   #14
Nonlinear
Human being with feelings
 
Join Date: Apr 2018
Posts: 396
Default

Quote:
Originally Posted by olilarkin View Post
all iPlug1 plugins are based on the VST3 SingleComponentEffect class

https://steinbergmedia.github.io/vst...entEffect.html

VST3 SDK recommends implementing "distributed" plugins with a separate controller and processor.

https://steinbergmedia.github.io/vst...ces/index.html
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?
Nonlinear is offline   Reply With Quote
Old 03-21-2020, 04:15 AM   #15
olilarkin
Human being with feelings
 
Join Date: Apr 2009
Location: Berlin, Germany
Posts: 1,248
Default

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
__________________
VirtualCZ | Endless Series | iPlug2 | Linkedin | Facebook
olilarkin is offline   Reply With Quote
Reply

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT -7. The time now is 02:27 AM.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2024, vBulletin Solutions Inc.