PreSonus Studio One 7 apparently imminent

[jens]

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

Well, it's certainly a stellar interface and at least nowadays quite inexpensive - especially per mic-pre. And it's possible that they managed to do some in-house trickery so that S1 runs especially well with it, not the other DAWs worse as compared to other interfaces - plus, given that you probably run it with super-small buffers, it's possible that Reaper simply doesn't perform that well under these circumstances (I think 256 samples of latency are far more common than 8 or 16 - so you might have a completely different use-case scenario as compared to the average user).

[VOODOO U]

RME. Problem solved.

[LawrenceF]

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

On older versions I think it was, yeah. Now it just has a green z on the instrument rack for that, for instruments.

[Uncle E]

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?

You can't comprehend the level of genius required to create a media player.

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

Well, it's certainly a stellar interface and at least nowadays quite inexpensive - especially per mic-pre. And it's possible that they managed to do some in-house trickery so that S1 runs especially well with it, not the other DAWs worse as compared to other interfaces - plus, given that you probably run it with super-small buffers, it's possible that Reaper simply doesn't perform that well under these circumstances (I think 256 samples of latency are far more common than 8 or 16 - so you might have a completely different use-case scenario as compared to the average user).

I've had it a while now as I got sick and tired of waiting for the update to the original Quantum (which is what I really wanted). As it happens, pleased I didn't wait because (Fender/)Presonus killed the Quantum line of interfaces in everything but name.

My normal settings are 64 samples on the audio buffer and 512 on the processing buffer. That gives me 4.5ms of RTL if I record something and it can cope with pretty hefty projects without tripping over.

I genuinely wanted Reaper to match/better this kind of performance, and assumed it would which is why I bothered to spend time putting it through its paces.

[jens]

Well, to be fair Reaper has a whole lot of settings you can play around with - in typical Reaper fashion if you expect it to work out of the box your chances of being disappointed are considerable.

[jamcat]

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

On older versions I think it was, yeah. Now it just has a green z on the instrument rack for that, for instruments.

I've always been a bt confused by this, actually.
How do you set it up for audio/FX tracks? Is it automatic?

[BKSchatzki]

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.

This becomes pretty funny for sends on a track you're monitoring. And, it can get a little weird when you already have some routings set up that are sending your monitored track through some high-latency buses.

[dastewart]

I've done another trawl of available information before giving up with Reaper (at least for the moment). So I've watched a few youtube videos on Reaper settings, read through various threads on forums and also listened to a couple of Dawbench podcasts - one with Justin Frankel (the man behind Reaper) and one with the guy responsible for the Studio One engine back in v3 when they introduced the "dual" buffer system.

Unfortunately, this hasn't really shed any light on the performance variation except that these two DAWs (and each and every DAW) work very differently. They way they handle buffering and latency, the way they cope with multi-core CPUs, the way they operate with virtual instruments, the way they interact with drivers and CPU cache, the way they operate with different OS and hardware are all very different. So, while it may be interesting (for some) to fully understand why the differences occur ... the quickest way to find out what's going to happen in YOUR real world situation is just to download the demo(s) and try it out.

I'm as convinced as I can be now that there are no settings in Reaper that I've overlooked so, for whatever reason, I'm finding that S1 can cope with more than Reaper and that rules out Reaper for me as an alternative.

Just for the record, that is the opposite of what 99% of internet is telling me. There's a received wisdom that Reaper is the "most CPU efficient" DAW but I've struggled to find any definitive testing to demonstrate that this is actually true. A few people (like me) have done some side by side testing but a) none that I've seen show Reaper as being particularly more efficient than S1 and b) for the reasons above it is so session/hardware specific that you'd need to probably test on about 5 different configurations on 5 different projects with 5 different buffer settings to get any meaningful results.

So, the long and short of it is that if you're thinking of changing from S1 (and I guess many people are because of how Fender/Presonus are acting) and CPU efficiency is important to you then download a demo and fully test it out rather than relying on the internet for an answer. It's the only way to know for sure and it may surprise you.

[lfm]

And S1 was more CPU efficient than Reaper at all the buffer settings I tried except 1024. S1 used 29% less CPU used at 64, 11% less CPU at 256.

And the render mirrored the CPU usage (i.e. Reaper took longer).

And when I kept duplicating tracks until Reaper was maxing out the CPU and couldn't play it back without pops and clicks, S1 was still running it at 30% CPU.

I had such different results also
- same daw, Sonar, and project though
- and two different brand audio interfaces

I ran Presonus 18i24c, I think model was, and going down to 64 samples it was double cpu compared to RME Digiface USB.

Similar less difference when doing other buffers like 128 or 256.

I was troubleshooting Cubase 8 or so for an event that made audio engine dropout in middle of recording.
- 8 threads restarted so hiddeous amount of thread for audio engine

I never tested Reaper to the limit having issues, so am with the 99% saying Reaper is very resource efficient.
- but running video Reaper was always heavy and you felt it running video too
- both studio one and Sonar I don't even notice running video too.
- new video engine Cubase was awful and why I went studio one at the time

So certain software, hardware and drivers seems to work well better together it seems.

I recently upgraded Samp ProX2 to X8 and running video it reduced headroom of tracks with in the range 30 tracks with plugins or so.

So always nice with headroom of course.

That Reaper would be a cpu hog is a mystery to most of us, I think.
- but join the choir of it being awful gui and not pleasent to look at
- that is the biggest mystery that Justin did not fix that in 20 years development

Showstopper leaving Studio One was that all midi recording convert to automation and cannot be chosen not to like Sonar, Cubase and whatnot.
- realtime recording turning knobs on synths create issues
- first recorded value become start value of the recorded clip
- and no sysex support

Other than that I would look at StudioOne again.
- but really think policy with steep price tag entering the StudioOne eco system now
- it would be 85-90% discount campaigns to even get any new users, nothing in below $100 is big mistake.

One size does not fit all....

[LawrenceF]

I've always been a bt confused by this, actually.
How do you set it up for audio/FX tracks? Is it automatic?

Audio tracks work the same way for software monitoring. The Z is on the master bus. If your audio device supports direct hardware monitoring you can choose software or hardware direct monitoring. You can see below that my audio device doesn't support direct hardware monitoring so that option is disabled.

audio device.png

[jamcat]

Showstopper leaving Studio One was that all midi recording convert to automation and cannot be chosen not to like Sonar, Cubase and whatnot.

It sounds like what you need is part containers for automation data, and the ability to reassign automation data to any plugin/parameter. That has been my one and only request for the last couple years.

[kevvvvv]

Consensus here seems to point to SI's cpu efficiency.

Would using Bitwig be worse on my system? Any one here know?

[lfm]

Showstopper leaving Studio One was that all midi recording convert to automation and cannot be chosen not to like Sonar, Cubase and whatnot.

It sounds like what you need is part containers for automation data, and the ability to reassign automation data to any plugin/parameter. That has been my one and only request for the last couple years.

Thanks, maybe that is it.

But really, the problem is that recorded midi CC is not only sent where recorded on that node and only then
- if first value, it will be used as starting value of clip as well

I noticed this first turning leslie on in middle of a clip and then when playing back, leslie turns on at start of clip instead.
- so had to edit start value in this case
- on/off value is not the worst, just set start to zero
- but using on any type of knob on filter or envelopes or similar it become really cumbersome to work around.

Sonar only sends as where recorded
- mandatory automation conversion thingy makes StudioOne need some start value too

Cubase has a full range of settings which midi cc to convert or not, by default none.
- also having what they called automation orphan territory or similar, that allowed automation on just a part of a track

In StudioOne this also made it impossible to remove a midi CC completly(at least in v4.x).
- had a mod wheel that acted up sometimes when playing creating a CC#01 that I could not remove later.
- had to export midi to Sonar, then import back to StudioOne
- maybe this at least if fixed now, not sure

[jens]

That Reaper would be a cpu hog is a mystery to most of us, I think.
- but join the choir of it being awful gui and not pleasent to look at
- that is the biggest mystery that Justin did not fix that in 20 years development

I don't think that the look of the GUI is the main issue with Reaper - the real problem is that
a) they keep adding and adding and adding stuff without ever cleaning up,
b) settings can be in at least three different places (with all of these being pretty messy), and last but in no way the least
c) they tend to come up with complex and outright convoluted solutions to relative simple problems. They then try to iron out issues (that exist due to this convolution) by adding further options and exceptions most of which everyone except the most dedicated die-hard fans often probably don't even know what they're about.

E.g. both Reaper and Samplitude recently added a new take-lane feature. While the Magix team simply threw out the old way of comping and dealing with multiple takes and came up with a new one that basically works exactly how one would expect it to, Cockos added a completely new system that basically works in competition to the old system, is complicated and outright messy as if that had been their main-goal when comping up with it and they keep adding to it to this day.

This is just from the last four versions (since July):

Lanes: add new action to move media items up to minimize lane usage, without preserving relative lane positions •
Lanes: fix loop recording behavior when recording into multiple tracks at once (7.20 regression) •
Lanes: when track has only one lane and it is not already playing, do not automatically set that lane playing after edits .
Lanes: improve interactions between take ranking and comp areas
Lanes: add explicit 'Do not add lanes' menu item to Options/'New recording that overlaps existing media item' submenu
Lanes: copy source media take name to comping lane
Lanes: fix recording into lanes when multiple files are created due to file size limit preference
Lanes: ignore setting to automatically remove empty lanes when displaying only one lane .
Lanes: optimize drawing performance when zoomed in to a track with many lanes
Recording: Recording: do not extend recording to span time selection when recording 2 takes that do not overlap