What stops audio in this code?

Hello.
I had to write a separate post about this cause it’s driving me insane.
@schamass wrote a fantastic script that allows selecting presets via gploadpreset
Here is the original thread:

What I am confused about - how is the audio stopped when returning to a previously played variation that had some reverb tail or long release.

I personally prefer to create rackspaces containing multiple instances of a plugin and change presets via bypass widgets inside variations.
My issue is that if I have a plugin preset that has a long reverb or long release tail, then when I return to this variation I can hear the left over tail.

This script does not do that. But I would like to achieve the same effect as the script without the script. Just with multiple plugin instances.

I guess it’s the plugin… many of them don’t empty the audio buffer properly… I had a similar issue when bypassing and unbypassing plugins while they were playing a sound (especially with long reverbs).
Try that… if the same happens with bypass, it’s the plugin and there is most probably nothing you can do about it.
Some plugins did it right (stayed silent), but many did not.

But this is the same plugin. And your code stops the audio completely. Which is desired.

The script that @schamass wrote is loading a preset each time a variation changes, so returning to a variation that you’ve already played on isn’t continuing anything— its re-loading the preset from the plugin.

So, if you aren’t actually re-loading the preset when you return to the variation and the plugin isn’t clearing its buffers when being bypassed, then you will hear the tails of whatever was playing when you switched away from that variation.

the tails I am hearing are in my rackspace which is using multiple instances of the same plugin. Changing presets via variation widgets.
That’s when I hear the reverb tail.
@schamass ’s script does not have this behavior because the audio is somehow stopped.

I wish to stop that audio in my rackspace because I need the multiple instances and widgets to create combinations of sounds. (Upper and lower with adjustable split point)

I guess I have to clear the preset and then reload it - but this requires using GPuserPresets which I am not looking forward to creating for like 2000 presets I have.

I am hoping there is a way to stop the audio similar like in the script without using gpuserpresets.

If the plugin isn’t clearing its buffers when being bypassed (which it should do), then this is the result. I have a few plugins that have this issue, and for those I connect a Midi In block and script in this when I leave the rackspace:

On Deactivate
`AllNotesOff(MIDI In blockname)` 
End

Since you aren’t actually deactivating the rackspace, you could instead try using a callback for when the widget connected to the plugin bypass gets activated(or deactivated) to generate the AllNotesOff message.

Yeah - if I am leaving the rackspace I haven’t seen this tail with any of the plugins.
But as you mentioned I would like to stay within the same rackspace.
That script piece seems promising and I will try it.
Thank you !!!

But you think it is really a notes off issue? I thought the notes were off but just the tail of the reverb is what we hear.
I actually do lift my fingers off the keys before changing variations. So theoretically this should not work.
But I will try it anyway.

This never happens when switching presets via variations. Every plugin and every plugin preset with a tail acts like that.
It would be absolutely fantastic to have a system function that actually completely stops audio from the variation that we left.

I posted a FEATURE REQUEST for that one.

If I only use dry presets that don’t have any release and no tail at all - then the system works flawlessly. Then as soon as I want to add an effect or if that’s part of the preset - this nightmare occurs.

My solution was to never come back to a certain variation - just duplicate it and go to it as if I go to a new variation (since it’s a new variation)
But this is a dirty solution since I have to duplicate variations as many times as I need to come back to a sound.

The issue is with that particular plugin, or plugins.
When coded properly, plugins should clear their audio buffers when bypassed.
So first, any ‘dirty solution’ is to work around poorly coded plugins not clearing their buffers properly.
Then second, this is coming up because you’re trying to mimic changing rackspaces without changing rackspaces by switching presets within variations thereby losing some functionality.

So its not about feature requests for GP at this point. You’re operating outside the GP paradigm using plugins that aren’t coded properly. I suggest you ‘feature request’ the plugin manufacturer(s) and tell them to update and clear their buffers like they should. :slight_smile:

1 Like

I knew the paradigm thing was coming in one of those posts.
That means all Arturia v collection 9 plugins are coded poorly.
How sad that would be.

As demonstrated in The script - it is possible to have variations change without the tail when using gp user presets. So certainly not a question of this not being possible - clearly it is.

I was just not looking forward to create 2000 gpuserpresets and also I didn’t want to scroll through them like in the script.

I wanted to activate them similar to activating organ stops.

I have yet to find a single plugin (any) that won’t sound its tail. I haven’t yet. All of them do it when changing presets via variations/widgets/bypassing.

My advice: make the rackspaces instead.
There’s certainly a time and place for using scripting to skirt around the edges of usual workflows, but when you venture too far away things get iffy and potentially unstable. You’ll get the functionality you’re after by switching rackspaces without using experimental scripting. It’s your call of course, but to me it would be worth the tradeoff for the stability.

1 Like

Yup. Disappointing enough that is the way. Using rackapaces.
That worked from day 1. But lots more instances than necessary unfortunately.
At least with rackspaces no scripting necessary.