Theoretical and practical size limits for plugin states


#1

We are toying with the idea of storing samples in the plugin state to increase persistence and ease of use. Typical usage will not exceed 5-10 MB per instance.
Did anyone of you do a similar thing? Do theoretical limits exist for different plugin types (VST, VST3 and AU are of interest)? Has anyone ran into practical problems with big state blobs? Is that just a straight out bad idea or worth researching?


#2

Hosts may not deal with the plugin binary states as binary but for example as base64 encoded text. So saving and loading the project files may become slow and the project files can get much larger than could initially be expected.


#3

I do this in a plugin, but I made it a switchable preferences item. The advantage is never losing samples, but as stated the problem is project-file bloat. Most hosts have no problems even with large blobs, but some are problematic. I’ve especially seen issues with MainStage, where loading can take minutes if there is 100mb of preset data. With that host, it seems the loading time scales exponentially with preset data size. In my experience, 5-10mb should not cause issues.


#4

Great thanks! That sounds encouraging. Of course when testing we’ll test with 10 times the expected size … Also thank you for mentioning MainStage as one of the hosts to look at more profoundly :slight_smile:


#5

Also remember that user may use many instances of your plugin in the same project…


#6

BigKick does this, has done for 5 years and 1000s of customers without a single complaint … Typical samples probably less than a meg tho.

Obviously there might be some Main Stage user who has a problem and hasn’t mentioned it, but they’ve not mentioned it.

If enough plugins do it then it’ll become the DAWs problem rather than the plugin developers :wink: (Sorry Dave!)


#7

I hate this shoving of problems between DAW and plugins manufacturers. As a company that makes both (and an open source DAW Engine for others to use) I feel like I’m getting shafted from all angles.

Everything would be a lot better if we decided to work together…


#8

You know I’m teasing ? :slight_smile:


#9

Yes. Maybe we should just get all the audio devs together to vote on it. Should DAWs and plugins be separate or part of the same ecosystem? Oh, wait…


#10

I think it isn’t so much about finding who’s to blame but in fact the very definition of the interface between the two worlds (i.e. VST, AU, etc.) that is too narrow. Almost all DAWs have a checkbox to collect sample and user data, but there is nothing in the Plug-in interfaces to pass that along.


#11

Be nice if there was a common standard all the DAWs implemented, not controlled by a single organisation, clearly documented with a series of tests to demonstrate compliance :slight_smile: Nicely documented threading model … And then similarly for the plugin end.


#12

I thought this was decided with convolution plug-ins… where they would give the user the option of storing the IR inside the preset or not. The only reason to embed it in the preset is for sharing with an off-site location and where the IR isn’t included in the Plug-In’s library.

Rail


#13

There is, it’s called LV2 (but not implemented by everyone and is extensible so you still have testing problems).