Does CPU play a role in the DAW you use?

[AdvancedFollower]

The difference isn't that big nowadays. No DAW can take a single-threaded plugin and magically spread it out over multiple cores, so you're always going to get CPU intensive plugin instances hogging up most of a single core. It has more to do with how you structure the project, how much audio processing happens in serial etc. In general though, provided you have a decent CPU from the last 5 years (4+ GHz, 6+ cores), CPU shouldn't be an issue unless you're working on massive projects.

[Kinh]

Wha-tha-hell are you people talkin' bout?

[machinesworking]

I don't think there's much of a difference in CPU use between the different DAW's.

There can be huge differences.

There are pretty much two tiers or three if you're getting precise. Ableton, MPC, Bitwig etc. all use between 20-40% more CPU resources than Logic, DP, Reaper etc. Basically Live etc. do not have a separate buffer for unarmed tracks, thus record enabling the track barely has any effect. You get less interruptions in the looped audio this way, but it costs CPU that they don't implement modern CPU saving features.

[machinesworking]

So with all that in mind, yeah CPU plays a role. If I'm doing large projects I use Digital Performer, 20 or so tracks and I'll probably use Live.

[Scrubbing Monkeys]

Absolutely cpu hit plays a role. Not only for smooth operation, but when you have limited power weather battery or solar it can make or break your ability to get something done. Dimming screen, efficient DAW, ssd drives, low cpu vsts among other tweaks can be the difference in working for 5 min or 3 hrs.

[TheFrozenSea]

Yeah, made the switch from Cubase to Reaper solely based on CPU performance. Cubase would crash during writing sessions (a few VST:s and low buffer, can't freeze or render since I'm writing so constantly making changes). Reaper handles this so far without issues. I'm sure they could both handle mixing, but it's not worth it to switch half-way through a project.

[Freaqpeak]

Working on a song with 100+ tracks with alot of vst fx on all channels + 10 modern vstis (Hive, repro, zebrahz, Diva).. using about 50% of Ryzen 3950x CPU (16 cores) which is 2-3 years old now. In Cubase.. No lag. Im sure it would take less in Reaper but there is no problem, so... no, I wont switch daw. My Bitwig projects has less tracks so cant really compare those two.

[vurt]

nope. no cups in my music room at all! not even anagrams.

[pixel85]

But does CCCPU plays role in the DAW? That's the question!

[vurt]

probably

[antic604]

...they don't implement modern CPU saving features.

That's a pretty biased way to frame it.

Bitwig (or Live) could implement double-buffering, but it goes agains the core principle of how they're expected to work - at any time during playback they need to be able to swap a preset, a device, to switch between arrangement and clip launcher, to switch between instruments or audio/MIDI effect chains, to launch clips not in predefined order, to use audio-rate modulation, incl. random and generative one, to build complex real-time interactions between MIDI, audio and automation on many tracks, to work seamlessly with CV hardware, etc...

I can understand that for someone who doesn't care about any of the above Bitwig and Ableton "failed" by not implementing double buffer.

But for those that do care it's a worthy tradeoff and actually something that makes it hard to go back to "traditional" DAWs with their rigidness and constraints.

A different - better, IMO - way of framing it would be that the CPU cycles are dedicated to different type of production complexity: not in the sheer number of tracks and plugins, but rather in ability to create interconnected, evolving and dynamic sounds and arrangements. By now it should be pretty clear that if one doesn't care about that aspect of music, they should probably look at other DAWs. Or work in two+ DAWs using their respective strengths without expecting a single one to cover everything.

[machinesworking]

...they don't implement modern CPU saving features.

That's a pretty biased way to frame it.

Bitwig (or Live) could implement double-buffering, but it goes agains the core principle of how they're expected to work - at any time during playback they need to be able to swap a preset, a device, to switch between arrangement and clip launcher, to switch between instruments or audio/MIDI effect chains, to launch clips not in predefined order, to use audio-rate modulation, incl. random and generative one, to build complex real-time interactions between MIDI, audio and automation on many tracks, to work seamlessly with CV hardware, etc...

I can understand that for someone who doesn't care about any of the above Bitwig and Ableton "failed" by not implementing double buffer.

But for those that do care it's a worthy tradeoff and actually something that makes it hard to go back to "traditional" DAWs with their rigidness and constraints.

A different - better, IMO - way of framing it would be that the CPU cycles are dedicated to different type of production complexity: not in the sheer number of tracks and plugins, but rather in ability to create interconnected, evolving and dynamic sounds and arrangements. By now it should be pretty clear that if one doesn't care about that aspect of music, they should probably look at other DAWs. Or work in two+ DAWs using their respective strengths without expecting a single one to cover everything.

I can agree with you, that was rash, to a degree, but that excuse is IMO now way past it's due date. I remember 12 years ago Urs Heckman mentioning that program change messages to quickly change patches wasn't going to work because it would glitch. You can now do that with U-He synths.

I think you're exactly right this is why they chose to worry more about keeping the audio free of glitches while editing or tweaking the interface, adding plug ins, setting up modulators while a loop is running etc. I think they also coded that all in ten years ago, and it's possible that Reaper or DP etc. gets this type of functionality solidly enough to say that those DAWs will be fully comparable to the "uninterrupted audio engine" of Bitwig and Live with the same 20-45% lower CPU overhead. < I own current copies of both Bitwig and Live, I say it with true love, they're amazing, but I think the excuse of it being due to them being performance DAWs is running thin. I have hope it's possible to not skip any of the features they have and provide some CPU relief.

[antic604]

...I own current copies of both Bitwig and Live, I say it with true love, they're amazing, but I think the excuse of it being due to them being performance DAWs is running thin. I have hope it's possible to not skip any of the features they have and provide some CPU relief.

I don't know about Live, but it sure appears that Bitwig leverages any known trick in the book to ensure that it uses the CPU optimally, to the point of using different math libraries depending on the CPU you have and compiling devices on-the-fly to achieve that. It also tries to parallelize the jobs as much as possible, taking any opportunity wherever the branches appear - polyphony, voice stacking, layers, selectors, splitters, etc. Would I want them to employ some feature that would intelligently detect tracks that aren't linked with other tracks, don't have any clips in clip launcher and no random/generative modulation; and then double-buffer them? Sure! But I'm not convinced the extra dev effort is worth it and it would be hella confusing if adding an Audio Receiver would suddenly double your CPU load

With regards to "uninterrupted audio engine" - last time I checked current versions of Cubase or Reaper (few months back) they both sucked at it: moving notes within the clip, moving the clip itself, messing with the FX chain, etc. caused the playback to fall apart completely with things not getting triggerd or falling out of time until they catch up. It's probably not as noticeable when working with audio, but I'm 90-95% MIDI so I notice it a lot.

Obviously that won't bother many people and frankly shouldn't even bother me because I'm not performing live where that would be crucial. But - as I said earlier - once you get used to this seamless workflow and it's helping your music, then it's difficult to go back. Because it's not even about the "uninterruped audio engine" for me, but rather the fact that it encourages me to be more bold with sound design - on one track in Bitwig I can have a simple MIDI clip, with some notes that have random properties (likelihood of them being triggered, random velocity, random gate length), followed by a bank of MIDI FX chains, couple of instruments in Instrument Selector and array of FX Chains in FX Selector. This lets me to quickly mix & match the above components to find something I like, or let Bitwig do the work for me by either automating the toggling, sequencing them with LFOs or step sequencers or even let them happen randomly.

It's that kind of freedom and ease of tapping into it that's worth TO ME the 20-40% CPU tax compared to Reaper, Cubase or DP, where I wouldn't even know where to begin with such a setup.

But then I also realize many (most?) people wouldn't even care about creating such setups - they have a fixed idea they want to record with as little friction as possible.

I said it multiple times, to dissatisfaction of many - Bitwig isn't for everyone. And it's not because I think people are too stupid for it or "not worthy", but because to get the most of it you need to go all-in with its workflow and feature-set, because otherwise you'll always feel you're compromising on e.g. better MIDI editor, better mixing features, lower CPU, etc. Only when most of what you do while producing is more difficult or even impossible in other DAWs, then it starts to break even

[machinesworking]

Would I want them to employ some feature that would intelligently detect tracks that aren't linked with other tracks, don't have any clips in clip launcher and no random/generative modulation; and then double-buffer them? Sure! But I'm not convinced the extra dev effort is worth it and it would be hella confusing if adding an Audio Receiver would suddenly double your CPU load

That's my point though, I'm seeing things done in Reaper and DP specifically that mimic the experience of Live and Bitwig, but I don't see the opposite. Reaper has buffering on it's containers not unlike Bit/live and DP added in a "Live Performance Mode", which gets rid of a good amount of glitching while doing all the things that Bit/Liv can do naturally. They're moving towards that, and with modern CPUs that's not as hard to do as it used to be. Conversely as you allude to, adding in buffering that doesn't mess with live performance aspects is a possibly trickier dance. Let's hope they don't get caught with their pants down like NI, that's all.

[antic604]

...Let's hope they don't get caught with their pants down like NI, that's all.

I really don't think people choose their DAW based on CPU utilization metrics, but rather on features and workflow. So I'd rather they worked on that.

And actually this thread proves it