AutoBypass scriptlet

[dhj]

This is a modification of a great scriplet created by @David-san that can be used to automatically bypass a plugin after a short (or zero) time delay when no MIDI activity is detected.
A little bit of work is required to set it up

1. Connect a MIDI In block to an AutoBypass scriptlet and then connect the AutoBypass scriptlet to your plugin
   

2. Create two buttons (e.g. LEDs) and put them in the same linked widget group
   

3. Map one of the buttons to the Plugin Enabled parameter of the AutoBypass scriptlet
   

   

4. Map the other button to the Bypass Plugin of the synth plugin you’re using (here, we are using the Hanon B70 that is included with the Deskew version of GP)
   

   

Play some notes — you should hear the sound as normal but when the sound stops, the CPU usage should decrease significantly.

The scriptlet has some parameters that you can tweak

1. Sustain - controls how long the scriptlet will wait before bypassing the synth after you release the last key
2. Release - You can allow the volume to reduce slowly after you release the last key
3. Current Volume - map this to a slider widget (say) in your rackspace if you want to visually see the release phase

Here is an example gig that demonstrates the above
AutoBypassExample.gig (52.3 KB)

Alternatively, if you’re already familiar with the basic concepts, just download the AutoBypass preset itself and drag it into a gigfile to create a scriptlet with the AutoBypass script already loaded
AutoBypassV2.gpp_internal (6.4 KB)

[edm11]

Very nice scriptlet.
Please note that not every instrument will sound the first note correctly after the plugin has been bypassed by the scriptlet.
The included plugin worked fine, as did Pianoteq, but Kontakt 7 had a slightly delayed attack to the first note played after bypass. IK’s Hammond B-3X and AAS’s Lounge Lizard did not respond at all to the first note played after being bypassed. By that I mean, the plugins came out of bypass, but there was no sound from the note being played.

Perhaps adding in a small degree of latency to the first Note On message being relayed after the plugin is in bypass could solve the issue?

[David-san]

@dhj

This is a modification of a great scriplet created by @David-san that can be used to automatically bypass a plugin after a short (or zero) time delay when no MIDI activity is detected.

I did not check what you modified, but the original Plugin Persist 2.0 Scriptlet can already automatically bypass a plugin after an adjustable delay when no MIDI activity is detected. Or did I miss something?

@edm11

Please note that not every instrument will sound the first note correctly after the plugin has been bypassed by the scriptlet.

That’s right, but there is nothing I can do to change this. I can only find workarounds. In fact something happen when the plugin is first initialized, which doesn’t happen when the plugin is “started” bypassed. It seems that this initialization takes a little bit of time which makes the plugin unavailable during a very very very short time, such that the first note played cannot be played. The solution would be to initialize the plugin at loading time whatever if it is bypassed or not. I had a talk with our friend Nebojsa about this, but at this time he didn’t want to change the current plugin initialization because of my Scriptlet, what I can understand.

[schamass]

@David-san

It seems that this initialization takes a little bit of time which makes the plugin unavailable during a very very very short time, such that the first note played cannot be played.

Have you tried to “delay” (SendLater(…)) the first played note a little bit longer than this “very very very short time”, so that no one would ever recognize this delay when playing but it might be long enough to let the plugin initialize properly?

[dhj]

@David-san

Or did I miss something?

No you didn’t. I just realized that the autobypass pet of your scriptlet was valuable in its own right.

[David-san]

This should work and that’s one possible workaround, but it is ugly in a Scriptlet to have to test millions of time that the first note has already been played.

[dhj]

@edm11

By that I mean, the plugins came out of bypass, but there was no sound from the note being played.

My position is that it works great for the plugins I needed to use that were very intensive and I’m not going to worry about whether it works for every plugin. It’s just another tool that can be very useful in some circumstances.

[David-san]

The issue is only for the very first note played, and as far as I remember most of the plugins I use (not to say all of them) have the same issue. If you unbypass a plugin once (and eventually bypass it again just after), it will work properly forever.

[marvz380]

Using this scriplet in my case, I’ve used MIDI Filter after the scriplet, then blocking out the CC7 which worked for me with all my plugins.

[dhj]

@David-san

The issue is only for the very first note played, and as far as I remember most of the plugins I use

I haven’t actually had this problem with any plugins I use – the scriptlet works great!

[David-san]

Well, the Scriptlet works perhaps great, but you can encounter the issue of the first note not being played when the instrument plugin starts bypassed. If it doesn’t start bypassed, no problem.

[dhj]

Ah — that’s why I haven’t seen any issues — I’m not sure though why it being bypassed the first time would cause a problem but not later on.

[edm11]

It’s not just the first time. It’s anytime the affected plugins are in bypass and a note is then played to bring it out of bypass.

[dhj]

Hmm, I had tried with a very percussive organ — what I noticed was that the very beginning of the attack was missing for the first note (i.e, the click) but s slight it’s not something that would be noticeable in a live situation - it’s not like the note is not there at all.

Right now I just tested with the Modartt Pianoteq and attached is a movie capture so you can see and hear. There are no missing notes and the plugin is definitely getting bypassed. Now I’m wondering if this is just happening on some machines or if it’s OS related.

[edm11]

@dhj

@edm11

The included plugin worked fine, as did Pianoteq, but Kontakt 7 had a slightly delayed attack to the first note played after bypass. IK’s Hammond B-3X and AAS’s Lounge Lizard did not respond at all to the first note played after being bypassed.

Yes, I listed Pianoteq as working fine.
Try it with Lounge Lizard.

[dhj]

OK - I can reproduce with Lounge Lizard — I had not tried that plugin before because it is so CPU friendly that it was never an issue.

But given that it seems to work with many plugins, I’m tempted to argue that, for the ones that don’t work, the developers are implementing bypass wrong.

[edm11]

@dhj

for the ones that don’t work, the developers are implementing bypass wrong.

I agree. I simply wanted to point out the potential for certain plugins to not play well with the scriptlet, for those who would come across this post in the future.

[David-san]

@edm11

It’s not just the first time. It’s anytime the affected plugins are in bypass and a note is then played to bring it out of bypass.

Oh, this is a different issue than the one I am talking about. Perhaps we should add a parameter delay applied to each first note played when the plugin has to be unbypassed, I will try this this week-end, I am just thinking of an efficient way to do it.

[salomao]

Any news on this subect?
I found that using Korg Triton Extreme plugin, every tim e the plugin is bypassed, then when I play it the first note wont come out.
Have you found a solution for this?

[David-san]

@salomao

every tim e the plugin is bypassed, then when I play it the first note wont come out.

If it is every time, then it probably means that the plugin is still asleep when playing the first note and for this particular situation, I think there is not much to do.