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.
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.
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.