COCKOS
CONFEDERATED FORUMS
Cockos : REAPER : NINJAM : Forums
Forum Home : Register : FAQ : Members List : Search :

Go Back   Cockos Incorporated Forums > Other Software Discussion > WDL users forum

Reply
 
Thread Tools Display Modes
Old 09-29-2019, 11:51 AM   #1
earlevel
Human being with feelings
 
Join Date: Dec 2015
Posts: 331
Default A case against PLUG_DOES_STATE_CHUNKS

An IPlug developer is expected to set PLUG_DOES_STATE_CHUNKS to 0 or 1 (resource.h for IPlug, config.h for IPlug2). Of the IPlug examples, I see only IPlugChunks set to 1, all others have

Code:
#define PLUG_DOES_STATE_CHUNKS 0
Up front, I'll say that PLUG_DOES_STATE_CHUNKS should be 1, always (assuming the plugin doesn't have custom code that for whatever probably-bad reason makes it otherwise), and in fact probably shouldn't exist. Likely it was needed in the beginning, but with default chunk handling built in, it isn't now.

I'm being blunt and getting to the point here, to spare words, but if you think I'm wrong that's exactly the discussion I'm looking for.
earlevel is offline   Reply With Quote
Old 09-29-2019, 11:52 AM   #2
earlevel
Human being with feelings
 
Join Date: Dec 2015
Posts: 331
Default

What PLUG_DOES_STATE_CHUNKS does

As for the purpose, like I implied I don't think it has one at this point, but the obvious idea being communicated is whether or not it is chunk-aware (yet IPlug is already chunk-aware without writing any code). Here is what it does in the code; I'll use wdl/ol IPlug, since it is archived and will not change, but IPlug2 today is bascially identical in this regard:

PLUG_DOES_STATE_CHUNKS is passed in the plugin constructor as a variable called plugDoesChunks (or in a config struct in IPlug2). So, if you want to follow along, start searching there. It's tested directly in one place, IPlugVSt2.cpp:

Code:
  if (plugDoesChunks) { mAEffect.flags |= effFlagsProgramChunks; }
In other words, the VST2 build of your plugin informs the host whether it can or can't handle chunks. (If a plugin can't handle chunks and says so, the host will send parameters individually upon program and state changes, if it's a good player, instead of as a chunk containing all the settings.) Besides this, plugDoesChunks is saved in the plugin instance as the boolean mStateChunks, which is never accessed directly, but through DoesStateChunks(). So, with the exception of the effFlagsProgramChunks flag-setting above, used only for VST2 (and the flag is not reference again by the plugin), DoesStateChunks is what you want to look for if you want to know what if affected by PLUG_DOES_STATE_CHUNKS.
earlevel is offline   Reply With Quote
Old 09-29-2019, 11:52 AM   #3
earlevel
Human being with feelings
 
Join Date: Dec 2015
Posts: 331
Default

OK, where is DoesStateChunks used?

Two places. This first is that it's used in (IPlugBase: SaveProgramAsFXP, SaveBankAsFXB, LoadProgramFromFXP, LoadBankFromFXB. These implement VST2-style preset and bank support. They aren't called in IPlug/2, they're just available for the developer. I suspect they are very old and don't actually need to support chunk and non-chunk anymore, since the rest of IPlug/2 support chunks.

The second is in IPlugVST2.cpp, this is the only use of consequence:

Code:
    case effSetProgram:
    {
      if (_this->DoesStateChunks() == false)
      {
        _this->ModifyCurrentPreset(); // TODO: test, something is funny about this http://forum.cockos.com/showpost.php?p=485113&postcount=22
      }
      _this->RestorePreset((int) value);
      return 0;
    }
This is the VST2 code for loading your "baked in" (MakePreset, etc.) factory presets. The code calls ModifyCurrentPreset if the plugin can't handle chunks. But 1) of course the plug-in knows chunks, and 2) why the heck call ModifyCurrentPreset? ModifyCurrentPreset does this: Say your plugin supports factory presets, and let's say it's a parametric filter plugin, and you set PLUG_DOES_STATE_CHUNKS to 0. Open it in Reaper, select the fourth factory preset, "fat bottom", with a bass-boost shelf. Play around with it, set the bass gain negative to get a tinny sound. Now switch to the sixth preset. And back to the "fat bottom" preset—it sounds tinny, because ModifyCurrentPreset overwrote the preset with the altered parameter setting when you changed to the sixth preset. All the factory preset will behave this way—they aren't really factory presets anymore, they are whatever they were when you last had them up. but the rewriting is only in memory, the next time you open the project/plugin, it will be back to the factory presets.

But this is only for VST2—your AU and VST3 versions in Reaper won't do that. And while it may seem like a cool idea to remember tweaks (um, temporarily), that's what save preset is for.

In closing, PLUG_DOES_STATE_CHUNKS serves no useful purpose. But if you forget to set it to 1, and your plugin has programming parameter-order dependencies, which you overrode some routine to implement, PLUG_DOES_STATE_CHUNKS 0 will break your code. So, it serves no useful purpose, but is a potential menace in some cases. And it adds needless confusion in the code (IPlug2 changed to passing a config struct, so it's not nearly as busy with "plugDoesChunks" as IPlug(1), but otherwise it's essentially the same).
earlevel is offline   Reply With Quote
Old 09-29-2019, 11:45 PM   #4
Tale
Human being with feelings
 
Tale's Avatar
 
Join Date: Jul 2008
Location: The Netherlands
Posts: 3,645
Default

Quote:
Originally Posted by earlevel View Post
But this is only for VST2—your AU and VST3 versions in Reaper won't do that. And while it may seem like a cool idea to remember tweaks (um, temporarily), that's what save preset is for.
Well, it might not be expected behavior nowadays (YMMV), but it is how VST2 was designed (it more or less mimics DX7 behavior). Also note that any tweaks should not be temporarily, because the plug-in should save the changes in the plug-in state.

But yeah, I do agree that you should always set PLUG_DOES_STATE_CHUNKS set to 1 and code your own serialization, because else you can't expand your plug-in anymore in a future version without breaking preset/project compatibility.
Tale is offline   Reply With Quote
Old 09-30-2019, 12:38 AM   #5
earlevel
Human being with feelings
 
Join Date: Dec 2015
Posts: 331
Default

Quote:
Originally Posted by Tale View Post
Well, it might not be expected behavior nowadays (YMMV), but it is how VST2 was designed (it more or less mimics DX7 behavior). Also note that any tweaks should not be temporarily, because the plug-in should save the changes in the plug-in state.
OK, I was wondering if it was some legacy thing like that. But it makes very little sense in current hosts, and seems unexpected, especially next to AU/VST3/AAX, which don't behave that way. However, if if we were to say that's a behavior we want, the implementation in IPlug1/2 is not quite right. ModifyCurrentPreset is called conditionally dependent on PLUG_DOES_STATE_CHUNKS (only called when it's 0). But ModifyCurrentPreset is called in other places too, so the exact behavior is likely dependent on the host (Reaper, for instance, calls effGetChunk like crazy, IIRC, after any parameter change).

So even supporting the "feature" doesn't make a good argument for the existence of PLUG_DOES_STATE_CHUNKS.

Quote:
But yeah, I do agree that you should always set PLUG_DOES_STATE_CHUNKS set to 1 and code your own serialization, because else you can't expand your plug-in anymore in a future version without breaking preset/project compatibility.
"set to 1 and code your own serialization"—Just to clarify what you're saying, you mean code your own serialization if you need something beyond the default serialization, right? The default handlers iterate through the parameters in both directions, and you only need to override them if you need to handle additional features (for instance, storing/retrieving additional non-parameter info, such as the format version of the program/preset). Is that correct?

For instance, I have a plugin commercial plugin, AAX/AU/VST2/VST3. I'm not doing my own serialization. The AAX part is a different story, and of course I'm overriding SetChunk/GetCunk/CompareActiveChunk (largely because I need backwards compatibility with its TDM predecessor). But for Au/VST2/VSt3, the serialization is untouched (though this particular plugin has parameter order dependencies, so I override RestorePreset).
earlevel is offline   Reply With Quote
Old 09-30-2019, 05:25 AM   #6
Tale
Human being with feelings
 
Tale's Avatar
 
Join Date: Jul 2008
Location: The Netherlands
Posts: 3,645
Default

Quote:
Originally Posted by earlevel View Post
Just to clarify what you're saying, you mean code your own serialization if you need something beyond the default serialization, right?
Yeah... However, I would argue that you never know if you will want something beyond default behavior at some point. What if you want to add/remove parameters? I suppose for AU (and I guess VST3 and AAX) you can always add extra parameters without breaking compatibility, and you can't really remove automatable parameters anyway. Still it might be better to store some extra info (version, size, etc.), so it will be easier to extend in a future version.

Also, parameters in IPlug (v1 at least) are always stored as doubles. If you have a lot of on/off style parameters, then IMHO this wastes a lot of space. This could be another reason to write your own serialization code.
Tale is offline   Reply With Quote
Old 09-30-2019, 10:02 AM   #7
earlevel
Human being with feelings
 
Join Date: Dec 2015
Posts: 331
Default

Agreed. I certainly have had plugins that added parameters to support new features (both Amp Farm and Echo Farm TDM versions—the newer native AAX versions support all the older chunk versions from TDM).

The good news is that even if a developer blows it and doesn't do custom chunks the first time, then needs them in a new version for feature enhancements, you can always detect whether a chunk is the old version (via size or an identifier that's non-double), and rewrite it to the new format.
earlevel is offline   Reply With Quote
Old 10-05-2019, 11:19 AM   #8
earlevel
Human being with feelings
 
Join Date: Dec 2015
Posts: 331
Default

To button up the idea, I'm bringing this up because I think it's extra baggage with no purpose, that IPlug2 should ditch early on. It boils down to:

1. PLUG_DOES_STATE_CHUNKS affects only VST2

- Yet it ripples through every plugin type

2. It's only purpose if to advise VST2 hosts that the plugin doesn't know state chunks

- Yet IPlug (1 and 2) plugins handle state chunks automatically

I can't imagine ditching it will break any plugins. And the only issues I've seen on the forum (and personally) have occurred when PLUG_DOES_STATE_CHUNKS was left at 0.

Last edited by earlevel; 06-23-2020 at 10:54 PM.
earlevel is offline   Reply With Quote
Old 06-23-2020, 02:48 PM   #9
olilarkin
Human being with feelings
 
Join Date: Apr 2009
Location: Berlin, Germany
Posts: 1,248
Default

thinking about this now
__________________
VirtualCZ | Endless Series | iPlug2 | Linkedin | Facebook
olilarkin is offline   Reply With Quote
Old 06-23-2020, 10:56 PM   #10
earlevel
Human being with feelings
 
Join Date: Dec 2015
Posts: 331
Default

Quote:
Originally Posted by olilarkin View Post
thinking about this now
My ears must have been burning, because I just logged in for the first time in quite a while, to see your comment
earlevel 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 08:01 AM.


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