Hydlides rant about performance

This forum is for discussing Reason. Questions, answers, ideas, and opinions... all apply.
ShawnG
Posts: 120
Joined: 31 Aug 2015

08 Jul 2018

normen wrote:
08 Jul 2018
jimmyklane wrote:
08 Jul 2018
what I’m wondering is if PH can even DO something like calling VSTs at the buffer size while still calling internal instruments at 64 samples. I’m not proficient enough with coding to know if running VSTs at some multiple of 64 samples (like your example of 256) would be possible while maintaining the speed of CV for internal devices. It may come down to an “efficiency vs speed” slider setting in the DAW.
Exactly that is what I suggest would be the easiest "fix" for certain VSTs. Allow setting a separate buffer size for either all VSTs, single VSTs or even single VST instances. In terms of ramifications you'd always have delay and a "quantization" of sorts for the CV of the VST(s) and depending on the situation you'd have a certain additional audio delay when using that VST live. Then of course CV would not work properly for all plugins, buses etc. where the VST is routed to either, so from each VST on it's problems :/

It's a bit ugly to program (afaics) and imo also a bit ugly to handle as a user - interested to see what the props do about it. They could try and invoke the "unusual signal flow detection" of the mix channel PDC. Then Reason could "automagically" set VSTs that have "normal" signal flow (no CV) to buffer size and those that have CV to 64 samples.

All in all thats why to me VST integration always was shoehorning something onto Reason that just doesn't fit there. So I was one of those "Props excusing anti-VST idiots" because I KNEW that this would be the outcome. VST in Reason can be fun - if you don't try and use it to send your audio to a PCI based DSP card :roll:
I am assuming the same issue is manifest in some third party RE's as well? The video In the OP isn't using a VST.

User avatar
normen
Posts: 3431
Joined: 16 Jan 2015

08 Jul 2018

ShawnG wrote:
08 Jul 2018
I am assuming the same issue is manifest in some third party RE's as well? The video In the OP isn't using a VST.
Sure, some synths that are ported 1:1 to an environment where they always have to run at 64 samples might not like that. Any synth can raise the DSP meter. If you watch the video I made you might see why that's the case. It's about TIME. If a plugin needs or wastes TIME - not CPU cycles - the DSP meter rises.

See if I wrote a RE that just waited 3 milliseconds each time it's called and did nothing else then it would max out the DSP meter instantly without using a single CPU cycle. You could install a 10,000GHz CPU with 10,000 cores and it would not help, even if I waited in 10,000 threads to use all cores :)

So the "test" and "conclusions" in OPs video are flawed, computing an oscillator will not happen faster when you throw more cores at it. Taking some time to build and configure your computer properly like jimmyklane did would help - then you can run Reason with 10 year old hardware.

User avatar
aeox
Competition Winner
Posts: 3222
Joined: 23 Feb 2017
Location: Oregon

08 Jul 2018

normen wrote:
08 Jul 2018
ShawnG wrote:
08 Jul 2018
I am assuming the same issue is manifest in some third party RE's as well? The video In the OP isn't using a VST.
Sure, some synths that are ported 1:1 to an environment where they always have to run at 64 samples might not like that. Any synth can raise the DSP meter. If you watch the video I made you might see why that's the case. It's about TIME. If a plugin needs or wastes TIME - not CPU cycles - the DSP meter rises.

See if I wrote a RE that just waited 3 milliseconds each time it's called and did nothing else then it would max out the DSP meter instantly without using a single CPU cycle. You could install a 10,000GHz CPU with 10,000 cores and it would not help, even if I waited in 10,000 threads to use all cores :)

So the "test" and "conclusions" in OPs video are flawed, computing an oscillator will not happen faster when you throw more cores at it. Taking some time to build and configure your computer properly like jimmyklane did would help - then you can run Reason with 10 year old hardware.
Thanks :)

User avatar
EnochLight
Moderator
Posts: 8405
Joined: 17 Jan 2015
Location: Imladris

08 Jul 2018

O1B wrote:
08 Jul 2018
Seqio's 'language barrier' aside...

That was for you, Enoch Light.
Still no Apology, Enoch Light?

Peace, Enoch Light.
Apology for what? Please stay on the thread topic.
Win 10 | Ableton Live 11 Suite |  Reason 12 | i7 3770k @ 3.5 Ghz | 16 GB RAM | RME Babyface Pro | Akai MPC Live 2 & Akai Force | Roland System 8, MX1, TB3 | Dreadbox Typhon | Korg Minilogue XD

User avatar
normen
Posts: 3431
Joined: 16 Jan 2015

08 Jul 2018

aeox wrote:
08 Jul 2018
normen wrote:
08 Jul 2018


Sure, some synths that are ported 1:1 to an environment where they always have to run at 64 samples might not like that. Any synth can raise the DSP meter. If you watch the video I made you might see why that's the case. It's about TIME. If a plugin needs or wastes TIME - not CPU cycles - the DSP meter rises.

See if I wrote a RE that just waited 3 milliseconds each time it's called and did nothing else then it would max out the DSP meter instantly without using a single CPU cycle. You could install a 10,000GHz CPU with 10,000 cores and it would not help, even if I waited in 10,000 threads to use all cores :)

So the "test" and "conclusions" in OPs video are flawed, computing an oscillator will not happen faster when you throw more cores at it. Taking some time to build and configure your computer properly like jimmyklane did would help - then you can run Reason with 10 year old hardware.
Thanks :)
You're welcome :)

I forgot to add that that same RE would only use 50% DSP as a VST in a host where the buffer size is set to 6 milliseconds. So you might actually say that Reason is the ultimate test for any plugin wasting time, really :ugeek: ;)

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

08 Jul 2018

normen wrote:
08 Jul 2018
If you watch the video I made you might see why that's the case. It's about TIME. If a plugin needs or wastes TIME - not CPU cycles - the DSP meter rises.
so multi-core processors are at the mercy of both the usb and memory bus, essentially bottle necking the data, along with other variable like parallel audio tracks? I think the video made sense to me :)

thanks

User avatar
EnochLight
Moderator
Posts: 8405
Joined: 17 Jan 2015
Location: Imladris

08 Jul 2018

normen wrote:
08 Jul 2018
So the "test" and "conclusions" in OPs video are flawed, computing an oscillator will not happen faster when you throw more cores at it. Taking some time to build and configure your computer properly like jimmyklane did would help - then you can run Reason with 10 year old hardware.
Oh boy, you're going to make the natives restless - careful! :lol: :puf_bigsmile: But you do agree that Reason's VST performance needs to be improved to be on par with other DAW?
Win 10 | Ableton Live 11 Suite |  Reason 12 | i7 3770k @ 3.5 Ghz | 16 GB RAM | RME Babyface Pro | Akai MPC Live 2 & Akai Force | Roland System 8, MX1, TB3 | Dreadbox Typhon | Korg Minilogue XD

User avatar
normen
Posts: 3431
Joined: 16 Jan 2015

08 Jul 2018

MarkTarlton wrote:
08 Jul 2018
so multi-core processors are at the mercy of both the usb and memory bus, essentially bottle necking the data, along with other variable like parallel audio tracks? I think the video made sense to me :)

thanks
Yeah, it's all about how much time is spent with what. Computing is only so much of it all and while a second core can help with all the USB management etc. (they have to do a lot of stuff like that too), having 8 cores compute one sine just isn't feasible so no single synth uses multiple cores for that. And that's what OP basically expects to happen. It's about how quickly the output of the synth can be generated and at some point more computing power simply won't reduce that time. High DSP load could be anything - the graphics card causing "micro-lags" where the CPU can't work etc. etc. etc. The larger your processing buffer the less you realize the amount of time you lose.

Whats said in the video is true for the whole signal flow in any DAW really. Every plugin is a step in there - as said some even send the data back out and in again instead of letting the CPU just do it's work ;) And yeah, Reason always has to deal with the small buffer size internally (not at the USB/system level). It's a blessing and a curse and I wouldn't want it to be different :)

User avatar
rcbuse
RE Developer
Posts: 1175
Joined: 16 Jan 2015
Location: SR388
Contact:

08 Jul 2018

Same strange behavior here on a macbook pro Intel Core i7. Did some tests with a good old mono/poly loaded and a ton of voices. In theory, a single RE should only occupy a single core.



The other interesting thing is, I can add more instances of the mono/poly, which totally kills the single mode, and it runs fine in the multi-core mode without any changes in CPU load (still all peaked)
Last edited by rcbuse on 09 Jul 2018, edited 1 time in total.

seqoi
Posts: 417
Joined: 12 Aug 2017

08 Jul 2018

O1B wrote:
08 Jul 2018
Seqio's 'language barrier' aside...

Image
"How Dare YOU"
I still don't get it but i'll leave it at that. You guys are awesome :mrgreen:

This is a bit OT but does anyone here tried Reason with AMD Threadripper and how it stacked? I am aware of CPU problems but PH will eventually solve them. While we wait if anyone tried it - did you find some significant performance boost in Reason?

User avatar
moneykube
Posts: 3447
Joined: 15 Jan 2015

09 Jul 2018

rcbuse wrote:
08 Jul 2018
Same strange behavior here on a macbook pro Intel Core i7. Did some tests with a good old mono/poly loaded and a ton of voices. In theory, a single RE should only occupy a single core.
:thumbs_up: :thumbs_up: my life :o :o :roll:
https://soundcloud.com/moneykube-qube/s ... d-playlist
Proud Member Of The Awesome League Of Perpetuals

elMisse
Posts: 135
Joined: 17 Jan 2015
Contact:

09 Jul 2018

I only care about a i7 HQ laptop telling me it is too slow when just browsing/trying presets in f.ex some U-HE synths.
Building some actual music around it...? Ehh...

Almost learned some actual workflow on Live already because of this situation.
See, Live (and so many others) can stack 5-10 of those presets without choking, as you all surely know already.

User avatar
jam-s
Posts: 3036
Joined: 17 Apr 2015
Location: Aachen, Germany
Contact:

09 Jul 2018

normen wrote:
08 Jul 2018
jimmyklane wrote:
08 Jul 2018
what I’m wondering is if PH can even DO something like calling VSTs at the buffer size while still calling internal instruments at 64 samples. I’m not proficient enough with coding to know if running VSTs at some multiple of 64 samples (like your example of 256) would be possible while maintaining the speed of CV for internal devices. It may come down to an “efficiency vs speed” slider setting in the DAW.
Exactly that is what I suggest would be the easiest "fix" for certain VSTs. Allow setting a separate buffer size for either all VSTs, single VSTs or even single VST instances. In terms of ramifications you'd always have delay and a "quantization" of sorts for the CV of the VST(s) and depending on the situation you'd have a certain additional audio delay when using that VST live. Then of course CV would not work properly for all plugins, buses etc. where the VST is routed to either, so from each VST on it's problems :/

It's a bit ugly to program (afaics) and imo also a bit ugly to handle as a user - interested to see what the props do about it. They could try and invoke the "unusual signal flow detection" of the mix channel PDC. Then Reason could "automagically" set VSTs that have "normal" signal flow (no CV) to buffer size and those that have CV to 64 samples.

All in all thats why to me VST integration always was shoehorning something onto Reason that just doesn't fit there. So I was one of those "Props excusing anti-VST idiots" because I KNEW that this would be the outcome. VST in Reason can be fun - if you don't try and use it to send your audio to a PCI based DSP card or wire a whole different sampling system into Reason :roll:
Another possibility for Props would be to have a kind of soft-/autofreeze function for all VSTi that would work like this:
During times of low DSP/CPU load prerender the VSTi output (possibly using a larger buffer) and keep the generated audio data in a hidden audiotrack until the user changes the settings/automation of the VSTi.

antic604

09 Jul 2018

jam-s wrote:
09 Jul 2018
During times of low DSP/CPU load prerender the VSTi output (possibly using a larger buffer) and keep the generated audio data in a hidden audiotrack until the user changes the settings/automation of the VSTi.
That's what Reaper, Cubase (and presumably Studio One) are doing.

However, for DAW like Reason - with complex routing, modulation, random devices - this might not be as effective as for "linear" DAWs that only keep the REC-armed track "live" and the rest is pre-computed.

User avatar
jam-s
Posts: 3036
Joined: 17 Apr 2015
Location: Aachen, Germany
Contact:

09 Jul 2018

antic604 wrote:
09 Jul 2018
However, for DAW like Reason - with complex routing, modulation, random devices - this might not be as effective as for "linear" DAWs that only keep the REC-armed track "live" and the rest is pre-computed.
As Reason does know about the modulation routing network it can also run this in the background in advance, too (and possibly cache the generated CV modulation as well until something is changed in the modulation node tree).

User avatar
normen
Posts: 3431
Joined: 16 Jan 2015

09 Jul 2018

jam-s wrote:
09 Jul 2018
antic604 wrote:
09 Jul 2018
However, for DAW like Reason - with complex routing, modulation, random devices - this might not be as effective as for "linear" DAWs that only keep the REC-armed track "live" and the rest is pre-computed.
As Reason does know about the modulation routing network it can also run this in the background in advance, too (and possibly cache the generated CV modulation as well until something is changed in the modulation node tree).
If you're that far into your composition you can just bounce your parts anyway right? :) I use Reason as a live synth rack so all of this added complexity would rather be annoying for me, I'd probably have to keep Reason from constantly creating some bounces in the background.

ProTools is made like that if you want this though. Does exactly those things like bouncing, loading into memory, preprocessing etc. - because it's workflow is like that. Record notes or audio once, then play back forever with the odd EQ or compressor change. Reason was always meant for something else imo - Reason is about changing the modulation parameter in one device and instantly hearing the change it does, not waiting for a render.

User avatar
jam-s
Posts: 3036
Joined: 17 Apr 2015
Location: Aachen, Germany
Contact:

09 Jul 2018

normen wrote:
09 Jul 2018
ProTools is made like that if you want this though. Does exactly those things like bouncing, loading into memory, preprocessing etc. - because it's workflow is like that. Record notes or audio once, then play back forever with the odd EQ or compressor change. Reason was always meant for something else imo - Reason is about changing the modulation parameter in one device and instantly hearing the change it does, not waiting for a render.
I pretty much agree with you there, still reason could use transparent caching to free some DSP and CPU as usually you don't change all parameters on all devices all the time live. Thus for most controls and audio paths the pre-rendered/cached data is good and can be used. When you start changing any control/param reason can simply switch this pipeline to live rendering while the rest would still be using the cached data (from RAM to keep DSP low).

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

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

User avatar
normen
Posts: 3431
Joined: 16 Jan 2015

09 Jul 2018

MarkTarlton wrote:
09 Jul 2018
However, the single biggest (or narrowest? :) ) bottleneck is usually memory accesses, not raw number crunching power. Also for audio.

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

09 Jul 2018

haha! good one normen :D

I spit out my coffee!

User avatar
mon
Posts: 169
Joined: 07 May 2018
Location: Sofia, Bulgaria

09 Jul 2018

mon wrote:
06 Jul 2018
I have performance issues too. My computer is nothing special by today’s standards but I use other DAWs too with some high quality plugins and I never had such problems with them. In Reason every project is a fight for resources. I don’t use VSTs except one instance of Reference. In almost every project I use only instruments made by Propellerhead. Since I started messing with audio software more than 20 years ago, I developed habits for optimizing my projects to be as easy on the system as possible without sacrificing quality and options... well with Reason 10 it feels almost as difficult as it was with version 1 on my 300MHz Celeron back in 2001. I hope that the guys at Propellerhead are working on the optimization of this otherwise wonderful creative environment.


Sent from my iPad using Tapatalk
I have to report big progress with my case. After monitoring the DPC latencies and trying to eliminate some minor issues without success, i decided to make clean install of Windows 10 (i was with 8.1 at that time). Under Windows 10 Reason started to behave MUCH better. The projects make similar load on the CPU as on Windows 8.1 but the DSP load is very low and i don't experience any hickups and glitches like before. I am one very happy user now :)
:reason: 10+
:recycle: :re: :refillpacker:

User avatar
EnochLight
Moderator
Posts: 8405
Joined: 17 Jan 2015
Location: Imladris

09 Jul 2018

mon wrote:
09 Jul 2018
mon wrote:
06 Jul 2018
I have performance issues too. My computer is nothing special by today’s standards but I use other DAWs too with some high quality plugins and I never had such problems with them. In Reason every project is a fight for resources. I don’t use VSTs except one instance of Reference. In almost every project I use only instruments made by Propellerhead. Since I started messing with audio software more than 20 years ago, I developed habits for optimizing my projects to be as easy on the system as possible without sacrificing quality and options... well with Reason 10 it feels almost as difficult as it was with version 1 on my 300MHz Celeron back in 2001. I hope that the guys at Propellerhead are working on the optimization of this otherwise wonderful creative environment.


Sent from my iPad using Tapatalk
I have to report big progress with my case. After monitoring the DPC latencies and trying to eliminate some minor issues without success, i decided to make clean install of Windows 10 (i was with 8.1 at that time). Under Windows 10 Reason started to behave MUCH better. The projects make similar load on the CPU as on Windows 8.1 but the DSP load is very low and i don't experience any hickups and glitches like before. I am one very happy user now :)
Congrats! Glad to see you got things sorted. Often a buggy OS can definitely mess things up. Freshly reformatting and/or re-installing, while a last resort, can often do wonders!
Win 10 | Ableton Live 11 Suite |  Reason 12 | i7 3770k @ 3.5 Ghz | 16 GB RAM | RME Babyface Pro | Akai MPC Live 2 & Akai Force | Roland System 8, MX1, TB3 | Dreadbox Typhon | Korg Minilogue XD

RandyEspoda
Posts: 275
Joined: 14 Mar 2017

10 Jul 2018

jimmyklane wrote:
08 Jul 2018

Is this why my old i7 2600 (which admittedly is water cooled and seriously OC’ed) has zero problems? I’ll be the first to admit that I use an awful lot of hardware and therefore have far less CPU-loading to worry about, but people here are saying they can’t run 15 instances of Europa which is insane. I can run far more than that at 88.2kHz....and I’m on an old computer. Makes no sense.
Probably, and likely. Because the new cpus with 8+ cores have their cores arranged in a mesh config, some of the cores share their pipelines with the other cores, adding processing time (latency), and driving up cpu usage and DSP in heavy multithreaded applications (probably). 'Coincidentally', only these types of cpus seem to be reporting bad 'multi-core' performance in Reason, all cpus with 6 cores or less seem to be doing very good...

Add in the fact that props haven't yet updated their 'multi-core' functionality to efficiently deal with this new architecture, which causes exactly what Hydlide shows when using just 'one' instance of a device: in stead of using just one core, because multi-core is enabled it pushes the same data to all cores simultaneously, thereby literally duplicating the same workload on every core. It's superficial coding that, IF it is being affected by this architecture change, was sufficient for the older architecture where up to 6 cores are placed on the same die, but now clearly needs to be updated, especially for the upcoming future. I do say 'if' because I'm also not 100% certain that the two are actually related. Fact remains that these 8+ core cpus do have different architecture that affects their 'muticore' performance, and fact remains that reason's multicore feature is outdated, clearly shown when using a single instance of a device with multicore enabled, resulting in all cores receiving the same workload that a single core actually does 100% the same, thus putting WAY more load on the cpu than is actually needed.

Even IF the two are NOT related, then still props need to pay attention to their multi-core feature, and likely adapt their code, add the necessary sub-functionality to 'not' duplicate workloads like that. Make it more efficient.
jimmyklane wrote:
08 Jul 2018
As to the posters that mentioned dual-CPU boards, my first commercial studio ran a dual Opteron configuration and never had a hiccup despite the slower ECC RAM that was required....interesting discussion.
Because in the case of a 'dual' cpu board, both cpus will have their own dedicated cache, pipelines and whatever, having no adverse impact on performance what so ever. In contrast, using an i9 14-core single cpu, it'll have that mesh architecture where not all cores have their own dedicated bla and bla...adversely affecting performance in heavy multi-thread loads...
jimmyklane wrote:
08 Jul 2018
In closing, I feel like people run into problems when using heavy REs or VSTs....is there perhaps flawed logic here? PH instruments have ALWAYS been super light on CPU in my personal experience.
Compared to the VST platform, Reason's proprietary platform certainly is the better one in terms of efficiency, stability and reliability.
No question about it, and no two ways about it. VST has had a (very necessary) development of what, 20 years ? And still it is plagued with performance issues and stability problems that need continuous addressing and improving.
As for popularity, and perhaps quality between the two, VST definitely has the upper hand, but still, imo it is very debatable.

Imo, the issues in Reason with VST, is not because props are 10 years behind but because of the unreliability of the VST platform itself.
VST has needed improvements for years b4 it was even remotely reliable. The platform is at fault, props simply need to clean up 'its' mess in order for it to 'play nice' with a platform that actually 'is' very lean and reliable...they say that oil and water don't mix, and that's what props need to accomplish here. Just an opinion though, and we all have one.

User avatar
aeox
Competition Winner
Posts: 3222
Joined: 23 Feb 2017
Location: Oregon

10 Jul 2018

jimmyklane wrote:
08 Jul 2018

In closing, I feel like people run into problems when using heavy REs or VSTs....is there perhaps flawed logic here? PH instruments have ALWAYS been super light on CPU in my personal experience.
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.

jimmyklane
Posts: 740
Joined: 16 Apr 2018

10 Jul 2018

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

In closing, I feel like people run into problems when using heavy REs or VSTs....is there perhaps flawed logic here? PH instruments have ALWAYS been super light on CPU in my personal experience.
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.
DAW: Reason 12

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

Post Reply
  • Information
  • Who is online

    Users browsing this forum: No registered users and 32 guests