Page 6 of 6
Re: Hydlides rant about performance
Posted: 10 Jul 2018
by aeox
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
Re: Hydlides rant about performance
Posted: 11 Jul 2018
by candybag
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!
Re: Hydlides rant about performance
Posted: 11 Jul 2018
by jlgrimes
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.
Re: Hydlides rant about performance
Posted: 11 Jul 2018
by normen
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.
Re: Hydlides rant about performance
Posted: 11 Jul 2018
by selig
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.
Re: Hydlides rant about performance
Posted: 11 Jul 2018
by antic604
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
Re: Hydlides rant about performance
Posted: 11 Jul 2018
by EnochLight
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.
Re: Hydlides rant about performance
Posted: 11 Jul 2018
by antic604
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.
Re: Hydlides rant about performance
Posted: 11 Jul 2018
by jlgrimes
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.
Re: Hydlides rant about performance
Posted: 11 Jul 2018
by WongoTheSane
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...
Re: Hydlides rant about performance
Posted: 11 Jul 2018
by bitley
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.
My relation with Windows is as it's always been... and this is even W10 & also W10 early release preview... nothing has changed...
Re: Hydlides rant about performance
Posted: 11 Jul 2018
by jimmyklane
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.
Re: Hydlides rant about performance
Posted: 11 Jul 2018
by EnochLight
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.
Re: Hydlides rant about performance
Posted: 12 Jul 2018
by mcatalao
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
Re: Hydlides rant about performance
Posted: 12 Jul 2018
by candybag
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
Re: Hydlides rant about performance
Posted: 13 Jul 2018
by KIKBAK1
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.
Re: Hydlides rant about performance
Posted: 13 Jul 2018
by jappe
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
Re: Hydlides rant about performance
Posted: 13 Jul 2018
by MarkTarlton
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?"
Re: Hydlides rant about performance
Posted: 13 Jul 2018
by MarkTarlton
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."
Re: Hydlides rant about performance
Posted: 15 Jul 2018
by Hauser+Quaid
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...