Reason's poor cpu performance

[EdGrip]

Studio One IS considerably faster than Reason at simply importing and exporting audio, on my PC.
Beyond that, I've never used any other DAW, so I have no data. I've never bumped into my computer's limits for the simple messing about that I do, so it's never been a consideration.

[MannequinRaces]

Reason runs better on a PC. Especially with VSTs, my mac can just freeze with a beachball when adding vsts (the latest softube effects for example). I don't trust using vsts at all on my mac!

Is that a Mac thing? I'm running a 2016 MacBook Pro and get the spinning beachball sometimes with Soundtoys FX in Reason, have learned to save my work before trying to load one. Seems be worse if loading while the sequencer is running

I've heard running Windows on a Mac through Bootcamp will give you better performance so I think part of it is how OS X handles audio. So Mac users get a double whammy, lol.

[pushedbutton]

I'm in the process of uploading a file to my google account that I have just upgraded my pc to be able to play. It's about 7.3Gb of audio data. Prior to the upgrade I was getting the blue light of struggle because my SSD is where my program lives and the HDD wasn't cutting it as a scratch drive. I just installed a small (120Gb) M.2 drive and the audio dropouts are gone.
It should be a good test of disc access speed but should be light on processing.
There's lot of factors to having a decent PC for Reason but I wouldn't agree that the program has become significantly less efficient.
When i've got the link I'll share it but it will probably be in few hours cos my internet is crap.

[Marco Raaphorst]

Please also reports the performance issues to Propellerhead. Always do that, it will make Reason a lot better!

[sublunar]

Please also reports the performance issues to Propellerhead. Always do that, it will make Reason a lot better!

THIS

[lzap]

I am getting nothing else but good performance.

Yesterday, I loaded up Analog Lab 2. Man, this is slow and CPU hungry beast as standalone app. And as VST it also crashes. I do not understand why I spent money with this one.

[sublunar]

I am getting nothing else but good performance.

Yesterday, I loaded up Analog Lab 2. Man, this is slow and CPU hungry beast as standalone app. And as VST it also crashes. I do not understand why I spent money with this one.

What does this have to do with Reason? Sounds like you have an old computer or some other problem.

I'm running Arturia stuff side by side with Reason (v8) constantly and even on my 5 year old laptop I have zero issues.

[lzap]

My rig is 2017 build 8 cores 32 GB RAM. But you are right, Arturia Lab 2 is irrelevant. I just don't like it anymore Anyway R9.5 works just fine here. Very fluent.

[moalla]

Now i´m still using RE 8.32 with my new 8core 16thread Ryzen CPU, the performance iss two times better than with my previous i5 3320m Notebook.
I´m really suspend how it will work there with Re 10.

But it´s a little bit lacking, that the newer versions of RE are so CPU hungry, that older Notebooks and Pc´s are more or less useless, so especial for Live Performances it would be nice to have a more Cpu friendly modus, with a high complexity shutdown function.

[RustyShakleforde]

I have been thinking about CPU a lot recently. My two music making tools are Maschine and Reason. I used primarily reason most of my life, but currently use Maschine a lot as I enjoy it.

Anyway, I noticed recently how CPU heavy Maschine is. Comparing to Reason, Reason is sooo CPU efficient.

I recently picked up a new laptop. It has a i7 7700HQ cpu, 64gb ram (I do video rendering sometimes too), 1tb ssd drive. Maschine is really struggling compared to Reason.

On my old laptop, which had an earlier, much less powerful i7 cpu and olny cost 500 4 years ago, I made some of my best tunes in reason. I was always really amazed at what I could achieve before CPU became an issue, this was the same before and after VST integration. The performance of Reason on this maschine has had me reflecting on my new purchase, as really, I could make finished tracks in reason no problem with a little audio bouncing etc. But for future work I guess a new build is never a bad thing.

I use the same vsts in reason as I use in maschine and Reason, every single time, out performs.

The CPU thing is really interesting, and I am not saying others don't have issues, over on the NI forum some say that Maschine is more CPU friendly than my experience would suggest

In my experiences though Reason has always had the best CPU use of anything im using (it also outperformed Bitwig and reaper).

[jlgrimes]

I've been doing some simple comparisons of Reason vs Live & Logic for cpu usage. My tests have consisted of looping various stock synths playing an init patch and stacking them up until I start to get audio dropouts on my Macbook Pro.

Unfortunately it seems like Reason is much less efficient than either Live or Logic, even running the built-in synths. Monitoring CPU & Energy usage confirms that Reason is much more resource hungry. Reason used to have a reputation for CPU efficiency. What happened? The new instruments in Reason 10 are appealing but I'm inclined to run VSTs in Live instead since I have so much more headroom and battery life that way.

I think something happened with the release of Rack Extensions. That was the first release I start noticing high CPU use when the Pulverizer, Alligator, and Echo came out.

Before then I've used Reason on the crappiest of computers and you really had to try hard to get it to struggle. Back in like 2007 when most DAWs were needing a Track Freeze, Reason actually didn't even need this at all as you could layer instruments upon instruments.


Now it is pretty easy to get it to struggle even on a good machine and I wished a good Freezing system was implemented. I think it deals mainly with what devices you use. I think it is mainly the Rack Extensions (and VSTs). I think over time though Rack Extensions usually get more efficient (as the developers figure out how to do processes more efficiently), but initially some of them can be hogs.



That said Reason is still stable (I never really had it hang up or crash) but its CPU use is less efficient than it used to be.

[jlgrimes]

I've been doing some simple comparisons of Reason vs Live & Logic for cpu usage. My tests have consisted of looping various stock synths playing an init patch and stacking them up until I start to get audio dropouts on my Macbook Pro.

Unfortunately it seems like Reason is much less efficient than either Live or Logic, even running the built-in synths. Monitoring CPU & Energy usage confirms that Reason is much more resource hungry. Reason used to have a reputation for CPU efficiency. What happened? The new instruments in Reason 10 are appealing but I'm inclined to run VSTs in Live instead since I have so much more headroom and battery life that way.

I think something happened with the release of Rack Extensions. That was the first release I start noticing high CPU use when the Pulverizer, Alligator, and Echo came out.

Before then I've used Reason on the crappiest of computers and you really had to try hard to get it to struggle. Back in like 2007 when most DAWs were needing a Track Freeze, Reason actually didn't even need this at all as you could layer instruments upon instruments. I think a lot of this have to do with Props using more advanced algorithms in Rack Extensions as a result using more CPU.


Now it is pretty easy to get it to struggle even on a good machine and I wished a good Freezing system was implemented. I think it deals mainly with what devices you use. I think it is mainly the Rack Extensions (and VSTs). I think over time though Rack Extensions usually get more efficient (as the developers figure out how to do processes more efficiently), but initially some of them can be hogs.



That said Reason is still stable (I never really had it hang up or crash) but its CPU use is less efficient than it used to be.

[Ostermilk]

Reason on the other hand always runs all plugins at 64 samples buffer size, even if you have a larger buffer size set for your audio interface. This is because the buffer size basically also defines the maximum frequency that parameters/CV can be modulated and since Reason is "modulation city" that is the paramount thing.

That's the clearest way I've heard this put.

Are you saying then, that in order to get higher instance counts of devices it would come at the expense of some of Reason's flexibility?

[normen]

That's the clearest way I've heard this put.

Are you saying then, that in order to get higher instance counts of devices it would come at the expense of some of Reason's flexibility?

The only real option I see is having a setting where VST plugs are run at larger buffer sizes but that would mean that they always have additional latency in Reasons signal flow and thus modulation for those would be messed up completely (late AND lower frequency).

As for adding different buffer sizes for Reasons complete signal flow and/or adding "hidden" buffers like in Logic or other hosts.. Yes, that basically goes completely against everything Reason - the Props didn't choose that global 64 samples processing size because they're idiots

[jam-s]

As for adding different buffer sizes for Reasons complete signal flow and/or adding "hidden" buffers like in Logic or other hosts.. Yes, that basically goes completely against everything Reason - the Props didn't choose that global 64 samples processing size because they're idiots

The Reason engine could analyse the connection network and build isolated groups of devices that are not intermodulated and then with some clever tricks those groups could be rendering into larger output buffer pipelines. Linear signal chains that are not working on live audio inputs could also pre-render into a large buffer with spare cpu/io. In general using free resources to render more complex parts in advance could help to lower DSP spikes, but for this the engine would either need some heuristics to determine the DSP intense parts or to collect and cache data from previous runs (like doing an automatic soft freeze on all tracks).
Coding this and getting it to work reliably, while not impossible, would still be quite a challenge.

[normen]

The Reason engine could analyse the connection network and build isolated groups of devices that are not intermodulated and then with some clever tricks those groups could be rendering into larger output buffer pipelines. Linear signal chains that are not working on live audio inputs could also pre-render into a large buffer with spare cpu/io. In general using free resources to render more complex parts in advance could help to lower DSP spikes, but for this the engine would either need some heuristics to determine the DSP intense parts or to collect and cache data from previous runs (like doing an automatic soft freeze on all tracks).
Coding this and getting it to work reliably, while not impossible, would still be quite a challenge.

Hehe.. Believe it or not I was about to add an edit to add this but I also added the fitting answer: Look at how PDC has been implemented, do you think we'll see a network solving buffer adaption system soon?

[Ostermilk]

Thank you for explaining something I'd been noticing during some earlier comparitive testing but couldn't work out why. Namely that instance counts widened proportionally in favour of more traditional DAWs under increasing loads.

I think if it was as simple as sloppy code the percentages would most likely have had stayed constant throughout the load spectrum.

More important than comparisons and benchmarks though is how the tool performs the work during the tasks you use it for, I might be in a minority in that I render a lot of audio while I'm arranging and end up with a few prime instruments that aren't pre-rendered and I rarely run out of resources on a modest 6600k machine. The other thing as well is that I'm fortunate enough to have access to both a traditional style DAW and Reason and each have their strengths.

Reason's performance certainly hasn't got worse. I decided to run R5 on a Windows 7 partition and if you were just using what came with that there'd be no question that you'd choose a later version than that quaint old thing everytime.

[normen]

Thank you for explaining something I'd been noticing during some earlier comparitive testing but couldn't work out why. Namely that instance counts widened proportionally in favour of more traditional DAWs under increasing loads.

I think if it was as simple as sloppy code the percentages would most likely have had stayed constant throughout the load spectrum.

More important than comparisons and benchmarks though is how the tool performs the work during the tasks you use it for, I might be in a minority in that I render a lot of audio while I'm arranging and end up with a few prime instruments that aren't pre-rendered and I rarely run out of resources on a modest 6600k machine. The other thing as well is that I'm fortunate enough to have access to both a traditional style DAW and Reason and each have their strengths.

Reason's performance certainly hasn't got worse. I decided to run R5 on a Windows 7 partition and if you were just using what came with that there'd be no question that you'd choose a later version than that quaint old thing everytime.

Mhm.. It also differs from plugin to plugin. Some algorithms work well with lower buffer sized and scale basically linear. Some don't. The UAD system has to shovel all the audio data through the PCI bus, into a DSP and back via the PCI bus into the CPU.. Not something you want to have only 64 samples time for

So yeah, if you choose your plugins well you can have a lot of fun in Reason extending it with VST plugins. If you're mixing a session with 16 Kontakt instruments and audio tracks loaded with UAD plugins... Why the FUCK are you using Reason for that?

[JdA57]

I am getting nothing else but good performance.

Yesterday, I loaded up Analog Lab 2. Man, this is slow and CPU hungry beast as standalone app. And as VST it also crashes. I do not understand why I spent money with this one.

O.o you really working with Version 2.1.2.80 ? Because before this version crashed only in Reason. Now I saw it never crashing anymore in any DAW.
(ok, I don't know about all OS-systems)

And for shure, in compare to other VSTi's it is'nt really cpu-hungry.

[Ostermilk]

Thank you for explaining something I'd been noticing during some earlier comparitive testing but couldn't work out why. Namely that instance counts widened proportionally in favour of more traditional DAWs under increasing loads.

I think if it was as simple as sloppy code the percentages would most likely have had stayed constant throughout the load spectrum.

More important than comparisons and benchmarks though is how the tool performs the work during the tasks you use it for, I might be in a minority in that I render a lot of audio while I'm arranging and end up with a few prime instruments that aren't pre-rendered and I rarely run out of resources on a modest 6600k machine. The other thing as well is that I'm fortunate enough to have access to both a traditional style DAW and Reason and each have their strengths.

Reason's performance certainly hasn't got worse. I decided to run R5 on a Windows 7 partition and if you were just using what came with that there'd be no question that you'd choose a later version than that quaint old thing everytime.

Mhm.. It also differs from plugin to plugin. Some algorithms work well with lower buffer sized and scale basically linear. Some don't. The UAD system has to shovel all the audio data through the PCI bus, into a DSP and back via the PCI bus into the CPU.. Not something you want to have only 64 samples time for

So yeah, if you choose your plugins well you can have a lot of fun in Reason extending it with VST plugins. If you're mixing a session with 16 Kontakt instruments and audio tracks loaded with UAD plugins... Why the FUCK are you using Reason for that?

My thoughts exactly.

[chaosroyale]

Seems like a Freeze function would solve a lot of this for reason-like users who value modularity/CV, and don't want it to be exactly the same as any other VST-driven DAW.

Even a very "conservative" Freeze which only lets you Freeze a track which is completely self-contained and functionally identical to audio (ie: one combinator with no realtime CV or side chains going in or out to other tracks).

[jlgrimes]

Seems like a Freeze function would solve a lot of this for reason-like users who value modularity/CV, and don't want it to be exactly the same as any other VST-driven DAW.

Even a very "conservative" Freeze which only lets you Freeze a track which is completely self-contained and functionally identical to audio (ie: one combinator with no realtime CV or side chains going in or out to other tracks).

Agreed.

I think even Ableton’s Freeze is limited as you can’t freeze sidechained tracks. But it still works wonders and helps a lot with CPU hungry plugins which is inevitable with VSTS.

[normen]

Seems like a Freeze function would solve a lot of this for reason-like users who value modularity/CV, and don't want it to be exactly the same as any other VST-driven DAW.

Even a very "conservative" Freeze which only lets you Freeze a track which is completely self-contained and functionally identical to audio (ie: one combinator with no realtime CV or side chains going in or out to other tracks).

Yeah, Reason kind of has that functionality with its "bounce to new tracks and mute old" function but it doesn't hide whats happening as well as the simple freeze button in other DAWs. Then again the new "bounce clip to audio" opens up new ways to deal with sounds coming from instruments.

[deepndark]

Would it be possible to radically save CPU, by geniously coding Reason doing it? Maybe they already have done it and there's really not much ways left saving CPU?

[pushedbutton]

I'm in the process of uploading a file to my google account that I have just upgraded my pc to be able to play. It's about 7.3Gb of audio data. Prior to the upgrade I was getting the blue light of struggle because my SSD is where my program lives and the HDD wasn't cutting it as a scratch drive. I just installed a small (120Gb) M.2 drive and the audio dropouts are gone.
It should be a good test of disc access speed but should be light on processing.
There's lot of factors to having a decent PC for Reason but I wouldn't agree that the program has become significantly less efficient.
When i've got the link I'll share it but it will probably be in few hours cos my internet is crap.

Here's that file I mentioned. It took a while but it's there now. have fun.