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
Big VST State help
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.
- Enlightenspeed
- RE Developer
- Posts: 1103
- Joined: 03 Jan 2019
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 2020I 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?
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!pongasoft wrote: ↑24 Jul 2020One 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...
Cheers,
B
-
- Information
-
Who is online
Users browsing this forum: No registered users and 1 guest