I’m using instances of Speedrum in several rackspaces in my gig file. Every so often Speedrum loads without samples on the pads for certain instances.
I ran into this problem in the past and figured out it was because I had an instance of speedrum disabled on load (so this instance and all subsequently loaded instances would load blank). Keeping all instances of Speedrum enabled seemed to have fixed the problem but it’s popped up again even though all of the instances are enabled in each rackspace. This time, however, the ones that don’t load samples seem to be somewhat random and I can’t trace what may have caused it, as the majority of the Speedrum instances will load properly.
I reported the issue to the plugin developer who said he was unable to recreate the issue and I was the only one to experience it thus far. Any thoughts about what may be causing this, seemingly at random? Is it possibly in the way GP saves plugin states? Any thoughts of how to ensure the samples are loaded every time I open the file? I would hate for this to happen at a gig. Of course, I’ve gotten in the habit of saving the sample bank in each instance, but having to reload each sample bank is a little time consuming.
Running GP4 from PA full unlocked latest version
Windows 11 64 bit
i7-8700k, 32 gb ram
What do you mean by disabled? How did you disable the plugin?
Did the developer try to recreate the issue with Gig Performer or with something else - the experiences will most likely be different
Gig Performer requests the state from the plugin and just saves it as a blob of uninterpreted bytes. When the plugin is loaded back (i.e, when you load the gig again), that blob of bytes is simply sent back to plugin. It is completely the responsibility of the plugin to restore its own state including reloading any samples, etc and if it is not doing so, then it either did not give GP the full state or it didn’t handle everything properly when it was given back its state.
Not all plugins types will behave the same (VST, VST3). Does Speedrum have these different types and have you checked the behaviour is the same?
Sorry BYPASS* is what I meant. I had a widget linked to bypass. But this has happened since I removed the widget and left all of the instances of speedrum unbypassed and active.
He hadn’t heard of Gig Performer prior to my bug report. He said he would look into it and try it out but I haven’t heard back. I’ll try to reach out again.
Speedrum only has a VST version. No VST3.
Bypass does not “disable” anything - it simply turns off audio processing of the plugin - it doesn’t impact anything else that the plugin does - at least not if the plugin is properly implemented
Ok I understand. I just know that when the plugin was bypassed, the instance in that rackspace failed to load its samples and all subsequent instances (in rackspaces created after the “bypassed plugin” rackspace) failed to load their samples as well. I can’t speak to the plugin being properly implemented as I am not the dev.
If you have anything I can pass along to the dev (he’s very responsive on the kvr forum) that might be useful for him in increasing stability I would be happy to share it with him. I just now asked him if he was able to check in Gig Performer and see if he could recreate the issue. I’ll make sure to update this post in case any other Speedrum users find this thread down the line.
Sorry - all I can say is that we have absolutely no control over what a plugin does (or doesn’t) — we send the state back that it previously gave us and that’s it.
If you create three (say) instances of that plugin in three different rackspaces, load the appropriate samples and then save the gig file, and the samples are not restored when the gig file is reopened, then the plugin is not properly handling state.
Ok thanks! I’ll keep checking in with the Speedrum dev then.