Cubase VST3 Idiosyncrasy


#1

We had a customer report that Cubase, on Windows 10, would freeze or crash with our VST3 plugin doing automation. The fix turned out to be related to the fact that we were doing an immediate return from the processBlock when numSamples==0.
i.e;

{
	const int numSamples{ buffer.getNumSamples() };

        if(numSamples > 0)
        {
             // do process block stuff
        }
}

Cubase doesn’t like the processBlock immediately returning with automation active, so use other means within the processBlock to deal with numSamples==0;


#2

“It’s always Cubase…”


#3

if (numSamples == 0)
   throw "Steinberg stinks"


#4

The VST3 standard says that plug-ins (and hosts) are supposed to be able to pass parameter and MIDI changes in/out of the plug-in via the process function even when the transport is not running. In that case, the number of samples may be 0, or the host may pass 0s for the audio. The plug-in is supposed to deal with that possibility.


#5

Exactly. And if numSamples==0, no processing is necessary, so it is logical for the processBlock to simply return. However, in Cubase, if automation is enabled, simply returning from processBlock when numSamples==0 results in freezing or a crash. So, beware!


#6

Did you write a bare bones plugin to test this theory? It doesn’t really make sense that a host could be effected by a processBlock that just returns.


#7

So what are you supposed to do in this case? Fill a dummy buffer with the fibonacci sequence?


#8

Nah, just step outside for a few. Smoke em’ if you got em’…


#9

It seems to be enough that the plugin “goes through the motions”, even if the for loops and functions, inside or processBlock, return right away. Passing through the processBlock seems to make Cubase happy.

If I get time to figure out why, I will look for a better explanation. But, since it is only Cubase that has the issue. And, simply not immediately bouncing back from processBlock seems to fix it. Looking deeper will be a future task when time permits.

I simply wanted to report this to save others the pain.


#10

If you didn’t reduce the test to the simplest plugin, it seems premature to assert that Cubase can somehow be effected by processBlock doing nothing. It’s just good engineering to test something like this outside of all the other factors our own codebases introduce.


#11

I agree 100%. Given time, this sort of issue can be traced down to a known cause. But, my immediate need was to get things working for my customer and it has to work with my plugin, not a generic. So, I found the issue and results I reported.

My intent was to help others. I hope it helps somebody. I’ve learned a million things on this forum, and was trying to give back.


#12

Do you have ANY host-dependent code in your plugin? Do you check for Cubase / Nuendo, Live etc. and react differently? Because that’s probably the place to look for your problem.


#13

The code us the same for all hosts. Only Cubase freezes or crashes with automation enabled.

I have not had a chance to trace this further. However I suspect it may be a timing issue since it happens only if Cubase gets an immediate return from the processBlock. Since VST3 can try to do sample accurate automation, this may be an edge case where the automation needs time that it does not get if the processBlock bounces back right away. In my case, simply allowing the processBlock to run through its algorithm keeps Cubase happy.

This does not happen with any other hosts. So, I wanted to make everyone aware of my experience, so they can be alert to the possibility of a cause for issues in their own code.

Bill


#14

This is impossible. The automation events are generated before the processBlock function gets called, for the plugin to read from. Nothing is generated in parallel with the hope of the plugin being slow enough to not cause problems. That would be extremely poor engineering that would cause problems with all fast plugins.

You have to realize that Steinberg invented VST2 and VST3. Their hosts are basically the “reference” hosts. If your plugin fails in the reference hosts, it may cause other problems in other hosts.

For the sake of argument, let’s say you have an accidental memory-writer in your plugin. Now if you write a random value into the hosts memory, it will have different effects depending on the host. Some hosts may have some resource in that location, so nothing terrible will happen when the memory location gets written to. Other hosts might have a bit of code there, that gets executed for each processBlock, but now that the code has been altered, it crashes.

I had such an issue when I started out writing VST plugins on pre-Windows NT OSes like Windows 98, Windows ME etc. I had a nullptr and without checking, wrote into it. On Windows, nothing bad happened at all. I wrote a value into 0x00000000 and read it back and life went on. On the Mac this led to an immediate segmentation fault. I was stumped by this apparent “only on Mac”-bug and blamed OS9 / OSX for my troubles. Later, when I found out that I was writing in 0x00000000, I became red in the face, fixed the bug and suddenly it worked on Mac. It was totally my mistake and had nothing to do with Windows vs. Mac at all.

This reminds me of your problem. You don’t know the cause, you haven’t investigated it at all, but you’re quick to blame Cubase, the reference host.

I sincerely hope you find the real cause and let us know, so we can all sleep easier knowing that Cubase wasn’t the blame after all.


#15

Thank you. I ask you to please understand the point of my post. My post was intended as a a heads-up. Bugs are hard to find. Every host is different. I was simply alerting the community to the behavior I have observed. And, specif call the behavior is with Cubase VST3 when automation is active. My hope is that any others that may see this issue will at least know that if has been seen before. And that an area for exploration might be the immediate bounce from processBlock since that has been observed to cause a problem.

We all learn from each other, and our experiences. My intent was to share my expetience, so others might avoid the issue. Or, someone might see where the problem comes from. Maybe it is my cide. Maybe not. I still think it is best to make others aware.


#16

I fully understand, but you have to understand my argument too, that I believe that you have a very specific bug in your code and that Cubase failing is just a coincidence.

Your whole argument reminds me of the anti-vaxxing movement. You observe a problem, blame it on the wrong cause and then defend your thinking despite evidence to the contrary.

To me you are blaming a bug in your code on the host, then informing others about the alleged host-failure, despite several others explaining that you’re premature in your conclusions.


#17

This would be pretty simple to test if the problem is actually Cubase.

Build the JUCE demo plugin and only add your return if numSamples == 0. Build it and test in Cubase. If it doesn’t fail, the problem is somewhere in your code and not Cubase.


#18

BTW, which exact version of Cubase are you referring to?


#19

It was reported in Cubase 9.5 running on Windows 10.

Thanks to everyone for their suggestions. I will certainly try all tests as soon as I get the chance. I appreciate your help.


#20

And is your plugin an audio-effect or an instrument? How many input / output buses?