Well, my current workaround is to add a second instance (also in the Global Rackspace) which is not connected to anything and also bypassed itself. No more delay… Or at least, no noticeable delay.
EDIT: Doing this also does not increase the CPU load.
An interesting note: If you put B-3X inside Blue Cat Patchwork Synth, you can bypass and unbypass the slot it occupies in Patchwork and there is no pause at all. You still get the CPU savings while it is bypassed. It also improves the delay in the notes when coming out of bypass.
So that’s essentially the same behavior as the plugin being on a regular rackspace
Interesting – I don’t know if @cuebert has the GUI window open but if he does, closing it would be an interesting experiment
No, I found there is a pause even in a regular rackspace if no other B-3X plugin is present in any other local or global rackspace. Using Patchwork allows for no pause with no other plugin present.
Also, the issue is not tied to having the plugin UI open.
Indeed. There is no difference whether the UI is opened or not.
Actually what I meant, and it was really just a very random thought, was to disable the GUI. IIR you can do that in Cubase and only have a list of parameters open when needed. I was just wondering if this might be something we can do in GP and whether it might speed things up. Probably more relevant to opening the GUI than your issue though.
Tried to reproduce it with no luck.
Should it be reproduced using a blank new gig, adding the plugin to the global rackspace connecting it with MIDI In and Audio Output, play and then bypass/unbypass?
Sure, new gig—add a B-3X plugin to a rackspace.
You can either map a widget to the Bypass parameter or use the plugin UI, doesn’t matter.
Toggle the bypass on and off.
When unbypassing, there is a pause.
Yes, i also could reproduce the Un-Bypass lag.
Since someone mentioned it wouldn’t happen if there is another instance present, i tried to have two instances in the Global Rackspace, but leave one in permanent bypass, so it wouldn’t consume CPU cycles… it works.
So as a temporary workaround, use two instances of B3-X but leave one bypassed permanently, so there’s only one instance to be processed, and the bypass/un-bypass can happen instantly.
So if I understand correctly:
One other question for someone to test.
Rather than adding a second instance of B-3X to the global rackspace, what happens if you add a different plugin to the global rackspace and leaving that permanently bypassed? Does the B-3X behave itself or is the delay still there?
No, as has been stated a few times now, it happens in any rackspace, local or global, when there is no other instance of B-3X anywhere.
So far, yes–only B-3X is affected.
Yes, its a workaround for the issue.
That doesn’t remedy the issue. It has to be another B-3X instance.
Ok so that suggests a bug in B-3X
If inserting another plugin and bypassing it causes the B-3X to work I would be definitely suspecting a GP problem. But if it only happens when you use two B-3X instances, then that suggest something very funky going on with the B-3X itself
I missed that one. That eliminates the possibility of their being something funky with the global rackspace as well
Yeah, its definitely some coding issue with B-3X. Perhaps some things that were meant for a visual thread got put in an audio thread instead. Just a hunch, based on the odd way the plugin UI loads.
I agree. It’s definitely weird only B-3X acts like this.
However, I just tried to reproduce the behavior in Reaper (as VST3) and Logic (as AU) and neither show the same behavior, at least not visually. I cannot try now while playing something (not behind my keyboard), but I suspect it may be fine.
So, funky code in B-3X, yes, probably, but somehow triggered by how GP handles the bypass routine, maybe?
EDIT: I just repeated my test in Reaper while playing a MIDI track. Bypass seems to be have as expected: instantaneous.
