Can we have multicore function for each channel please?

Hi Cubase/Steinberg (if anyone from the company is reading).

Any chance we could have multicore function per channel, i.e., when one loads more than one plugin on a single channel, having Cubase to distribute each plugin to different cores, for better performance?

From what I understand, as it stands, each channel is managed by one core, including all its plugins.

Cheers

1 Like

This topic, or similar, has been discussed many times before on this forum.
The way I understand it is that it does not make sense to split up the processing of different insert plugins on a single channel onto individual threads since the whole process is serial. Plugin #1 has to finish processing before plugin #2 can do anything (since it’s processing the output of plugin #1).

1 Like

Sigh…I see.

Yes but, if one splits the plugins as per, Channel → To Group 1 (One Plugin) - Group 1 → Group 2 (Second Plugin) and so on, the plugins are split into several cores.

Why does that work and having a single channel doesn’t? Steinberg has to figure this out…

1 Like

I don’t know the full philosophy behind how Cubase assigns threads. I’m assuming it works that way because you normally assign multiple channels to a group track. In your example, the principle of serial processing still applies and assigning the two plugins (or channel paths or whatever you want to call it) will not have any performance benefits. The thread assigned to your ‘Group 2’ channel will sit idle until the thread assigned to ‘Group 1’ has completed its buffer.

But it does though. I asked Greg Ondo at his streaming, and he advised to take this action as I was struggling with mastering exporting times, he suggested for me to do what I described.

It actually worked. Greg suggested that this way the plugin weight would be distributed to several cores, and it actually worked for me, I shaved quite a bit of time on exports.

I don’t think so. At least not in this example:

It gets more complicated when the group tracks receive from more sources.

There could also be differences when rendering or doing a mix down (not real time) compared to playing back the project.
Since you didn’t mention render or mix down, I assumed we were talking about playback.

It did for me.

Fair enough. However, the split (groups) seems to be working. I am not a programmer, but programmers at Steinberg are working on processes that I can’t come close to understand what they are doing.

I am sure they can figure it out. I get your point, but there has to be a new innovation within Cubase to make this work. It would help workflow and exporting to a big degree.

If we’re talking about rendering or Export Mix Down, I agree. There are likely room for optimizations.
But for playback, the logic still stands that plugin #1 has to finish before plugin #2 have anything to work on.

I wish I could find the thread where one of the Steinberg developers briefly explained how all this works.

Hung on, is there a thread that a dev replied?

In any case, here’s hoping.

It would be enough for them to integrate an internal wrapper for each plugin similar to Audiogridder by default, which they would then redistribute to the various cores. Incidentally, at this point it would be really great if they offered the option, just like on Audiogridder, of being able to use networked CPUs. Imagine an integrated Steinberg ‘Audiogridder’ without all the hassle of having to load the wrapper and then the plugin…

3 Likes

oh yes!
Audiogridder is a life saver.

I believe it works as Greg described because at a finer level of detail, the thread for a logical groupings of plugins can run on different cores. Think of the plugins on a single audio track mapping to a “thread” that is essentially a chunk of DSP - or a job - that has to be run. Similarly for a group of plugins on an FX channel. If the audio channel sends to the FX channel, that means the thread on the FX channel has a dependency on the thread from the audio channel, i.e., the FX channel thread has to wait for the the audio channel thread to send it audio data. But those 2 threads might run on different cores simultaneously thereby better distributing the load. Multiple threads may also end up running on the same core. Applications running on the machine present one or more threads to the OS to run with different priorities; they are all competing for run time resources. A single application that is written “multi-threaded” to do its work may run 100’s of threads, but the key is they usually all don’t have to run simultaneously and they are not all high priority. I don’t know the Windows OS details, but at least on MacOS, it is the OS that decides or schedules what thread(s) from what application will run on a particular core. The application does not pick a core and say run my thread(s) here.

It works the same on Windows. The application creates a thread, the OS distributes it to a core.

steinberg please please please take a look at how Vienna Pro & Audiogridder are managing VST’s. I have to constantly render in place to prevent ASIOGuard drop outs with hardly anything happening. Without a doubt I was able to do more on less powerful & older Cubase / mac setups.

Please help.

1 Like