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
Connect a MIDI In block to an AutoBypass scriptlet and then connect the AutoBypass scriptlet to your plugin
Create two buttons (e.g. LEDs) and put them in the same linked widget group
Map one of the buttons to the Plugin Enabled parameter of the AutoBypass scriptlet
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)
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)
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?
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?
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.
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?
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.
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.
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.
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.
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.
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.
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.
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.