Does CPU play a role in the DAW you use?

[pixel85]

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

I don't know anymore who is talking about what in this topic Total mix of conventions, terms and ideas like at the very late evening at a pub

[pdxindy]

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.

Of course... I don't think anyone said otherwise or claimed there was one right answer.

The question is "Does CPU play a role in the DAW you use?" For me the answer today is not so much. For someone else it may be a yes.

Oh, and my impression is that Bitwig or Live will not be significantly less efficient if you bump the buffer up high like some DAW's do automatically for un-armed tracks. Lots of people program parts, not play them and in that case armed tracks don't need a low buffer for realtime play.

It may be other features that attract people to the classic linear DAW's more than the CPU use.

[antic604]

I don't know anymore who is talking about what in this topic Total mix of conventions, terms and ideas like at the very late evening at a pub

Well, we're doing our best to turn around a nonsensical question into a coherent discussion. With moderate success, at best

[mystran]

Oh, and my impression is that Bitwig or Live will not be significantly less efficient if you bump the buffer up high like some DAW's do automatically for un-armed tracks. Lots of people program parts, not play them and in that case armed tracks don't need a low buffer for realtime play.

The main advantage of "render ahead" is that it allows you to spend less time waiting as you can put some useful work on any free CPU cores even before the next buffer period has technically started. While it doesn't reduce the total amount of processing it needs to be done, it reduces the amount of waste.

Increasing the blocksize does have some efficiency benefits and is less sensitive to CPU load variation, but it'll still suffer from the same waiting problem, just less often. Another strategy that might work better would be to keep the buffersize, but add some additional buffering. This will have a latency hit similar to a longer buffer, but it means that now you can have multiple blocks "in flight" concurrently, which could give you a similar utilization benefit to render-ahead schemes. Not sure if Live can do this, but it does (or at least used to) have an option for extra buffers.

[antic604]

The main advantage of "render ahead"...

...Another strategy that might work better would be to keep the buffersize, but add some additional buffering...

Hmm. I always thought those 2 were the same, but now that you've written it like that I start to think they aren't, i.e. the difference is nuanced but important: "render ahead" would use free CPU cycles to render as much as possible ahead, whereas "additional buffer" approach would always rended only up to specified, secondary buffer length even if there were CPU cycles to spare.

Am I getting it right?

And if that's the case, is Cubase the "render ahead" type while Studio One is "additional buffer" type?

I think I have a "science project" for the weekend cut out for me!

[machinesworking]

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

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

So why call it "modern"?

Because I wasn't referring to what Live and Bitwig do, but to what other DAWs have done since to improve tracks counts. DP calls it NextGen PreGen the others have similar silly names, but it's essentially a buffer filled with the first milliseconds of all the MIDI and adio data in your song. It didn't really exist in 2000 when Live came out.

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

I'm pretty sure you could write music with a few glitches to the audio while you wrote. I love Bitwig too, but show me a song that can't be done in another DAW. Bitwig hasn't fundamentally changed the nature of music or even added in any new element, it's just really well thought out for people who need to modulate the modulator of an FM knob on the fly. Something that would take maybe rendering to audio to do in another DAW.

[machinesworking]

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.

Eh? Logic and DP both have clip launchers now. You pretty much named the only major DAWs that don't besides Pro Tools. So no Clips don't stop working in DAWs with some sort of buffering to save CPU.

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.

Sure, but the big difference, device chains, is IMO not one that requires an "uninterrupted audio engine", that's not a prerequisite for tweaking an effect or synth.

[machinesworking]

The main advantage of "render ahead"...

...Another strategy that might work better would be to keep the buffersize, but add some additional buffering...

Hmm. I always thought those 2 were the same, but now that you've written it like that I start to think they aren't, i.e. the difference is nuanced but important: "render ahead" would use free CPU cycles to render as much as possible ahead, whereas "additional buffer" approach would always rended only up to specified, secondary buffer length even if there were CPU cycles to spare.

Am I getting it right?

And if that's the case, is Cubase the "render ahead" type while Studio One is "additional buffer" type?

I think I have a "science project" for the weekend cut out for me!

It's not likely you can get a solid answer on this, and results aren't proof in cases like this, i.e. your assumption that "additional buffer' is better or worse that "render ahead" isn't based on any actual knowledge of what that DAW is doing. It's kind of an impossible task. All you can really prove is the time it takes for the tracks to play after hitting Play on the DAW.

My ill informed assumption is that most DAWs do a combination of both, buffering a little for prerendering a track, and buffering the start time of the sequence a bit to add a prebuffer to the entire song. The problem with trying to figure out which is which is that both of them add CPU to armed tracks, and what mechanical device are you going to use to measure that likely 20-200 millisecond delay? most devices aren't going to be that accurate enough to get that little delay.

Back to the original chat, DP11 recently introduced a "Live Performance Mode", shutting down what I would assume would be buffers that glitch the audio etc. It's not perfect, first thing I did when they introduced it was attempt to break it, and it's not nearly as bullet proof as Live and especially Bitwig, but it's there. So, if they can do it to a degree, then Bit/Liv can do the opposite.

Yes, they don't need to, no it's not unfair to point out that there's been little to no improvements in this way from either DAW.

[antic604]

It's not likely you can get a solid answer on this, and results aren't proof in cases like this, i.e. your assumption that "additional buffer' is better or worse that "render ahead" isn't based on any actual knowledge of what that DAW is doing.

Why you're trying to grade everything? Nowhere did I wrote that I think one is better than the other, or that I'm even trying to establish that. I'm just trying to learn and understand. Out of curiosity. As it says in my sig - I'm music tech enthusiast. Not music tech warrior.

[machinesworking]

It's not likely you can get a solid answer on this, and results aren't proof in cases like this, i.e. your assumption that "additional buffer' is better or worse that "render ahead" isn't based on any actual knowledge of what that DAW is doing.

Why you're trying to grade everything? Nowhere did I wrote that I think one is better than the other, or that I'm even trying to establish that. I'm just trying to learn and understand. Out of curiosity. As it says in my sig - I'm music tech enthusiast. Not music tech warrior.

I'm not exactly sure how you got that assumption from quoted text? My point was just about the possibility of being able to gather any data at all that pointed towards which buffering method was used by a DAW. I don't think you really can reverse engineer it, we're not talking about more than a tenth of a second here for the most part.

[mystran]

It's not likely you can get a solid answer on this, and results aren't proof in cases like this, i.e. your assumption that "additional buffer' is better or worse that "render ahead" isn't based on any actual knowledge of what that DAW is doing.

Why you're trying to grade everything? Nowhere did I wrote that I think one is better than the other, or that I'm even trying to establish that. I'm just trying to learn and understand. Out of curiosity. As it says in my sig - I'm music tech enthusiast. Not music tech warrior.

I'm not exactly sure how you got that assumption from quoted text? My point was just about the possibility of being able to gather any data at all that pointed towards which buffering method was used by a DAW. I don't think you really can reverse engineer it, we're not talking about more than a tenth of a second here for the most part.

You could probably do this by writing a special purpose plugin (eg. log timing, introduce artificial delays) or even a special purpose driver to complement it, but .. like why would you bother?

[rod_zero]

Kind of, i actually have stopped using some.plugins in favor of the daw native ones, I use Live, cause they are much more friendly with the CPU.

When I have tried other DAW I always like to go through their native effects and see how easy and CPU efficient are, i liked Studio One for example.