Big VST State help

This forum is for developers of Rack Extensions to discuss the RE SDK, share code, and offer tips to other developers.
Post Reply
User avatar
pongasoft
RE Developer
Posts: 478
Joined: 21 Apr 2016
Location: Las Vegas
Contact:

24 Jul 2020

I know this is somewhat unrelated to RE development, that being said, I am using Reason to test my VST plugins and running into some performance issues.

One thing I have noticed is that Reason constantly calls the plugin to get its state (which in VST3 translates into the call to Component::getState for the RT and EditController::getState for the GUI). So for example, simply clicking on a toggle will result in Reason calling those 2 methods... For example Maschine 2 calls this method ONLY when the song is saved (which seems to make a lot more sense to me). This could partially explain why VSTs are slow in general with Reason...

That being said, the issue I am bumping into is that my SAM-SPL64 plugin ends up having a sample file being part of the state. Which means that every time Reason calls me, I have to serialize the entire sample to save it in the state. I am doing this because I want the state of my plugin to be self contained. I could instead only save the "location" of the file on the disk which would be a lot faster but then the song in which the plugin is used is no longer self contained.

Of course REs don't have this issue, since samples are handled "natively" by Reason... So I was wondering if you have any advice on how to manage this issue. I am curious how other (VST) sampling devices handle this situation. Are users expecting the sample to be saved with the song or separate? I am not sure there is a right or wrong answer... but if the file becomes too big then I am bumping into issues with the way I am doing things...

Yan

User avatar
jam-s
Posts: 3035
Joined: 17 Apr 2015
Location: Aachen, Germany
Contact:

24 Jul 2020

As a workaround: You could keep the serialised sample cached in RAM and use it as a static part of the plugin state. Then you only need to serialise the other parameters (like position) on the (frequent) calls.

User avatar
Enlightenspeed
RE Developer
Posts: 1103
Joined: 03 Jan 2019

12 Aug 2020

pongasoft wrote:
24 Jul 2020
I am doing this because I want the state of my plugin to be self contained. I could instead only save the "location" of the file on the disk which would be a lot faster but then the song in which the plugin is used is no longer self contained.

I am curious how other (VST) sampling devices handle this situation. Are users expecting the sample to be saved with the song or separate?
All other VST samplers I'm aware of just use the reference. Serializing the samples for the purpose of self-containing the state would seem to be completely unnecessary unless a destructive process is being carried out on the sample itself in realtime, meaning that the reference would become unreliable. Some samplers also rely on what effectively become mega-wavetables with the entire soundset for the preset in the same audio file, and thus serializing would be a non-starter due to size.
pongasoft wrote:
24 Jul 2020
One thing I have noticed is that Reason constantly calls the plugin to get its state (which in VST3 translates into the call to Component::getState for the RT and EditController::getState for the GUI). So for example, simply clicking on a toggle will result in Reason calling those 2 methods... For example Maschine 2 calls this method ONLY when the song is saved (which seems to make a lot more sense to me). This could partially explain why VSTs are slow in general with Reason...
If I had to take a stab at it, I'd reckon it's because Reason will make a far more spirited attempt than Maschine at performing Undo/Redos. Generally speaking it does a good job of it, but it's certainly not perfect. That said I recently got caught out using Maschine 2 inside Cubase and did an undo. The experience was... Spartan!

Cheers,
B

Post Reply
  • Information
  • Who is online

    Users browsing this forum: No registered users and 1 guest