Long pause when using a control in Cubase VST3 plug-in

High when I test my finished VST3 plug-in in Cubase I’m getting a 2 second pause when I first click a control, then afterwards it seems to run smoothly. I can’t use VST3 because of this.
I’m using OpenGL which renders 2 quads. They do use a simple shader that renders a frequency map and a loudness graphic, both set to setContinuousRepainting.

This is only a Cubase problem, but I’m surprised it hasn’t been spotted before.
I suspect it might be something to do with Cubase wanting to repaint quite quickly compared to other hosts.
edit running the same build as VST2 is fine in the same host (Cubase LE Elements 9).
I’m using a brand new iMac with Mojave, and 5.4.1 of Juce.
Anybody have any ideas?

It’s always Cubase and VST3, right?

Have you tried disabling setContinuousRepainting or trying to pinpoint where the hickup is?

Out there question - is the control doing anything with MIDI? Is it tied to the start of playback at the beginning of a project in Cubase? I’ve had a lot of problems (going back to Cubase 7) with MIDI and playback missing MIDI input at the beginning of a project, it’s a bug that I don’t think has been fixed and is very temperamental.

Yes VST3 Cubase, of all the hosts it would happen to, it would be Steinberg’s baby!! :slightly_smiling_face:
There is no MIDI on the plug-in.
This is just one instance in a completetely empty project. I boot Cubase as ‘empty’ then add an audio track then add my plug-in to an insert, and that’s it. It’s not even playing anything, that makes no difference anyhow.
Disabling continuous repaint will just break my plug-in, but I’ll try it to see if anything changes anything.

Turning off continuous repainting on both panels fixes the issue, but only turning off ONE of them reduces the pause - it’s still about .5 seconds but it’s still there.
Anyway my plug-in needs continuous updates, is there a way of slowing the updates down? It would be OK if they were just half, I could live with that, a bit of a compromise, but an OK one I suppose…

Just tried the develop branch - same problem.
edit this is ALL in Release BTW! Debug is just as bad.
edit2 It doesn’t matter what I set SetSwapInterval to either, it could be 0,1 or 300. (Incidently I had to set the interval in newOpenGLContextCreated() because it didn’t work at all in the constructor)


OK I think I may have found a compromise, it turns out that using SetSwapInterval(0)
actually works and un-sticks my Juce controls. BUT it renders at lightning speed now which fooks up my graphical, frame based animations. Not to mention it quite scarily could interfere with other software, not to mention other instances.
So now I’m going to have to put in my own timer in my renderOpenGL function which skips frames - Why do I have to do this crap!! [whimpers silently, goes to lie down somewhere…]

This of course creates a lot of tearing where the vsync is missed but it can’t be helped at the moment, I’ll just make it a VST3 specific thing in my code.

I’m seeing this issue as well, where mouse down events in Cubase 10.5 don’t seem to get picked up for 1-2secs, when I have an OpenGLRenderer with setContinuousRepainting(true). setSwapInterval(0) also has no effect on the mouse lag. It seems that only setting setContinuousRepainting(false) solves the issue, I’m relying on setContinuousRepainting(true) in order to get smooth rendering, as using a Timer can be choppy due to the lack of precision.

Has anyone else encountered this, and been able to work around it while keeping continuous repainting?

Ping. Still an issue. Has anyone found anything new on this front?