Hydlides rant about performance

This forum is for discussing Propellerhead's music software. Questions, answers, ideas, and opinions... all apply.
User avatar
aeox
Posts: 1395
Joined: 23 Feb 2017
Location: Oregon

10 Jul 2018

jimmyklane wrote:
10 Jul 2018
aeox wrote:
10 Jul 2018


I can run about 100 instances of a supersaw patch I made in eXpanse that has 4 osc, each with 8 voice unsion, playing 5 note chords. How many instances of Europa? Seemingly endless... Not even something I would think about.

I definitely have performance issues with VST like most people but not RE.
That was my point. I’ve not gone beyond 48 of the most demanding Europa and Grain Patches....but I can get 48 of each at 128 samples without breaking much of a sweat. I’d never USE that in real life, but it is an interesting benchmark. I DO use 8 instances with Distributor in a single Combinator all the time....and sometimes 2-3 of those to sample layers into the Ensoniq or Emu.

Makes me want to NOT upgrade. Reason works really well for me right now, with only Diva and Repro causing any hardship.....but I don’t really use those since I actually OWN many of those synths. I just offload the entire sound creation, effects, and processing to my outboard and use Reason as a MIDI sequencer and audio recorder. The mixing is often done on my console and the synths themselves are often recorded “wet” so I can use the hardware I have for multiple effects.
Agreeing with you and sharing my results :thumbs_up:

User avatar
candybag
Posts: 27
Joined: 26 Feb 2018
Location: Sweden
Contact:

11 Jul 2018

Yesterday i realized the EQ (F2) drains quite alot of resources. I always have it open on one screen, but turning it off made all my stuttering projects play smooth again. No VST's involved tho.

I've read about optimization and how closing combinators help reduce DSP load, just didn't occur to me that it goes for the EQ as well!
Yamaha HS7 - HD600 - Focusrite Scarlett 2i2 - Akai MPK261 - AT2050 - Auralex Project 2™ Roominator Kit
6700K - 16 GB - 3xXB270HU - GTX 1080 ti

jlgrimes
Posts: 219
Joined: 06 Jun 2017

11 Jul 2018

candybag wrote:
11 Jul 2018
Yesterday i realized the EQ (F2) drains quite alot of resources. I always have it open on one screen, but turning it off made all my stuttering projects play smooth again. No VST's involved tho.

I've read about optimization and how closing combinators help reduce DSP load, just didn't occur to me that it goes for the EQ as well!

I think it is more the Spectrum Analyzer and less the EQ.

I think there are some graphics issues with Reason. I heard the problem is worse on Macs.

I use both Mac and PC. I have to use Mac in Low Resolution mode to get decent performance.

User avatar
normen
Posts: 3331
Joined: 16 Jan 2015

11 Jul 2018

jlgrimes wrote:
11 Jul 2018
candybag wrote:
11 Jul 2018
Yesterday i realized the EQ (F2) drains quite alot of resources. I always have it open on one screen, but turning it off made all my stuttering projects play smooth again. No VST's involved tho.

I've read about optimization and how closing combinators help reduce DSP load, just didn't occur to me that it goes for the EQ as well!

I think it is more the Spectrum Analyzer and less the EQ.

I think there are some graphics issues with Reason. I heard the problem is worse on Macs.

I use both Mac and PC. I have to use Mac in Low Resolution mode to get decent performance.
I think you‘re right on every point there.

User avatar
selig
Moderator
Posts: 6714
Joined: 15 Jan 2015

11 Jul 2018

jlgrimes wrote:
11 Jul 2018
candybag wrote:
11 Jul 2018
Yesterday i realized the EQ (F2) drains quite alot of resources. I always have it open on one screen, but turning it off made all my stuttering projects play smooth again. No VST's involved tho.

I've read about optimization and how closing combinators help reduce DSP load, just didn't occur to me that it goes for the EQ as well!

I think it is more the Spectrum Analyzer and less the EQ.

I think there are some graphics issues with Reason. I heard the problem is worse on Macs.

I use both Mac and PC. I have to use Mac in Low Resolution mode to get decent performance.
It's actually more the screen redraw than the spectrum calculation in my testing. While there's no more resolution (FFT points) with a bigger window size, the CPU hit can significantly increase with increases to the size of the FFT/EQ display. At it's smallest size it hardly makes a dent in my CPU, but at the largest (iMac screen) it's approaching double the CPU hit (according to Activity Monitor). I'm no expert on this so I could be mis-reading the data, but my conclusion is that screen redraws cause more CPU hit than FFT (or other) calculations, at least on a Mac.

Further tests: with my ColoringEQ FFT display, there is a "hold" function (very useful, btw). When the display is in hold mode for a few seconds/minutes (until it no longer changes/updates), the CPU hit is almost exactly back to about where it was with no display.
Selig Audio, LLC

User avatar
antic604
Posts: 801
Joined: 23 Oct 2017
Location: Warsaw, Poland
Contact:

11 Jul 2018

candybag wrote:
11 Jul 2018
Yesterday i realized the EQ (F2) drains quite alot of resources. I always have it open on one screen, but turning it off made all my stuttering projects play smooth again. No VST's involved tho.
Reason doesn't use GPU to render the graphics - just check how much of your graphics card is used in Task Manager... - so the more things you have on screen, the more dynamic they are (like spectrum analyzers, oscilloscopes, LFO displays, volume meters, even moving knobs) and the higher the resolution, the less CPU cycles is left for processing audio :(

Hopefully this is fixed while they're porting Reason's rendering to support high-DPI screens :)
Reason 10 // Bitwig 2 // Live 10 // Studio One 4
My music: https://soundcloud.com/antic604

User avatar
EnochLight
Posts: 4458
Joined: 17 Jan 2015

11 Jul 2018

antic604 wrote:
11 Jul 2018
candybag wrote:
11 Jul 2018
Yesterday i realized the EQ (F2) drains quite alot of resources. I always have it open on one screen, but turning it off made all my stuttering projects play smooth again. No VST's involved tho.
Reason doesn't use GPU to render the graphics - just check how much of your graphics card is used in Task Manager... - so the more things you have on screen, the more dynamic they are (like spectrum analyzers, oscilloscopes, LFO displays, volume meters, even moving knobs) and the higher the resolution, the less CPU cycles is left for processing audio :(

Hopefully this is fixed while they're porting Reason's rendering to support high-DPI screens :)
To expand on this a little, I was under the impression that Reason's spectral window, when open, utilizes DirectX on Windows. Not sure how it works on Macs, though.
Windows 10 64-bit | Reason 10 |  Studio One 3.5| Asus Sabertooth Z77 | Intel i7 3770k Quad-Core @ 4.5 Ghz | 16 GB RAM | Mushkin Reactor 1TB SSD | RME babyface Pro| Nektar Panorama P-4 | M-Audio Trigger Finger Pro

User avatar
antic604
Posts: 801
Joined: 23 Oct 2017
Location: Warsaw, Poland
Contact:

11 Jul 2018

EnochLight wrote:
11 Jul 2018
antic604 wrote:
11 Jul 2018


Reason doesn't use GPU to render the graphics - just check how much of your graphics card is used in Task Manager... - so the more things you have on screen, the more dynamic they are (like spectrum analyzers, oscilloscopes, LFO displays, volume meters, even moving knobs) and the higher the resolution, the less CPU cycles is left for processing audio :(

Hopefully this is fixed while they're porting Reason's rendering to support high-DPI screens :)
To expand on this a little, I was under the impression that Reason's spectral window, when open, utilizes DirectX on Windows. Not sure how it works on Macs, though.
It does? Have to check this, because indeed my Surface Pro 4 struggles much more when I'm switching to the Rack (and scrolling it, when a lot of things are moving there) than opening the channel EQ. Considering how this is probably a separate process from the "standard" GUI I wouldn't be surprised if this was the case.
Reason 10 // Bitwig 2 // Live 10 // Studio One 4
My music: https://soundcloud.com/antic604

jlgrimes
Posts: 219
Joined: 06 Jun 2017

11 Jul 2018

antic604 wrote:
11 Jul 2018
candybag wrote:
11 Jul 2018
Yesterday i realized the EQ (F2) drains quite alot of resources. I always have it open on one screen, but turning it off made all my stuttering projects play smooth again. No VST's involved tho.
Reason doesn't use GPU to render the graphics - just check how much of your graphics card is used in Task Manager... - so the more things you have on screen, the more dynamic they are (like spectrum analyzers, oscilloscopes, LFO displays, volume meters, even moving knobs) and the higher the resolution, the less CPU cycles is left for processing audio :(

Hopefully this is fixed while they're porting Reason's rendering to support high-DPI screens :)
Yeah I hope they get that together. Graphic performance have been one of my biggest issues when using Reason on Mac. I have to use my PC more though to see if there is a really big improvement but Reason (esp in High Resolution Mode) could easily hiccup with open Spectrum Windows and scrolling quickly in the Rack.


Low Res mode works a lot better, but has a few minor bumps at low buffer settings (128) with my UAD Apollo. At buffer sizes of 512 or higher Reason actually seem pretty efficient or at least for my use, but I use Reason at low latencies most of the time for playing synths.

WongoTheSane
Posts: 1445
Joined: 14 Sep 2015
Location: Paris, France

11 Jul 2018

EnochLight wrote:
11 Jul 2018
antic604 wrote:
11 Jul 2018


Reason doesn't use GPU to render the graphics - just check how much of your graphics card is used in Task Manager... - so the more things you have on screen, the more dynamic they are (like spectrum analyzers, oscilloscopes, LFO displays, volume meters, even moving knobs) and the higher the resolution, the less CPU cycles is left for processing audio :(

Hopefully this is fixed while they're porting Reason's rendering to support high-DPI screens :)
To expand on this a little, I was under the impression that Reason's spectral window, when open, utilizes DirectX on Windows. Not sure how it works on Macs, though.
That may very well be the case: when recording with OBS Studio, the Spectrum window isn't captured...

User avatar
bitley
Posts: 626
Joined: 03 Jul 2015
Location: sweden
Contact:

11 Jul 2018

I've not read the thread but just made an observation;

According to a blurry but somewhat readable screen image this virtual ASIO driver is in use;

https://www.kvraudio.com/product/voicem ... y-vb-audio

Reason's performace is deeply tied with the sound card & sound card settings.

Amongst my computers I have a fairly new (2016/2017 model) laptop PC from HP which I use with Asio4All, not a "main" computer at all but one for my kids to use when playing Minecraft etc, and I can just say that used in that way, with Reason, it performs worse than Reason 1.01 did on an Mac Powerbook G3 back in 2001. :shock: My relation with Windows is as it's always been... and this is even W10 & also W10 early release preview... nothing has changed... :cry:

jimmyklane
Posts: 660
Joined: 16 Apr 2018

11 Jul 2018

WongoTheSane wrote:
11 Jul 2018

That may very well be the case: when recording with OBS Studio, the Spectrum window isn't captured...
I had to use a different screen capture system because of this very issue.

As a side note, it seems to me as if Reason dedicates one of my CPU cores to screen draw. When I’m up at the wall, dragging or scrolling ANYTHING causes brief stutters and odd computer noises.
DAW: Reason 10,

SAMPLERS: Akai MPC 2000, E-mu SP1200, E-Mu e5000Ultra, Ensoniq EPS 16+, Akai S950, Maschine

SYNTHS: Mostly classic Polysynths and more modern Monosynths. All are mostly food for my samplers!

www.soundcloud.com/jimmyklane

User avatar
EnochLight
Posts: 4458
Joined: 17 Jan 2015

11 Jul 2018

jimmyklane wrote:
11 Jul 2018
As a side note, it seems to me as if Reason dedicates one of my CPU cores to screen draw.
This would be correct.
Windows 10 64-bit | Reason 10 |  Studio One 3.5| Asus Sabertooth Z77 | Intel i7 3770k Quad-Core @ 4.5 Ghz | 16 GB RAM | Mushkin Reactor 1TB SSD | RME babyface Pro| Nektar Panorama P-4 | M-Audio Trigger Finger Pro

mcatalao
Posts: 721
Joined: 17 Jan 2015

12 Jul 2018

selig wrote:
jlgrimes wrote:
11 Jul 2018

I think it is more the Spectrum Analyzer and less the EQ.

I think there are some graphics issues with Reason. I heard the problem is worse on Macs.

I use both Mac and PC. I have to use Mac in Low Resolution mode to get decent performance.
It's actually more the screen redraw than the spectrum calculation in my testing. While there's no more resolution (FFT points) with a bigger window size, the CPU hit can significantly increase with increases to the size of the FFT/EQ display. At it's smallest size it hardly makes a dent in my CPU, but at the largest (iMac screen) it's approaching double the CPU hit (according to Activity Monitor). I'm no expert on this so I could be mis-reading the data, but my conclusion is that screen redraws cause more CPU hit than FFT (or other) calculations, at least on a Mac.

Further tests: with my ColoringEQ FFT display, there is a "hold" function (very useful, btw). When the display is in hold mode for a few seconds/minutes (until it no longer changes/updates), the CPU hit is almost exactly back to about where it was with no display.
This corroborates some tests I did in the past where I found that if you had the rack and mixer windows closed you the cpu test project would run some more tracks. Which is odd because I always thought reason would use one core for screen rendering. At some more troublesome projects moving windows around or opening and closing windows cause glitches despite using a gpu or the cpu original graphic chip.

Sent from my WAS-LX1A using Tapatalk


User avatar
candybag
Posts: 27
Joined: 26 Feb 2018
Location: Sweden
Contact:

12 Jul 2018

jlgrimes wrote:
11 Jul 2018
candybag wrote:
11 Jul 2018
Yesterday i realized the EQ (F2) drains quite alot of resources. I always have it open on one screen, but turning it off made all my stuttering projects play smooth again. No VST's involved tho.

I've read about optimization and how closing combinators help reduce DSP load, just didn't occur to me that it goes for the EQ as well!

I think it is more the Spectrum Analyzer and less the EQ.

I think there are some graphics issues with Reason. I heard the problem is worse on Macs.

I use both Mac and PC. I have to use Mac in Low Resolution mode to get decent performance.
Right you are, i was talking about the Spectrum Analyzer when i wrote EQ. Got the terminology mixed up :D
Yamaha HS7 - HD600 - Focusrite Scarlett 2i2 - Akai MPK261 - AT2050 - Auralex Project 2™ Roominator Kit
6700K - 16 GB - 3xXB270HU - GTX 1080 ti

User avatar
KIKBAK1
Posts: 80
Joined: 22 Jan 2015

13 Jul 2018

I've had this 12core Mac tower for a couple years now, with 64 gigs of ram & ssd drive. Its simply mind boggling that playing 1 chord on EXPANSE would spike the DSP to the max. Reason is definitely not taking full advantage of the 12 cores blah blah blah..Yes major improvements can be made blah blah blah. At the end of the day, It still gets the job done. And as far as Hydlide goes, I don't have anything bad to say about a guy who's put that much time, energy & effort into creating all that content.
KIKBAK1.com

User avatar
jappe
Posts: 1899
Joined: 19 Jan 2015

13 Jul 2018

MarkTarlton wrote:
09 Jul 2018
here is a post from facebook by magnus lidstrom!

"Simple truth is that less cores with higher cpu clock is nearly always better than more cores with lower cpu clock (not only talking about audio). In general (and in theory), more cores means you can run more plug-ins simultaneously. Higher CPU clock means you can run heavier plug-ins with lower latency. Modern processors actually run on variable clock frequency that adapts to CPU heat, which means that the CPU will begin to run slower if you push a lot of work on all its cores = bad for latency. However, the single biggest (or narrowest? :) ) bottleneck is usually memory accesses, not raw number crunching power. Also for audio. This complicates matters so much that it is virtually impossible to estimate CPU performance reliably nowadays."
is the context for this Reason, or DAW:s in general?

There's a thread about memory performance discussing this:
viewtopic.php?f=4&t=7506316

User avatar
MarkTarlton
Posts: 268
Joined: 15 Jan 2015
Location: Santa Rosa, CA

13 Jul 2018

jappe wrote:
13 Jul 2018
MarkTarlton wrote:
09 Jul 2018
here is a post from facebook by magnus lidstrom!

"Simple truth is that less cores with higher cpu clock is nearly always better than more cores with lower cpu clock (not only talking about audio). In general (and in theory), more cores means you can run more plug-ins simultaneously. Higher CPU clock means you can run heavier plug-ins with lower latency. Modern processors actually run on variable clock frequency that adapts to CPU heat, which means that the CPU will begin to run slower if you push a lot of work on all its cores = bad for latency. However, the single biggest (or narrowest? :) ) bottleneck is usually memory accesses, not raw number crunching power. Also for audio. This complicates matters so much that it is virtually impossible to estimate CPU performance reliably nowadays."
is the context for this Reason, or DAW:s in general?

There's a thread about memory performance discussing this:
viewtopic.php?f=4&t=7506316
the quote's context of this question is being asked on facebook by my friend tony.

"To my audio DSP friends... would it be safe to say that multi-threaded audio is still developing and that for audio production, you’re better off getting less cores at a higher clock rate than more cores at a lower clock rate?"

User avatar
MarkTarlton
Posts: 268
Joined: 15 Jan 2015
Location: Santa Rosa, CA

13 Jul 2018

another goodie from facebook...

Hayden Bursk - "In general, multi-threaded audio is challenging. No one wants latency. Multi-cores means adding latency. But, if you want to do mixing with a lot of effects, multi-core can help with that. If you want to track through lots of effects or use virtual instruments with low latency, you won’t be splitting the processing for that among cores most likely. From what I hear, Logic is the best at doing a lot of work behind the scene so you can always hit play and get lots of plugin instances. But it needs cores to do that. More of everything is always best."

Hauser+Quaid
Posts: 113
Joined: 06 Jun 2017

15 Jul 2018

jlgrimes wrote:
11 Jul 2018
candybag wrote:
11 Jul 2018
Yesterday i realized the EQ (F2) drains quite alot of resources. I always have it open on one screen, but turning it off made all my stuttering projects play smooth again. No VST's involved tho.

I've read about optimization and how closing combinators help reduce DSP load, just didn't occur to me that it goes for the EQ as well!

I think it is more the Spectrum Analyzer and less the EQ.

I think there are some graphics issues with Reason. I heard the problem is worse on Macs.

I use both Mac and PC. I have to use Mac in Low Resolution mode to get decent performance.
There are definitely graphics issues on Macs, and odd ones at that. I guess it's as noted above something to do with the GPU (I'm definitely not an expert on any of this). The interesting thing for me is the smoothness in VSTs like Serum. When placed directly in Reason, Serum looks terrible. The knob movement is choppy and the general graphic movement is awful. Like putting an LFO to a Wavetable position for example... it just looks awful and not smooth at all!

However, as soon as I load Serum in a container like Komplete Kontrol, all of the graphic issues magically disappear! It's smooth as in any other DAW, the redraw rates are beautiful and everything is smooth. No idea what the issue is or if this is something to do with the Props side or Xfer's side. Maybe I should ask Steve Duda...

Post Reply
  • Information