B3-X Un-bypass issue

Hi,

Already for a while, I am struggling with a strange issue with the B3-X plugin and its bypass behaviour. I finally found some time to investigate it properly and want to share my experience here.

I am using GP5 (v5.0.20), but I also experienced the issue earlier in GP4.
My current setup runs on a M2 Mac Mini, but before that it also happened on an older Intel MacBook Pro (16", i7).

I have the B3-X plugin instantiated in the Global Rackspace and nowhere else. I do this because I like to keep a few often-used instruments accessible at all times (piano, organ, Rhodes, etc…).
Because the B3-X plugin has quite a high CPU load, I sometimes put it in bypass to reduce the load when I don’t need the organ.

The problem is that for some reason I cannot find, un-bypassing/activating the plugin takes longer than expected (about 500ms). This can be seen in the following screen capture. The switch controls the bypass directly, while the LED (also connected to the bypass) lights up when the plugin is actually active. You can clearly see the delay between me clicking the switch and the LED turning on.

Delay

While the delay in itself is annoying while playing (missed notes), it actually seems to cause other processes to hang until the plugin is active. E.g., when I switch between two rackspaces, one in which B3-X is bypassed and the other one in which it is active, everything I play is skipped until the plugin is active, including the other plugins and possible other actions. This is of course unacceptable. Note, that this delay does NOT seem to happen when the plugin is in a Local rackspace, although this could be a side-effect of one of my observations described below (multiple instances)

Simply replacing the plugin with a new instance did not solve the problem. However, ADDING another instances of the plugin (both as VST3) did seem to help, even when this second instance has no connections and is bypassed!

You can see this in the following screen capture, repeating the procedure from above, but now with this additional, bypassed plugin.

No delay

While this workaround seems to cure my most urgent problems, it does not feel like it is actually solving the root cause. I also need to do a bit more testing. So, I am hoping the great minds at Deskew might have ideas why this happens, and how to really git rid of this delay properly.

I detected this issue in my main gig-file, which I had been working on for the last year or so, and which contains over 70 rackspaces, many songs and song parts and even multiple SAFP instances triggering various other actions. In other words: not really possible to share here.

Luckily, I was able to reproduce this in a new, smaller gig-file, to share it here for testing.

b3x_delay_test.gig (341.4 KB)

Note that the local rackspaces in this smaller file have an empty space in the signal path (wiring view) in which the plugin can be added for testing. Doing so, and thus having multiple instances, will solve the activation delay on the global rackspace as well… If you play something on the keyboard, you will mostly hear a Rhodes, with the B3X at lower level. When switching rackspace, or songpart, you should hear it stutter due to the activation delay in the B3X plugin.
You can also see the the delayed activation with the LED.

Thanks for helping me figuring out this issue.

Does this happen if you use a different plugin instead of the B3 X?

It does not seem to happen with any other plugin.

I have not tried replacing the B3-X plugin with another plugin within the full chain, if that is what you mean…

That said, the fact that this also happens in a brand new gig-file with only the B3-X plugin makes me think it is not a problem in the specific gig-file…

Curious about your further thoughts.

What version of B3-X are you using?
VST, VST3, AU?

When you press the LED widget, does is behave the same?

That is precisely what I mean

I’m currently using the VST3 version.
I tried the VST2 as well. Same results.

I didn’t try the AU, though, as I try avoiding using them altogether.

Same results.

When you connect only 1 widget to bypass, the issue stays the same?

When you bypass manually (no widget used) then issue is the same?

Why do you need bypass?
Because of CPU-Usage?

Maybe it would be better to Mute a Gain Plugin after B3-X?
Or Filter Note-On Messages.

OK. I just tried replacing it with Omnisphere, which is not a particularly low-CPU plugin either.
I didn’t change anything else.

No issues there.

Yes.
In fact, originally I just the Plugin Persist script let to control the bypass itself. In that scenario, the LED was the only widget connected to the bypass parameter and was by itself controlled by the Local GP Port CC message generated by the scriptlet.
At first, I thought this was the cause of the delay, but entirely removing the Plugin Persist script let makes no difference.

Interestingly, yes.
Even when disconnecting the widgets entirely.
Clicking the Bypass button on the plugin still produces the delayed activation.

So you should contact IK Multimedia

The bypass is indeed for the CPU load reduction.
On my previous machine I had serious crackles when the B3X was active in combination with some more complicated rackspaces with various other plugins.
I try to remain below 50% CPU load in GP because of that.
With the settings I like, B3X on its own uses about 23% CPU, so that frees up a lot of CPU for other sounds when disabled.

I indeed use all the other tricks for smooth enabling of the sounds as you mention. The bypass is only used when no organ is used in a patch at all.

I am using B3-X too, but in the local rackspaces.

Perhaps, yes.
I was just hoping that there was a trick to solve this issue directly in GP.
It’s just weird that instantiating a second plugin seems to entirely reduce the delay.

Also, it might be an idea for the GP developers to have a look what happens if any plugin has a delayed bypass behaviour , because that seems to stall all kinds of other processes inside GP. Ideally, GP should not wait for the bypass to be executed before continuing with the rest. Now, switching to a variation or rackspace is stalled by this delayed bypass, even causing missed notes from other plugins.

A stability improvement request, I guess.

I can confirm with a blank gig that B-3X pauses while unbypassing in the Global rackspace. There is no such pause with the same plugin in the local rackspace.
All I did was insert a B-3X into the Global rackspace, open the plugin UI, and toggle the Bypass button there on and off. The pause is very obvious.

EDIT: I did see a pause in the local rackspace with B-3X while unbypassing if there is no other B-3X plugin present anywhere else. This is clearly a bug with the plugin itself—and the only real workaround I see is to not bypass it.

I use B-3X a lot, although not in the Global Rackspace. I tend to use Blocknote on rather than Bypass, but I do find its the plugin with the longest delay to open the UI. Sometimes a couple of seconds or more. Every other plugin is almost instant.
I wonder if turning off the GUI would make a difference.