I use the JUCE framework primarily for my plugins, so the VST3 SDK is abstracted away and I prefer testing in Reaper and other DAWs. But one of my users has noted a bug specific to cubase… that when the soft bypass is enabled when using my plugin, cubase’s playhead lags and has a low refresh rate.
I tried to debug this behavior, as assumably it is something to do with latency reporting, that’s the only thing I can think of, but I just want to simply attach a debugger to find out but it is not possible directly because Cubase is blocking my debug builds. I even made a release build with debug symbols but that is also getting blocked.
So next step, I tried to debug using VST plugin test host, assuming that it was the same kind of platform as Cubase uses to host plugins, but on my Mac the application either hangs on startup at the splash screen, when there are VST3 plugins installed, or when I temporarily remove all my VST plugins, VST plugin host just crashes. Attaching a debugger to VST plugin test host reveals that it is crashing because of bad memory access.
So there’s apparently nothing for me to do because neither Steinberg product is working to debug plugins.
Customer support refused to help and just directed me here.
Hey thanks for replying. Cubase does not block me attaching a debugger, I can do that no problem. What is blocked seems to be non-release builds of my plugins. My release builds run just fine in cubase but my debug builds don’t appear in the list of plugins available. When I attach a debugger I get a large amount of Steinberg’s own debug output saying how the program is calling certain methods on the wrong thread and failing at various things - it takes a long time to load, like many minutes, but eventually, I am able to run cubase with a debugger.
I’m using CLion with LLDB on Mac, M4 chip.
In terms of VST plugin test host, as a few other people have already reported in this forum, the software attempts to dereference a null pointer at startup and resultantly crashes. This apparently has been known on this forum for at least 6 months in multiple posts but has apparently not been fixed yet.
After fully notarizing my debug build, my plugin turned up in cubase, so it is indeed NOT debug builds getting blocked but plugins which are not notarized, even when they are compiled on the same machine. So that means that cubase is additionally/explicitly blocking plugin loading of non-notarized builds which has nothing to do with gatekeeper… AFAIK this effectively means, if I used Cubase as my DAW of choice to test plugins on Mac, I would have to notarize my plugin every time I make a change, which would be a workflow disaster, so I don’t understand this choice from Steinberg to intentionally block non-notarized plugins.
Anyway… I fixed the original bug. But it seems to be a bug in the way cubase handles latency reporting and it doesn’t seem to be a problem of my plugin as far as I can understand… maybe I’m wrong, so I’ll just explain what the bug was…
In the processBlockBypassed JUCE method, I used to check the current latency, and if it is nonzero, I set it to zero, so that my bypassed plugin does not introduce latency in its bypassed state. But Cubase cannot handle this and chokes.
So I solved this by simply setting a flag and only reporting the latency exactly once per bypass toggle cycle, so in the case that cubase doesn’t actually update the latency after it is reported, or takes many blocks to do so, the setLatencySamples method is not spammed every block. This is safer, sure, maybe I should have done that in the first place, but it seems odd to me that cubase is brought to its knees and can’t handle a simple “if nonzero latency, set zero latency” in the processBlockBypassed method. Whether this is my fault, a JUCE framework fault or a cubase fault, I don’t really know. It’s just a bit odd and I thought I’d report it here.
Cubase does not do any checks if a plug-in is notarized or not. I guess that somehow your code signature was invalid in your debug build and if you run on an Apple Silicon machine, any code must be correctly code signed, otherwise it won’t be loaded (by the system, not Cubase).
Changing the plug-in latency is not allowed from the process thread and must be done on the main thread. Other hosts may be more forgiven on which thread you call the latency change notification.