Rack overloading CPU

[mchoffmann]

I built a nice rack with 3 synths bring separate by Channel /keyboard split. All works find but i get overload spikes since the whole rack seems to go to only 1 core. Still i only have 1 midi in so i cant use multiple tracks. Is there something i can do to utilize the other cores as well?
Regards
Marc

[Peter Widdicombe]

You CAN create virtual midi inputs in tracktion; and these are tied to the actual midi you have. So if you create virtual1 and virtual2 connected to the "real" midi input.

If it's existing midi in a track, I suppose you could use a rack to send the midi output to various other tracks ?

[mchoffmann]

Thank you,,
i have to check that when i´m home.
I use the Rack to play live with different SoftSynths for several Areas on the Keyboard so multiple tracks won´t help.
If i get to split the rack i hope to utilize more than 1 core......

Regards
Marc

[jochicago]

I don't think I can help with the 1 core thing.

I do send the same MIDI into more than 1 track. I use the rack feature to create a second output using the + button on the bottom right hand corner "add to track". Wire the MIDI through the rack and now you'll see a rack send on your second track.

I'm not sure that putting stuff into a second track will use a new CPU core/thread. From my experiments, it seems that any tracks that are linked by output/sends will be processed by the same CPU core, although I have experimented on CPU usage with audio tracks, not MIDI.

[zzz00m]

While I have not tested the individual CPU core usage with Waveform, I have heard that in general use with any DAW, all audio processing on one track most be processed in a serial fashion on a single thread.

That means there is no way possible to multi-thread the computation for that track. Each operation on an audio chain is dependent on the output of the one that precedes it. So that is the limiting factor. No plugin that depends on the output of a previous computation can predict what that result is until it happens. So for an audio track, all of its plugins and racks, etc., is a serial process. Makes sense that it would only use one CPU.

I'm not sure how Waveform treats separate tracks regarding CPU cores. It would be ideal if it at least split tracks out across available cores where possible.

Regarding the MIDI inputs and sending one input to multiple tracks, using virtual MIDI inputs works very well. I use them all the time! Set them up once and they will be available to any project you open. Whether that helps with the CPU load or not is still a question until someone can explain how Waveform is optimized for core usage.

[HansP]

I looked up for DSP FIR IIR FPU parallel computing.
There is math for this, that can break up the computation in several ways.
There is SIMD - single instruction multiple data. It was conceived already in the 70ies. etc etc etc

Seems, in DAW context no one has done that so far.
Probably, the VST paradigm is not capable.
Still, there could be a bucket brigade system, but it would have to use buffers and create multiple latencies. Math pa more.
Sure will be quite a challenge.
Let's just wait
Some genius will do it one day.

[dRowAudio]

We use SIMD all over the place. These are low-level instructions for performing maths on contiguous blocks of memory. They're not really suitable for high level graph operations and are completely separate things to multi-threading or processing on different cores.

[Peter Widdicombe]

Probably more of a VST thing, but...

I used to always use SFZ for strings, horns, etc. However, when I got my next computer, it sounded horrible. I had to run Tracktion (3 in those days) in single-core mode. SFZ seemed to be the only VST that was afflicted that way; but even back then it appears multiple cores got used.

Newer versions of Tracktion must allocate differently, as I can use SFZ again.

[HansP]

We use SIMD all over the place. These are low-level instructions for performing maths on contiguous blocks of memory. They're not really suitable for high level graph operations and are completely separate things to multi-threading or processing on different cores.

That's true and it seems I am mixing things up.
But still, the basic ideas are not based on particular hardware systems, but seek to develop various ways to use parallel hardware processing units and parallel memory structures.
It became later a family of concrete instruction sets in certain architectures.
It does not rule out that processing cores share the data and work together on it, following some more versatile patterns. Becoming thread-oriented was a practical solution. There are more possibilities than that. What about a meta-SIMD that for a limited task involves 256 math units in full sync for the same big block of data? To have motherboards and CPUs optimized for that one (competes the GPU concept e.g. for block chain, and it might IIR an hour of hi-res audio in a second).This should be transparent to thread structure and operation. But it takes planning and announcement of matters at run-time. At least in the lab, such a thing likely exists.

(I have touched a VAX and a PDP11 and what have you, and in the lab they were extremely versatile beyond what the OS normally could do. So, this continued with discrete hardware for multi-processing, and CPUs came years later. Today, let's mention the Hypervisor guys among those who are challenging the hardware, and organize virtualization and parallel operation.)

There are examples online, about how to break up a polynomial function to be computed by more than one math unit at the same time, so to be faster. It is a very general idea. How the processes get implemented and shared, there can be many ways, more than currently worked out in available OS's.

This would mean that an EQ itself could organize the collaboration of CPU kernels. Which is not the rule and habit in current systems AFAIK.
In a theoretical, innovative system, the optimizer would dynamically do:
a) Low-level organization of computation among kernels about blocks of data, on the granularity of certain operations within complex plugins. A thread would become something that can borrow additional kernels or units in a GPU for sync'd matrix operations.
b) Thread-level organization of graph processing, with dynamic granularity.
c) Rearrange graphs into structures with equivalent results, and evaluate efficiency.

In other words, the threading concept is not intelligent in a way that on meta-level it would know and understand what it is actually doing at the moment. Therefor comes the idea of an optimizer, that is being created for meta-level intelligence, that can plan and estimate efficiency of kernel use corresponding to the actual task and audio graph.

currently this is more like science fiction and I am not a CPU guy so I write this in a smaller font.
take it with a grain of salt. ^_^
but it is clear that the task would be huge.

[dRowAudio]

As DAW developers we also have to weigh up the reality that in hosts, most of the CPU time is taken up by plugins. We can optimise forever but if you've got a hefty plugin in the chain, we need to wait for it to complete.

[mchoffmann]

I was just wondering if there would be a chance (in the future?) to split up the rack and its plugins to utilize the CPU power existing in my machine. The way it works right now i can easyly set up combinations that make my system unmanageable.

Cheers
Marc

[dRowAudio]

Yes, there's a (hopefully good) chance this will improve in the future but we don't have any immediate plans for this I'm afraid.