Bitwig's cpu core allocation per track?

[Echoes in the Attic]

Stamp, are you running a laptop or desktop?

[stamp]

Stamp, are you running a laptop or desktop?

Desktop. I had a laptop too but it was stolen from my car.

[sth]

Very simply: have you maxed-out every core on your machine? No? More cores will not help. Did you max them for 5-minutes today? OK, more cores will help you the next time you do that 5-minute task.

But, faster single-core performance will _always_ help.

I was maxing out my old 4 core (I7 4770).
...
So getting an 8 core seems like a no brainer, imho.

Exactly as I said: if you are 100% on every core for an extended period of time, then more cores will help. Just doubling core count is not a no-brainer, however. It's highly likely that if there was another option with 6 cores but a higher single-core performance, that you would have seen the same or probably better performance as preferring core count.

The contrary is also true, though, and it's unknown if that's this user's case. If you are *not maxing* then more cores *will not help.* Single-core performance will *always help.*

The situation I described is the "bounds" on this potential parallel processing problem; it's not necessarily how Bitwig has handled it, it's just a theoretical limit on any option they choose.

I'm certain that they're not heavily-multi-processor capable. They've probably even found that (due to this problem space where allocating/deallocating memory is many times more costly than the processing itself) in many cases it's faster to limit the parallelization!

[Taika-Kim]

I wouldn't hold my breath about quantum computers, they won't be applicable anytime soon for general usage, probably for a long time they can be only used for very specific calculations.

About GPUs, yes they are good for only some things like convolution etc. About additive synthesis, maybe, that could be probably configured parallel. But then again it can be very optimised even without, Alchemy, Vertigo and so on could run thousands of oscillator without a big CPU hit.

I have sent them already a long time ago the idea about both a resynthesizer and also an additive synth. But for an additive synth the UI is a big big design problem, since many additive synths I've tried really don't even touch the potential, since editing lots of partials directly is a problem for the user, as is understanding what is happening, and how to achieve a sound you have an idea for. But please send them more requests, maybe we'll see this

Btw on the subject of additive synthesis, try these: https://bitwiggers.com/presets/e8727812 ... 8c01b3c31/
https://bitwiggers.com/presets/c9b99c0c ... 3e86ffdb5/

I'm also interested in neural CPUs that work very differently from traditional linear computers. There's a ton of super interesting research happening now on deep learning and sound, and some of the applications are already useful in a production context, we just don't have designed plug and play ready VST products available generally.

How's all this for OT ?

I noticed now when I was building a quite complex resynthesis patch, that if a Grid effect can be split to layers (like when you do frequency splits etc that all follow the same logic), CPU usage will be greatly reduced when splitting the effect to several tracks. By grouping them the benefits are not lost. I'm talking here about something like 10% vs 90% DSP load in the best of cases. The only problem would be creating a "master" remote page for the split effect, which I haven't tried yet doing, but should be possible with Audio Rate modulators and DC generators.

[xx JPRacer xx]

No, we don't. Just because Intel is stuck in it's 14nm loop since 6 years now doesn't mean we have reached the limit of single core performance. Look at Amd with it's 7nm process and nearly 20% more ipc (instructions per clock) vs Intel.

Yous should take that 20% more IPC with a grain of salt. Most of these claims come from Cinebench benchmarks and that's it. Most game benchmarks at identical clock put Intel in the lead and you should take at look at this: https://lemire.me/blog/2019/12/05/instr ... sus-intel/

In most benchs (except Cinebench), at equal clock speed, Intel is still in the lead for IPC. Overall multi-core performance... ok, Intel can't compete especially for the price and power (Watts) difference.

[machinesworking]

Personally my experience with Bitwig bears out a pretty straightforward relationship between number of cores and amount of plug ins that it can run.

It should be mentioned that the plug in itself can make a huge difference. I did a shoot out between Reaktor and Diva, pitting Bitwig and 4 other DAWs against each other, and Bitwig does fantastically well with Diva on the Xeon chips. Beyond that Bitwig is very uniform in it's CPU use VS core. [Edit] The Macbok Pro is a 4 core 2.7 i7 16GB RAM. The Mac Pro is 2x6 core 3.33ghz Xeon 24GB RAM ----

Slightly faster note run, just to stress the system a bit.
120bpm 32 8th notes four bar run.

Macbook Pro
Results

Diva

Bitwig - 16
DP 10 - 13
Reaper - 19
Live - 10

Reaktor
Bitwig - 19
DP10 - 13
Reaper- 26
Live 9



Mac Pro

Diva

Bitwig 24
DP 11
Reaper 12 (not responsive, crackles if you do anything)
Logic 8 (I feel like I should get better than this in Logic)
Live 9

Reaktor

Bitwig 32
DP 62
Reaper 64
Logic 56
Live 8


Basically, the older DAWs drop the ball with diva, mostly only able to run one or more instance per core, but the opposite is true for Reaktor with them easily running 55+ instances of Blocks, DP running 5 instances per core as an example. Conversely Bitwig can run 4 instances of Diva on the macbook pro compared to the others.

I'm getting the distinct impression DAWs and plug ins can both run various instruction sets on chips to gain performance, and depending on the DAW and plug in, you're going to get wildly different results. What's interesting to me is I chose these two for availability and CPU use, because it really doesn't matter than much if there's a CPU hit slightly more on some plug in like Hive that has low CPU use in the first place. I did not choose them expecting wildly different results depending on the DAW and computer, but they obviously are using different things in different DAWs and different Chips.

One thing is clear, Ableton aren't doing anything, and are severely underperforming on multicore setups compared. Squeezing by on i7 chips, but badly suffering on Xeons. The Reaktor on Xeon tests are really pretty sad, no wonder I haven't enjoyed using it for a while now!

[Taika-Kim]

I got over 120 instances with a 4 core i7 6700 playing an 8th note pattern with the "init" patch. Try changing sandboxing to "individually" in BW settings.

[machinesworking]

I got over 120 instances with a 4 core i7 6700 playing an 8th note pattern with the "init" patch. Try changing sandboxing to "individually" in BW settings.

The sandboxing settings barely change a thing here, an instance or two maybe. The point wasn't to compare computer speeds, we'd need a standardized test for that, same MIDI file etc. but to compare the way plug ins are used per core.

Bitwig as mentioned earlier uses more resources than some other DAWs because it tries to allow for real time manipulation of the the DAW while the sequencer is running etc. but it's pretty consistent, you can for the most part see a consistent increase in instances from 4 core laptop to 12 core desktop, and the Geekbench scores are roughly identical.

[Echoes in the Attic]

I got over 120 instances with a 4 core i7 6700 playing an 8th note pattern with the "init" patch. Try changing sandboxing to "individually" in BW settings.

The sandboxing settings barely change a thing here, an instance or two maybe. The point wasn't to compare computer speeds, we'd need a standardized test for that, same MIDI file etc. but to compare the way plug ins are used per core.

Bitwig as mentioned earlier uses more resources than some other DAWs because it tries to allow for real time manipulation of the the DAW while the sequencer is running etc. but it's pretty consistent, you can for the most part see a consistent increase in instances from 4 core laptop to 12 core desktop, and the Geekbench scores are roughly identical.

Interesting test but does it take into account some of the things mentioned earlier in this thread, such as the use of return tracks or groups having an impact on the benefits of multiple cores, due to having to calculate the signal flow differently? I think that's the problem with tests that simply multiply devices on separate tracks. In the real world there will be many of those tracks sending to effect tracks which apparently means that all processes in a given signal flow end up needing to be calculated on a single core.

Actually I think an old Ableton Live test may have dealt with this in a way. There were reverb on a bunch of sends with every track sending to the reverbs. Might be worth doing tests with some reasonably cpu heavy effects on a bunch of effect tracks (at least as many as there are cores, but not sure what would be most representative there, maybe whatever you feel would be a typical project, say 4-6 effect tracks).

[Echoes in the Attic]

This stuff I'm bringing up above makes me have a bunch more questions though, like if a given signal path from a normal track to an effect tracks requires those calculations to be on a single track, then how does using send effects save cpu over using the same one on the individual tracks that would have been sent to the send. It's always been said that using sends should reduce cpu consumption, so not I'm wondering why. Also, if there are two tracks sending to a single return track effect, do those two tracks get processed on different cores and additionally each core also processes the effect on the return track? So effectively the return track gets calculated twice (once on each core)?

[machinesworking]

This stuff I'm bringing up above makes me have a bunch more questions though, like if a given signal path from a normal track to an effect tracks requires those calculations to be on a single track, then how does using send effects save cpu over using the same one on the individual tracks that would have been sent to the send. It's always been said that using sends should reduce cpu consumption, so not I'm wondering why. Also, if there are two tracks sending to a single return track effect, do those two tracks get processed on different cores and additionally each core also processes the effect on the return track? So effectively the return track gets calculated twice (once on each core)?

I think, (and I flatly admit I do not know 100% for sure, I'm just going off information given by MOTU about their CPU saving techniques), you might be mixing up CPU saving resources. With most DAW, and I believe even with Bitwig and Live, you have a separate buffer for tracks that have no real time activity. This separate buffer doesn't work with tracks that have Sends. So there's this odd shift from Sends being the most efficient way to save CPU to being only OK at it.
So with DP10 there's an Effects Performance meter, Reaper has a similar (although I think more 'generous' to plug ins, i.e. less accurate) meter. This lets you see the CPU effect of plug ins run in Aux, record enabled, and master fader tracks. So tracks sent to an Aux or that have a send that feeds and Aux track use more CPU than they used to because everyone has figured out how to save CPU by pre rendering or buffering tracks that do not do this.

I do not think it's as big of a CPU hit in Bitwig or Live though, but that's because they both operate more or less in "real time" anyway. With Bitwig having a lot more power saving features than Live.

Worth testing out.

[sth]

This stuff I'm bringing up above makes me have a bunch more questions though, like if a given signal path from a normal track to an effect tracks requires those calculations to be on a single track, then how does using send effects save cpu over using the same one on the individual tracks that would have been sent to the send. It's always been said that using sends should reduce cpu consumption, so not I'm wondering why. Also, if there are two tracks sending to a single return track effect, do those two tracks get processed on different cores and additionally each core also processes the effect on the return track? So effectively the return track gets calculated twice (once on each core)?

It is CPU/RAM saving (or rather, not "wasting") in the sense that you only have instance that must be computed. On the Send, it's only computed that one time, although it must wait for all prior inputs to be calculated.

On each individual Track it's re-computed each time, but is not bound (assuming nothing else in the signal chain is) by that prior-work restriction.

It also serves a different, human-cost-saving, don't-repeat-yourself purpose. Why adjust 1 parameter X times when you really intended that 1 parameter to affect X things?

[Taika-Kim]

That's true about real world situations being complicated. I remember once there was a situation where adding on Dynamics device with sidechain made the DPS meter jump 20% or so. At the time I wondered about that, but it makes perfect sense now when I think of how the parallelism works. Great explanation on that earlier in the thread btw!

[Tj Shredder]

This is an interesting topic on the one hand, on the other hand it isn't something a musician/producer should deal with ever. It must not influence your workflow. If there is a performance problem report it to the devs.
In general a DAW with separate tracks is easy to calculate in parallel. Its getting more complicated if you put in audio receivers or use fx tracks. As Bitwig can have separate processes for plugins, they could as well run on their own cores.
The optimisation problem the devs have to deal with (partially the devs of the operating system) is how to avoid overhead which is always needed to transfer values from one thread to another.
Life is simpler if you simply forbid feedback, which is the case in Bitwig. All the workarounds to allow this anyway will introduce some latency which mostly isn't a problem.
The only point to influence performance is how to distribute the load to the cores, its a bit of a multiple travelling salesman problem. You have four salesmen, which have to deliver to 100 places in very varying distances. How can they deliver within a given time. If they deliver slower than new orders come in you get crackles...

[Lutein79]

My 24 Thread AMD CPU results:

More CPU Cores = More Tracks with more Plugins.
tested (20x Arturia Pigments per track equal smooth play)

One Track with Instrument Layer is One Audio Signal Way which limited to One CPU Thread.
tested (4x Arturia Pigments in Instrument Layer and hear Jitters)