Auto Bypass for global plugins - a different approach

Scripting with Gig Performer
1

I was looking for a way to automatically bypass my Leslie plug-in in the global rackspace when it’s not needed. It is fed by a separate bus „from rackspaces”.

While the AutoBypass scriptlet based on ideas by @David-san works great in many cases, it wasn’t quite right for my needs.
The organs in the local rackspaces constantly produce leakage noise even when there’s no note played currently. I also didn’t want to setup addional widgets or scriptlets.

For this purpose, I’ve come up with a different auto bypass solution:
When I switch rackspaces, my global rackspace script checks if there is a widget called „Hammond“ in the local rackspace and automatically turns the Leslie plugin on or off accordingly. This widget could be a drawbar, a hidden text label or whatever with this handle.

Here’s the code (global rackspace script):

var
    Leslie : PluginBlock
    ew : ExternalWidget

On Rackspace(oldRackspaceIndex : integer, newRackspaceIndex : integer)
    If BindExternalWidget(ew, "Hammond", GetRackspaceNameAtIndex(newRackspaceIndex)) == true then
        SetPluginBypassed(Leslie,false)
    Else
        SetPluginBypassed(Leslie,true)
    End
End

Additional idea (not tested): if you delay the bypassing after a rackspace change until all notes are released, even the patch persist function should work. :thinking::bulb:

5 Likes
2

Good idea, we are waiting for this GPScript too :stuck_out_tongue_winking_eye:

3

A general problem with “auto bypassing” exists with plugins which produce sounds having a slow fade out (like you get with long reverbs/delays or long release phases).
Many of them (not all) don’t empty their audio buffer properly when they are bypassed, so when they are activated again, the sound starts ringing on from where it formerly was interrupted…
That was the reason why i used the envelope follower plugin to detect when a plugin is actually “silent” before it can be bypassed - the Envelope Follower also has some threshold settings, so you could easily handle a certain noise floor (Lesllie, and such).

5 Likes
4

I love this idea. When we wanted to develop an envelope follower, I was thinking only of the obvious uses such as auto-wah and automatically “ducking” music while talking.
Seeing it used for completely different purposes is awesome.

3 Likes
5

Maybe you had missed this one…

That’s the example where i used the envelope follower as described above.

5 Likes
6

I don’t know whether it’s good or bad but it is becoming very difficult to keep up with everything posted on the community forums as there is so much great content coming in from users.

5 Likes
7

That’s right… there’s a lot of cool stuff going on recently. :+1:

2 Likes
8

In particular, @Florian 's contribution to the forum is off to a flying start. :wink:

3 Likes
9

In particular, @Florian 's contribution to the forum is off to a flying start. :wink:

Thanks. When I started with Gig Performer I found everything I needed to kickstart my learning curve here, so I thought I could give something back.
Especially the things a could not do with any other hardware or software. :+1:

5 Likes
11

While it would be nice to support iteration of plugins and widgets in a rackspace, it’s absolutely not going to happen anytime soon. GP Script was simply not designed for this level of programming.

That is one of the reasons we created an SDK that allows you to use a language such as C++ to write your own extensions and even control them by exposing new GPScript functions.

You may have to go down that route if you want more functionality than Gig Performer can currently support given its goals and the needs of the vast majority of users.

1 Like