Proprietary Cubase Audio CPU

I would gladly pay for a piece of hardware that allows Cubase to offload much of its audio processing away from the computer’s CPU. Perhaps integrated into a new audio interface? Maybe a PCI-E card? Some of us, myself included, have invested a lot into exceedingly capable computers for the express purpose of music production. But yet, latency is still a huge problem. Let’s eliminate latency issues once and for all, Steinberg. I challenge you as a company as I know you can pull this off brilliantly…

Thinking plugins has the most to do - and UAD hardware allow for a solution like you ask for relieving plugins some load.
But then you face challenges like how many instances of plugins you want to support - and their special set of plugins.
Cheapest UAD version is 64 instances I think, if not 32. Starting at about $1000 or so for hardware then all plugins on top of that.
Then you can expand up to 256 instances or so.

Waves has their Soundgrid with their versions distributed over network. Starting price at if it was $3000 or more.

Vienna Ensemble Pro also allow distribution over network to process your instruments on other computers, maybe one of your old daws.
Probably cheapest solution - and about $300 and a computer you own.

Avid has their solution HD and HDX, don’t know that much about it other than it also starts at about $3000 and up.

Huge problem with latency - a modern interface would allow 32 samples ASIO buffer.
And as project grows you freeze instruments and tracks to free cpu doing just audio which virtually is a breeze for computer.
Just summing the audio you can run 200-300 tracks or more on any modern computer, not even the beefiest Xeon needed.

Testing Firewire 7 years ago, I would loose 8% of cpu on a new i7 quadcore Windows machine - just keeping audio up. No daw running even.
So dropped that idea since I could not go below 128 samples latency anyway. For three months testing various firewire interfaces and cables and cards.

So choice of audio interface matters a lot if you have to run small buffers.

A few solution that exist…

These are manufacturer-specific processors for their own plugins. What I propose is a DAW-based solution specifically designed for Cubase regardless of whose plugins you’re employing.

My current interface is the UR44, which seems quite good sonically, but are there other interfaces that provide greater dsp for latency reduction?

I think you expect too much from usb based dsp processing.
Technology is often like that - what you gain in one regard you sacrifice in something else. Lower cpu - higher latency - make your pick.

All is usb - your basic audio in/out - and for effect you need audio to go through usb to device - be processed - and then back over usb again - this for every instance of the effect you are using. And this is usb 2.0 - not even usb 3.x device.

And this is also for plugin especially written for this device as well, Steinberg plugins, just as UAD and Waves I mentioned earlier.
Every plugin has it’s own algorithm what to do.

Masters of low latency and load overall is RME in my view. They crushed many barriers regarding what you could get over usb in latency with the audio itself. Best you got before they went into the usb game were pretty much 256 samples, and they came out with numbers unheard of over usb at the time. 64 samples and like that - this was 14-15 years ago.

I think Focusrite has some unit with dsp inside as well. Including their VRM box software that emulate various monitors in a room.
If RME have something that on top of audio that do dsp as well, I have not really checked.
But it all boils down to - dsp in hardware need audio to go two ways and be processed in between - for every instance of a plugin.

Yes, I agree that USB is mostly inadequate for processing today’s plugins. Two instances of Zynaptiq Adaptiverb is enough to practically cripple my Xeon-based computer paired with the UR44. This is unacceptable given how much this computer cost me. Hence, my request for dedicated Cubase hardware. In the meantime, I am going to try an RME UCX to see if I can shave off some milliseconds.

So you want a PCI-E card on which you can run any plugins without latency and more processing power than your Xeon? Keep dreaming.

Yep… I surely will. Except that the “dream” is actually a reality and has been for quite some time, but it’s produced by Steinberg’s strongest competitor:

It’s past time that Steinberg developed a similar system. I truly believe that the future relevancy of Cubase is at stake if Steinberg continues to ignore the elephant in the room: latency. The complexity of audio modeling is growing and Steinberg/Cubase has simply not kept pace.

So baffling that Steinberg, the developer of the VST standard, has fallen behind to this extent. It just doesn’t make any sense. Cubase has all the qualities of a world-class DAW, but it exists with virtually no relevant hardware support.

Instead of dedicated DSP, HD Native harnesses the power of your Mac or PC, so you can take on large, complex sessions.

DSP Power: n/a (CPU host)

This isn’t not a proprietary CPU like you were talking about. It does not offload audio processing to it, it uses the host computer’s CPU for that.

The closest thing that exists that I know of is V-Machine, but there’s nothing special about it. Just look at the specifications:

It matters not what form the processing happens to be in. It’s very simple: ProTools HD Native is proprietary hardware for that specific DAW, and Cubase clearly lacks such support.

Cubase’s native audio connection is through ASIO and they have their own hardware that uses that. If the latency you want to eliminate comes from plugins, and you don’t mean the minimum ASIO latency, then I’m not sure how an audio interface would fix that.

Beats me. I’m not an electrical engineer, but Avid has achieved what I’m calling on steinberg to develop, so it’s certainly doable.

You can’t run any plugins on that PCI-E card. So if you had a plugin with latency, that card won’t fix it either.

I don’t want to bash your idea specifically, but it’s such a prime example of an unrealistic feature request.

Untrue… Did you actually read the specs? Latency is addressed specifically in this system and is far superior to any Steinberg hardware in this regard.

It doesn’t run plugins… plugins that have latency will still have latency. Even if that interface has low latency.

Bingo! You just made my point. Currently, none of Stenberg’s interfaces are “low latency” by virtue of their insistence on 17-year-old USB 2.0 technology.

Your opening post didn’t state you were looking for an interface with lower than 64 or 32 samples of latency or something like that. You mentioned a card with a CPU that you can offload any plugin to.

As for the actual subject then, I’m not sure how the audio hardware interface options compare to other DAWs. Hopefully you’ll find someone here to discuss that with. My suggestion remains to be a little more calm if you self-admittedly aren’t quite the engineer type.

What might achieve the desired functionality here is a formal SDK from Steinberg to utilize GPU processing power. I remember trying a reverb plugin some years ago that used CUDA on NVidia GPUs to run the DSP code for its plugin… maybe something formalised by Steinberg would encourage plugin developers to code for GPU-based DSP and produce something stable and production-ready.

What an intriguing idea. No need to get an UAD hardware.

What is unclear is how many instances would be supported in realtime.
A single reverb effect bus is ok, but this and that for a full project?

UAD has strict number of instances that it has hardware for on their stuff.
It made me back off having to think about that.

I’m pretty sure that plugins can already do this on their own without Steinberg. But according to u-he there are problems with latency, which doesn’t make it ideal.

A few years ago there was a PCI card called Yamaha DSP factory that was integrated well into VST5/SX/SX2. 16 channels with 4 param EQs, Comp and Limit per Channel, decent reverb and other send fx, and you could combine 2 cards for 32 ch DSP without any relevant CPU load. Shame was it had been designed for no lower latency than 256 samples buffer, so it was not suitable for VSTi in realtime, and the signal path was quite fixed. I think Steinberg stopped thatkind of hw solutions afterwards and focused on native processing completely.