Cubase 14 Pro and VST3 plugin automation visual lag

Cubase
1

Dear forum members!

After a long pause with Cubase I returned a few weeks ago with a new Pro 14 setup and ran into a minor but a little bit annoying behavior with the Reason Rack Player VST3 plugin. The automated controls in the RRP are not following the automation curves in Cubase, they jump around quite badly. As far as I could tell after doing a few renderings and null tests, the audio is not affected, only the visuals. Here’s an example:

RRP 13 automation in Cubase14:

Did a few tests with other plugins, which seem to work well. For example a side by side comparison with NI Driver:

I also tried loading RRP via another plugin (Voltage Modular) and it was working well:

I tested it in multiple DAWs on the same system. Bitwig, Reaper, FLStudio, all are working fine. Here’s a demo in Bitwig:

I also did a fresh Windows 11 install, with the bare minimum setup/drivers, and the same:

I also tested it with the CPU’s built-in GPU, and a different display (4k TV), nothing changes.

Since I’m on Windows I’m trying to optimize the system to my best knowledge: running the latest versions, having the latest drivers, studio driver for NVidia, using optimized high performance power plans, disabling core parking, etc.

I have contacted ReasonStudio support and we tried disabling OpenGL in Reason, which had no effect, and they are out of ideas and I believe this is not a Reason bug.

I also tried contacting Steinberg support, but I got no response yet.

Not expecting miracles at this point, but I was wondering if there are any similar cases, or I’m just having bad mojo lately. I appreciate any feedback!

These are my systems details:

MB: Gigabyte Z790 UD, latest BIOS
CPU: Intel i7 13700K
RAM: 32GB DDR5 / 6000 Kingston, (2x16 GB Kit)
GPU: Nvidia GeForce GTX 1050 Ti, Studio driver, 572.16
System Drive: Crucial 1TB P3 Plus NVMe M.2 SSD
PSU: Seasonic 750W Focus GX 80+ Gold
Displays: 2x Dell U2412M displays at 1920x1200, 60Hz
Audio: Focusrite Scarlett Solo, 48kHz, 256 sample buffer size, (driver version 4.124.3)

Windows 11 Pro, 24H2, 26100.3194
Cubase Pro 14 (14.0.10, Build 144)

2

I also have ASIO Guard enabled and I’ve noticed that disabling it slightly improves it, but not completely. Same goes for enabling record or monitoring on the track, which AFAIK does the same, disables ASIO guard for that particular track.

3

I did some more testing, and it seems like it’s not a Reason Rack specific issue, I’ve managed to reproduce it with U-He Hive, but only with the VST3 version.

VST2 on the left, VST3 on the right:

4

can’t be of much help. I do not have these problems with Hive or any other automation in Cubase

5

Thank you! I’ve never seen a similar issue. I did some more testing and I have pinned down to a few plugin developers:

  • all the VST3 U-He plugins behave like this, the VST2 versions are fine
  • same for Voxengo LF Max Punch, VST3 lagging, VST2 smooth
  • Brainworx Vertigo VSM-3 and bx_aura VST3 were also lagging, could not try their VST2 version
  • and Reason Rack Plugin VST3

But many others from different developers are working fine: all from Native Instruments, Synapse Audio, Softube, Korg, Arturia, UAD, Waldorf, AudioRealism, IK Multimedia, UVI, Sonic Academy, Tokyo Dawn Records, XLN Audio, Eventide, Valhalla.

Maybe there’s something common, like they are using the same UI framework, or VST3 version. Don’t know.

I could also reproduce the same with Cubase 13 and 12, so it’s not a new 14 thing.

6

You can check the VST SDK version in the VST plugin manager.
I have only one U-He VST3 instrument, that works flawlessly.

If one has an issue that is non-reproducable by others it is always a good a idea to try starting Cubase with factory settings.
Here is a little guide how to achieve that:

Where it says Cubase 13_64 you’d have to use Cubase 14_64 for your C14 version. All settings can be restored in case you find no improvement.

7

Thank you for the suggestions! As I’ve mentioned yesterday I also did a clean new Windows 11 and Cubase 14 installation on a 2nd drive to experiment with a clean slate so the preferences were pristine. But I tried resetting the original installation’s preferences anyway and no difference unfortunately.

This is what I don’t understand yet: what are the common problems that survive a new OS and Cubase installation and switching to the internal GPU too and a different display? Also having the same issues with Cubase 13 and 12.

The Windows version is the same, the soundcard and it’s driver version, mouse, keyboard, midi keyboard, RAM, SSD and a webcam. I could start eliminating those one by one, but Bitwig, FLStudio and Reaper are working fine with the same configuration. It’s hard to imagine what could be so different with Cubase.

8

What happens if you throw an LFO modulator onto the parameter instead of track automation? Also jumping eradically?

9

Modulators are working fine, only the automation is lagging. Great question, thank you, tried it, but forgot to mention. Appreciate the suggestions a lot! :+1:

10

Really, modulators produce smooth movement but track automation doesn’t?
Can you post a screenshot of your automation panel settings?

grafik
grafik594×220 5.52 KB

11

Another thing:
If you load the modulator ModScripter, but just the default, without a script, it will send its input signal to its ouput signal.
Can you please load a ModScripter, send track automation to its input and then make a connection to one of the troubled parameters? Set the connection to uni-polar, dial at minimum, depth 100%.

grafik
grafik635×422 19.9 KB

What happens then?

12

Yup, modulators are fine. Just recorded a video to show the difference:

Even changed the tempo and the LFO followed it well.

That’s how my automation panel looks like:

image
image610×226 5.56 KB

In the meantime I tried it with another NVidia driver (an earlier one), uninstall my Logitech app, removed the bluetooth dongle and the webcam, unplugged my Focusrite and tried with another cheap USB card, but no changes at all. Maybe the CPU cooler is the culprit :smiley:

I will try the modscripter, give me a few minutes. Thanks again!

13

From 1:05 to 1:20 we can see that the modulator knob, even though bypassed, mirrors the automation data sent to and received by the plugin. It looks silky smooth at that stage. That means the plugin must also receive the smooth automation data.
This surely is weird.

14

It is smooth via Modscripter:

15

The modulator knob shows it’s LFO’s movement (I set it to the same shape and frequency and from min to max as the automation) from 1:05 to 1:20.

16

Another demo with Hive and modscripter:

17

If you set the connection of a modulator to bypass the dial on the knob will replicate exactly the parameters movement, not the input from its own modulator.
These two tests show that the modulation data, that is being sent from the track is smooth and does not induce the erratic jumps.
But the same plugins work on other DAWs (also VST3 version, not Clap or so?).

This is really weird.
Normally I would suggest to also bring this to the attention of the plugin developers but Reasons Studios and Urs (U-He) are amongst those that dislike VST3 the most, so they’ll probably just say that it must be Cubase’s fault.
On the other hand - the audio is smooth, the modulation signal entering the plugin is smooth and the plugin is solely responsible for its GUI. Cubase just delivers the VST value, it does not move the fader.

18

Oh I see, didn’t use modulators much yet, didn’t know about the bypassed behavior, thank you!

Yes, I tested the VST3 versions everywhere.

I have opened a Reason Studios ticket a few days ago and we agreed that I will update them if/when I get a response from Steinberg. I know about the stance of U-He regarding VST3 / Clap, so I wouldn’t expect much support either, but maybe I will contact them.

It’s not a showstopper and as you said, the audio is smooth, I can live with the rest, I was just wondering if this is something with my configuration or reproducible by others too. But I think I really gave my best to isolate it as best I can, but pretty much nothing affected it.

Worst case I’m going to use the modscripter a lot for these plugins. I appreciate your suggestions a lot, thank you!

1 Like
19

I confirmed this using HIVE2’s VST3.
I’m using an M2 Mac, and I get the same stutter when the process size is 2048. There is some stuttering at 1024, but it is slight. If it is lower than that, it will appear to move smoothly.

The bottom line is that the smaller the process size, the more accurate the automation and the better the sound quality. Instead, the load will be higher.
When exporting offline, ASIO-Guard has no effect, only the buffer size.

Additional information below

In Cubase, during playback and real-time export, the automation accuracy varies depending on the process size.

Process size is determined by a combination of buffer size and ASIO-Guard level. If ASIO-Guard is off, the buffer size becomes the process size.
When ASIO-Guard is on, the lowest process size is low:256, normal:512 high:1024. (However, it will be slightly different if the buffer size is not 2 to the n power)

I investigated the above by actually creating a VST3 plug-in using VST3SDK. I haven’t checked it with VST2 plugins, so I don’t know if it’s the same.

Additionally, automation accuracy has been found to vary depending on other DAWs and settings.
More specifically, it is possible to absorb some differences in behavior due to process size on the plug-in side, but it seems very difficult to do exactly the same.

Use Google Translate

1 Like
20

You wrote your buffer size is 256 samples. Can you run the automation with 64 samples and see if that changes anything?