Could multi-Bounce to Clips be made more multi-core friendly?

[sreams]

I've been doing some drum timing adjustments using Audiosnap. I have 12 tracks of drums. All are set to use Radius Mix for offline rendering. When I'm happy with my adjustments, I select all of the clips, right click on one, and choose "Bounce to Clips".  It then takes a very long time to complete the task. Looking at Task Manager, I can see that only one thread of my 12-core/24-thread Ryzen 3900x is being utilized. Overall CPU usage shows as just 6%.

It seems that if each bounce could be processed on it's own thread, processing time could be reduced by massive amounts. Any thoughts on this from the bakers?

Edited August 28, 2020 by sreams

[Gswitz]

 

 

There is a button to balance FX across threads better. It depends on what you are doing as to whether this helps.

[sreams]

47 minutes ago, Gswitz said:

 

 

There is a button to balance FX across threads better. It depends on what you are doing as to whether this helps.

Yeah... this is a different issue. "Bounce to Clips" is always done one track at a time with the current Cakewalk engine.

BTW... looking at your video, you can see much more clearly what is going on with CPU usage in Task Manager by right-clicking on the CPU graph and choosing "Change graph to -> Logical Processors". It will then show all 8 threads and their usage on your Core i7.

Edited August 28, 2020 by sreams

[Bill Phillips]

On 8/27/2020 at 10:34 PM, sreams said:

BTW... looking at your video, you can see much more clearly what is going on with CPU usage in Task Manager by right-clicking on the CPU graph and choosing "Change graph to -> Logical Processors". It will then show all 8 threads and their usage on your Core i7.

Thanks!

[Noel Borthwick]

Unlike normal export or bounce to track, Bounce to clips can't easily be done in parallel - at least not easily.

The bounce code essentially relies on the audio engine which is optimized to render independent tracks for contiguous sections in parallel. With bounce to clips you are rendering chunks of data at different points on the timeline. So its not as a simple process to do this in parallel since we'd need to have multiple instances of the engine render the discontiguous sections of audio in parallel. Additionally the radius rendering isn't currently optimized for multi processing and could have bugs handling this.

In short this would be nice to have but it would take a lot of work to achieve.

[sreams]

1 hour ago, Noel Borthwick said:

Unlike normal export or bounce to track, Bounce to clips can't easily be done in parallel - at least not easily.

The bounce code essentially relies on the audio engine which is optimized to render independent tracks for contiguous sections in parallel. With bounce to clips you are rendering chunks of data at different points on the timeline. So its not as a simple process to do this in parallel since we'd need to have multiple instances of the engine render the discontiguous sections of audio in parallel. Additionally the radius rendering isn't currently optimized for multi processing and could have bugs handling this.

In short this would be nice to have but it would take a lot of work to achieve.

Makes sense. I wonder if the B2C algorithm could then analyze how the clips relate to each other in time before starting the process. Many times, the clips I'm bouncing all have the exact same start and end times, so being aware of that and then processing them together would make sense. For clips that don't start/end together (let's say you have one that spans 3:01:000-10:01:000 and another than spans 5:01:000-12:01:000), then you could still run the bounces in parallel by drawing a virtual "box" around them and running the bounce from the earliest start time to the latest end time and including each new clip as its start time is reached during the pass.

Of course... I know very little about the complexity of coding such a thing.

Edited August 29, 2020 by sreams

[Noel Borthwick]

That wouldn't really help since today the parallel processing occurs at the track level, so knowing about contiguous clips wouldn't make it easier. One approach could be splitting each clip into a new track behind the scenes and then bouncing the whole split project splitting the track outputs to new files.