Enabling record or monitor on midi track massively increases real-time CPU

Cubase
,
1

I could find some reports on this issue, but all were vague and/or not specific. Therefore:

I haven’t noticed this before, probably because I never push my CPU(s) that hard. But now I did, and found out the ugly way (dropouts and crackles). It’s pretty simple, just pull up the CPU meter and watch the real-time bar. Create a MIDI track, point it to an internal VST(i) destination, place the cursor on it, and hit record enable. Watch the meter bar double or triple, and start to spike. All this with no extra processing going on. Hitting “monitor” instead of record does the same thing. Deactivate record and all is idling near zero – even with the project playing back pre-recorded midi to the same instrument/effect(!). This does NOT happen with audio tracks, just MIDI (and instrument), and only when they’re routed to a plugin (instrument or effect), not to an external MIDI port.

Iow: midi thru to VST(i) seems broken.

I get this in 9.5 and 10.0.10. Why on earth does this happen? And can it be fixed?

r,
j,

2

Hi,

When you enable Record on a MIDI Track routed to the VSTi, the processing becomes real-tine. So the CPU is used heavily. When the Record is not enabled, you can use the Buffer to collect the data and process them beforehand. So the CPU is not used so heavily.

3

Good point. Unpleasant but unavoidable then. Time to upgrade the CPU…

r,
j,

4

no I have a 7900x 10 core intel i9 running all 10 cores at 4.4 ghz. when record enabled is on, I get “real time” spikes a lot, even though in task manager, the cpu doesn’t go above like 35% usage, and coretemp shows all cpus running relatively cool.

I don’t really know what’s going on, but it seems like this real time audio meter either isn’t working, or Cubase isn’t optimized.

5

See CPU vs. ASIO Performance: Why is the performance meter maxed, but CPU not? - Cubase - Steinberg Forums for a good explanation what the audio performance meter is showing.

6

As a trained (albeit no longer practicing) software engineer, I must admit being somewhat embarrassed about not figuring out the reason for this behaviour myself. However, I do believe that some of us are equally surprised that a 2019 superduper-multicore-multi-ghz computer can’t avoid this. Yes, real-time is real-time, and buffered playback is something else, but it does seem that the current engine is not quite there yet.

I really hope that you’re able to improve on this. Bring on 10.5 :smiley:

r,
j,

7

My recent exp.
What VST instrument is being used makes a big difference.
I saw the same happened with Halion inside Cubase.
Figured out that works best is to set the Cubase ASIO to Deselect: Multicore support.
On Halion, enable multicore support, forget the warning since it does not apply, we just deselected Cubase multicore support, hence not both running in that mode. Also reduce the number of Max Voices in Halion if 128 are not needed to something more reasonable. If using instruments as lead and no polyphony is required, select under Halion Edit for the selected, loaded slot: Manage Voices - On and then Mono. Will free up lots of CPU realtime work.
Do the same minus the mono thing if using Groove Agent.
This on a Macbook Pro, late 2014 i7-2.5, retina, 16gb ram, 500gb ssd. Steinberg UR44 USB interface, buffer at 512.
On my PC i7 4790, Windows 10, 32Gb memory and Focusrite thunderbolt interface I can reduce buffer to 128.
Highly recommended to get further info, Richard Ames Music on YouTube. He runs complete VSTi orchestras and shows how he tests his system to determine what given what VST you are using. Some VST are more demanding and cannot get as many voices before clipping.