PreSonus Studio One 7 apparently imminent

[jens]

Cockos only started calling it "anticipative FX processing" with V2 in 2007. Before that, they called it "render ahead", and it already was there (and enabled by default) in 2006 at the very least, so yes, Reaper indeed had it even before Samplitude.

https://forum.cockos.com/showthread.php ... nder+ahead

[neverbeeninariot]

That just left CPU performance and the fact that Reaper (nor any other DAW afaik) can do S1's trick of having two different audio buffer sizes: one for playback and one for recording.

Wait - what???

Dude! Reaper had that for so much longer than S1 - in fact iIrc Reaqper was the first DAW to have that and especially those being familiar with it were the ones pestering the S1 dev team long enough (for years) requesting it in S1 until they finally gave in and added it.

Reaper does not have multiple buffer sizes (unlike Steiny's ASIOGuard or whatever S1 has, or Tracktion Waveform, etc.). It has AnticipativeFX, which pre-renders n blocks of audio ahead of time on non-armed tracks.

For an explanation straight from the llama's mouth (thankfully not his ass) - https://dawbench.libsyn.com/episode-02- ... ent-future approx ~00:57:15.

[jens]

That just left CPU performance and the fact that Reaper (nor any other DAW afaik) can do S1's trick of having two different audio buffer sizes: one for playback and one for recording.

Wait - what???

Dude! Reaper had that for so much longer than S1 - in fact iIrc Reaqper was the first DAW to have that and especially those being familiar with it were the ones pestering the S1 dev team long enough (for years) requesting it in S1 until they finally gave in and added it.

Reaper does not have multiple buffer sizes (unlike Steiny's ASIOGuard or whatever S1 has, or Tracktion Waveform, etc.). It has AnticipativeFX, which pre-renders n blocks of audio ahead of time on non-armed tracks.

For an explanation straight from the llama's mouth (thankfully not his ass) - https://dawbench.libsyn.com/episode-02- ... ent-future approx ~00:57:15.

Pre-buffering is exactly what it is in all these cases (ie. it pre-processes the tracks/plugins into a buffer - the bigger the buffer the longer the pre-processed timeframe and the longer the timeframe (which is what you set in Reaper) the higher the buffer. Regardless of whether you call it "rendering" or "processing" it's the same thing))
- and unless the DAW comes with a built-in time-machine, there isn't any other way either.

Tracktion unfortunately doesn't have hybrid buffering by the way.

[Uncle E]

That just left CPU performance and the fact that Reaper (nor any other DAW afaik) can do S1's trick of having two different audio buffer sizes: one for playback and one for recording.

Wait - what???


Dude! Reaper had that for so much longer than S1

See, this is why no one likes Reaper users.

He did say "afaik", after all.

[dastewart]

Thanks for the replies. Let me separate out two things here for the sake of clarity. Firstly, there's raw CPU efficiency regardless of any trickery (dual buffers for S1, adaptive FX for Reaper). And secondly there's the trickery.

So, firstly, I am getting far better CPU efficiency from S1 than Reaper without any trickery, i.e. with S1 dropout protection off and my process and audio block sizes identical. That's not what I expected but it is what I'm finding and I can't ignore it. Given what The Intrancer said in their post maybe this isn't such a surprise to others.

And that's probably the end of it for me because I'm not going to move to a DAW which is harder on my CPU (personal choice). What follows is really just curiosity.....

In terms of the dual buffer then I'm happy to be corrected. I've never use "Cubendo" and I'm new to Reaper. But I've got my anticipative FX buffer set to 200ms (the default) so if that's what you're talking about then it isn't helping. I don't know how the guts of these DAWs work and it doesn't really matter because the result is that whatever S1 is doing seems far more effective than Reaper.

However, just to make sure I'm comparing apples to apples, if I have S1 set to 64 samples audio buffer and 512 process buffer (which are my typical settings) what is the equivalent for Reaper to achieve the same thing?

As a final comment, I started this with the intention/hope of moving away from S1 so I want Reaper to be better or as good from a CPU perspective. I'm not fighting a cause here, I'm genuinely trying to understand if my findings are flawed in some way.

[jens]

That just left CPU performance and the fact that Reaper (nor any other DAW afaik) can do S1's trick of having two different audio buffer sizes: one for playback and one for recording.

Wait - what???


Dude! Reaper had that for so much longer than S1

See, this is why no one likes Reaper users.

He did say "afaik", after all.

He also said it's a fact that Reaper doesn't have it.

I'm defending S1, Reason, Samplitude and Cubendo with the same vigour, so you're way off here (even though I generally speaking know what you mean and have been a victim of the Reaper fan-gang myself more than once already).

[jens]

So, firstly, I am getting far better CPU efficiency from S1 than Reaper without any trickery, i.e. with S1 dropout protection off and my process and audio block sizes identical. That's not what I expected but it is what I'm finding and I can't ignore it. Given what The Intrancer said in their post maybe this isn't such a surprise to others.

Common consenus is that Reaper typically is the most efficient DAW (and it is certainly also more effient that S1 on all machines I used both on), but common of course doesn't mean universal.

There of course might be one or the other system/audio-interface/settings/use-scenario combination where S1 outperforms Reaper. Every DAW might outperform any other DAW
on this or that system.

[Uncle E]

Imagine caring about DAW efficiency in 2024.

[neverbeeninariot]

Pre-buffering is exactly what it is in all these cases (ie. it pre-processes the tracks/plugins into a buffer - the bigger the buffer the longer the pre-processed timeframe and the longer the timeframe (which is what you set in Reaper) the higher the buffer. Regardless of whether you call it "rendering" or "processing" it's the same thing))
- and unless the DAW comes with a built-in time-machine, there isn't any other way either.

Tracktion unfortunately doesn't have hybrid buffering by the way.

I should have done my homework on Waveform, I thought that was a thing for them now.

Anyways, fair point on the pre-rendering. I was pretty sure that time-travel was not involved but this is now confirmed, thanks

[dastewart]

So, firstly, I am getting far better CPU efficiency from S1 than Reaper without any trickery, i.e. with S1 dropout protection off and my process and audio block sizes identical. That's not what I expected but it is what I'm finding and I can't ignore it. Given what The Intrancer said in their post maybe this isn't such a surprise to others.

Common consenus is that Reaper typically is the most efficient DAW .....<snip>

Yup, that's why I'm surprised by my results. But I'm still waiting for which settings I may have messed up in Reaper (mostly I'm on default) because if I haven't messed up then the consensus is wrong. At least for my PC which I'd say is fairly typical.

Just for info:
PC
Intel i9-12900K
ASUS ROG MAXIMUS Z690 HERO
32GB RAM
NVMe drives
Windows 11
Quantum 2626

[jens]

That's a nice system - I do notice however that you use a Presonus audio-interface - and I don't think it's a completely outlandish idea to think they might have concentrated mainly on their own DAW when developing the drivers for it.

[dastewart]

I guess that's possible but a bit annoying if true because when my 2626 dies I wasn't planning to replace it with a Presonus interface as they've removed the killer feature of their "old" interfaces (i.e. ultra low latency).

[jamcat]

Is it any surprise to anyone not in the Reaper cult that their claims aren’t true?

Why would anyone believe such outlandish propaganda that the Winamp guy is single-handedly doing what teams of the top audio developers across the industry supposedly can’t?

[LawrenceF]

Studio One's dual buffer system is easy enough to understand.

When Low Latency Monitoring is on, tracks not being monitored will play back through a larger buffer (up to 2048 samples on my device) putting much less stress on the CPU. Tracks being monitored go through the smaller buffer (64/128 samples) for lower throughput latency. It's not anticipating anything afaik, it's just using higher buffers only for tracks not being monitored to free up more CPU juice.

There's some other things going on like bypassing high latency plugins in the monitored track, but that's really all it is.

[jamcat]

These are the tracks with the green Z lit up, right?