Does CPU play a role in the DAW you use?

[machinesworking]

...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

Sure, but they change from one DAW to the next because of CPU. This is a common reason people have switched from Live to XYZ DAW, or added a second DAW. There are certain plug ins that will kill everything but the latest computers in Live, this has been true since Live came out.

Back to the original statement, they don't implement modern CPU saving features, that's not a false statement. Whether it's somehow harsh to you because they choose not to, and somehow the term "modern" is loaded compared to "certain" is up to your interpretation of what modern means. If you've chosen to think that modern means "good" or "better" in every case, then your reaction to become the defender of the faith™ and explain to me the reasons why you think it's unimportant that they typically use 20-45% more CPU than other DAWs makes sense.

I mean it's not like we haven't discussed this before, but if we're to discuss all the reasons why Live and Bitwig are great to work in, we most certainly need to discuss the areas where they aren't so great. I don't think either is that great at large template projects, I wouldn't want to attempt to set up either with an entire orchestras worth of tracks plus a couple dozens for streamers etc. There's finally a M4L device for SysEx dumps to Clips etc. So you can store your sound from a hardware synth in Live now, which is great, nothing like that for Bitwig. Neither of them have complex quantization etc.

[antic604]

Back to the original statement, they don't implement modern CPU saving features, that's not a false statement. Whether it's somehow harsh to you because they choose not to, and somehow the term "modern" is loaded compared to "certain" is up to your interpretation of what modern means. If you've chosen to think that modern means "good" or "better" in every case, then your reaction to become the defender of the faith™ and explain to me the reasons why you think it's unimportant that they typically use 20-45% more CPU than other DAWs makes sense.

Right, "modern" doesn't always mean better. But in this particular case you seem to imply that this is the case - by refusing to use double-buffered audio engine they're not taking advantage of the latest & greatest tech available.

But I'm saying that Bitwig - and Live, to a lesser extent - chose the implement modern optimal CPU utilisation techniques tailored for particular workflows and user cases, where music complexity is achieved not by sheer force of number of tracks & plugins, but rather by complexity of instrument/effect chains and modular interconectedness between generative / random components of the project.

I'm not following gaming tech like I used to, but I remember there was something similar happening at least with consoles - they'd use double- or even tripple-buffered graphic pipelines to be able to render better ("more") graphics, but that was at the expense of controller latency and if they missed the CPU budget, they'd no go from 30fps to 28fps, but straight to 20 or 10. Whereas competitive games - like shooters - were usually single-buffered and as a result they could tear like crazy, but were much more responsive and fps fluctuated more smoothly.

So by analogy you could say that the former games used newer tech, but a) there was a lot of users who preferred responsive and fluid games to beautiful games, b) the graphic engines of the latter games weren't less advanced or outdated - they were putting effort in other areas.

So yes - I will defend the notion that sacrificing 20-40% CPU performance in Bitwig compared to Reaper or Cubase was worth it, simply because I can't do the music the way I want to in Reaper or Cubase, but I can in Bitwig. And I refuse to believe it's only because Bitwig devs are somehow less competent or less talented. No. They simply chose different objective(s) to optimise for.

[jancivil]

CPU is not the whole story, real-time performance of the system is more than that. You could have the best machine in terms of specs there is and suffer with poor performance and tons of latency. I cannot overemphasize the importance of the audio IF's drivers here. And that peripherals may be major bottlenecks.

[mystran]

I'm not following gaming tech like I used to, but I remember there was something similar happening at least with consoles - they'd use double- or even tripple-buffered graphic pipelines to be able to render better ("more") graphics, but that was at the expense of controller latency and if they missed the CPU budget, they'd no go from 30fps to 28fps, but straight to 20 or 10. Whereas competitive games - like shooters - were usually single-buffered and as a result they could tear like crazy, but were much more responsive and fps fluctuated more smoothly.

Pretty much every game is actually double buffered and what you describe is just a matter of whether or not the presentation of new frames is synchronized to the screen refresh or not. While consoles typically enforce the sync, many (most?) PC games have always had an option to enable or disable it depending on what you prefer (and in terms of programming it's literally just a simple flag you need to set), but most in most competitive shooters it just ends up being preferable to accept a bit of tearing (ie. different parts of the screen showing different frames) in exchange for an overall smoother experience and (slightly) reduced latency.

Unfortunately, with audio you can't really "cheat" like this.. either you hit the deadline for the next buffer or you glitch.

[antic604]

Unfortunately, with audio you can't really "cheat" like this.. either you hit the deadline for the next buffer or you glitch.

That wasn't the point of my analogy

The point was you cannot say one (game/audio) engine is more "modern" than the other only because it prioritizes the things you care for and the other does not.

[mystran]

The point was you cannot say one (game/audio) engine is more "modern" than the other only because it prioritizes the things you care for and the other does not.

Fair enough... (although in case of games, the "modern" solution would be a monitor with variable refresh rate, which actually do exist; unfortunately a similar solution for audio is not really possible).

[machinesworking]

Right, "modern" doesn't always mean better. But in this particular case you seem to imply that this is the case - by refusing to use double-buffered audio engine they're not taking advantage of the latest & greatest tech available.

You're reading a lot into what I wrote here, they chose these methods 10 and 20 years ago roughly. At that time I believe they were right in that it was the best option.

But I'm saying that Bitwig - and Live, to a lesser extent - chose the implement modern optimal CPU utilisation techniques tailored for particular workflows and user cases, where music complexity is achieved not by sheer force of number of tracks & plugins, but rather by complexity of instrument/effect chains and modular interconectedness between generative / random components of the project.

Again this tech is now 10-20 years old. The goal posts are moving.

So yes - I will defend the notion that sacrificing 20-40% CPU performance in Bitwig compared to Reaper or Cubase was worth it, simply because I can't do the music the way I want to in Reaper or Cubase, but I can in Bitwig. And I refuse to believe it's only because Bitwig devs are somehow less competent or less talented. No. They simply chose different objective(s) to optimise for.

Again, this is old tech at this point. I'm not even saying this is entirely possible for them, but IMO it can't be near impossible. The thing about buffering unused parameters whether it's a cut off on a synth, volume, note, etc., that being a high cost in terms of glitching and bogging the system down, that's starting to go away.
None of that says that it's not a trade off, Ableton and Bitwig might believe any possible issue isn't worth the CPU savings, but to not acknowledge that things are a lot different than they were 20-10 years ago is... I dunno man, you're just doing the fanboy thing and not wanting to admit the advantage of what you've set up as competing products to your football team.

We will see, but if Bit/Liv get stuck with only a workflow to differentiate them from the pack, then it's going to be simply a matter of whether you think too many features is a bad thing or not. <- There will always be reasons to choose a DAW, but you're dying on a hill here IMO. We all know there are reasons they chose that path, but you seem to be incapable of harboring the thought that it's possible that path will be next to meaningless soon.

[pdxindy]

We will see, but if Bit/Liv get stuck with only a workflow to differentiate them from the pack, then it's going to be simply a matter of whether you think too many features is a bad thing or not. <- There will always be reasons to choose a DAW, but you're dying on a hill here IMO. We all know there are reasons they chose that path, but you seem to be incapable of harboring the thought that it's possible that path will be next to meaningless soon.

For me it is the other way that it has become meaningless. I recently put in 120 tracks of Dune 3.5 each playing 4 notes simultaneously. I did like 60 tracks of RePro. This is in Bitwig with my new M1-Pro MBP. Another DAW being more CPU efficient is of no real importance to me at this point cause Bitwig with my new machine is fast and efficient enough to fulfill my needs.

In the opposite way, it will not be soon that a DAW like Cubase has Bitwig's modulation system, Bitwig's Grid, etc., etc. That is a lot more than workflow differentiating Bitwig.

[BONES]

Whatever DAW's you've tried, does how well it performs on your computer play a role in you using it? Or do you just sacrifice workarounds to work with it (etc less 3rd party plugins for stock etc)?

It is not something I have ever even thought about. CPU usage definitely influences my choice of plugins but it never occurred to me that one DAW might be more efficient than another.

[machinesworking]

We will see, but if Bit/Liv get stuck with only a workflow to differentiate them from the pack, then it's going to be simply a matter of whether you think too many features is a bad thing or not. <- There will always be reasons to choose a DAW, but you're dying on a hill here IMO. We all know there are reasons they chose that path, but you seem to be incapable of harboring the thought that it's possible that path will be next to meaningless soon.

For me it is the other way that it has become meaningless. I recently put in 120 tracks of Dune 3.5 each playing 4 notes simultaneously. I did like 60 tracks of RePro. This is in Bitwig with my new M1-Pro MBP. Another DAW being more CPU efficient is of no real importance to me at this point cause Bitwig with my new machine is fast and efficient enough to fulfill my needs.

In the opposite way, it will not be soon that a DAW like Cubase has Bitwig's modulation system, Bitwig's Grid, etc., etc. That is a lot more than workflow differentiating Bitwig.

For sure workflow and a $3K laptop will change the game! Like everything with plugins though, anytime a new advance in chips comes out someone finds a way to max it out.

This is all so use case specific though. The question is "Does CPU play a role in the DAW you use?" that matters for sure if you're doing orchestral work, film scores etc. and most people doing that aren't going to choose DAWs that eat CPU, that don't have built in video support, for that task.

Now doing a 12-32 track electronic piece with heavy plug ins? Yeah that's a lot more fun in Live or Bitwig, but people use Logic, Cubase, DP etc. for a reason.

[pixel85]

Comparing DAW with games doesn't make any sense. Two completely different universes. There's like absolutely nothing in common.

Ps. in game engines / games, audio has the lowest priority in the pipeline and has plenty of latency. Performance in games is executed in totally different ways that performance in DAWs. Real-time audio performance doesn't exist in games. It's executed in the cheapest way for the CPU to leave space for graphics and code execution. Not to mention that games use, at best, very basic DSP with cheap sounding effects (besides IR for reverbs but this is w piece of cake for CPUs these days).

So what are those modern CPU instructions that DAWs could, but they don't use? Can somebody list them + list of DAWs that are not/using them?

[machinesworking]

So what are those modern CPU instructions that DAWs could, but they don't use? Can somebody list them + list of DAWs that are not/using them?

Antic was sort of right, modern isn't really the right term. Twenty years ago Ableton decided to not use any sort of buffer on unarmed tracks to make sure audio had no issues (cracks, dropouts etc.) when doing things like instantiating a VST while a loop is playing, even editing audio pitch and stretch etc. Bitwig also does this. Both have a roughly 35% CPU hit on average if you run tests on them for track count. This is because DAWs like Cubase, Reaper, DP, Studio One, Logic etc. use a secondary buffer on unarmed tracks, thus saving CPU. You can kill this CPU efficiency in any of these DAWs by record arming all the tracks, at that point it will generally behave worse than Bit/Live.

The whole debate comes from my assertion that this way of saving the integrity of the audio stream, no dropouts etc. is coming to an end at some point, the other DAWs are getting better at not dropping audio when you mess around in them while they're playing, DP even went as far as to add a "Live Performance Mode", it's not perfect but it vastly improves DP's real time experience, and I doubt they will remain the only DAW to do this.

[antic604]

...they chose these methods 10 and 20 years ago roughly.

...Again this tech is now 10-20 years old.

So why call it "modern"?

...I dunno man, you're just doing the fanboy thing and not wanting to admit the advantage of what you've set up as competing products to your football team.

I'm not, at least I don't believe I do. I'm not saying Bitwig's or Live's approach is objectively better. I'm saying it's better for the type of workflow they - especially Bitwig - excel at. If that's not the workflow you care for, you should use a DAW that's more optimal for your workflow. For me it's worth to "sacrifice" those 20-40% of CPU for features I couldn't write music without

Sorry if I'm not being clear.

I'm not saying Range Rover is the best car in the world, but it's definitely much better than Ferrari if you're stuck in the middle of the woods.

[antic604]

We will see, but if Bit/Liv get stuck with only a workflow to differentiate them from the pack, then it's going to be simply a matter of whether you think too many features is a bad thing or not.

I thought workflow is the most important thing?

There will always be reasons to choose a DAW, but you're dying on a hill here IMO. We all know there are reasons they chose that path, but you seem to be incapable of harboring the thought that it's possible that path will be next to meaningless soon.

No. I don't think I will ever be able to create the type of device chains in Reaper, Studio One or Cubase that I can in Bitwig. Or to audio-rate modulate a pad on one track with a lead on the other. Or instantly - even randomly - go between different chains of effects or instruments. Or switch between clip launcher and arranger on a whim, to completely change the flow of the track.

Those things go against the core assumption of double-buffered audio engines, i.e. that you can pre-render ahead some (or most) of tracks, because they're set in stone. Although - as you suggested - it's probably easier for Cubase to disable ASIO Guard than for Bitwig to add it.

And for the last time - that's fine. I'm aware probably most people don't care about what Bitwig can do that other DAWs can and definitely the target audience won't know the difference; but for the producers themselves it might be important, or even crucial. Both approaches are viable and appropriate for the workflow they're optimised for. Neither of them is more "modern" or "better". Just different.

[antic604]

Comparing DAW with games doesn't make any sense. Two completely different universes. There's like absolutely nothing in common.

I wasn't "comparing" them, just offering an analoguous - to my mind at least - situation that someone else might be more familiar with, as I'm obviously struggling to explain what I mean