Goodbye Hydlide?

This forum is for anything not Reason related, if you just want to talk about other stuff. Please keep it friendly!
User avatar
rcbuse
RE Developer
Posts: 1175
Joined: 16 Jan 2015
Location: SR388
Contact:

31 Oct 2018

MattiasHG wrote:
31 Oct 2018

Might've mentioned this before, but this is actually not that wacky. We "spin wait" threads so that they're ready for instructions and don't need to be woken up. This is done to make sure everything's super tight, real-time audio is complex and demanding. We do this in all cases, mostly because we expect people to make songs with multiple devices and tracks.
That is very interesting! That would also explain why I can throw a ton more devices in there without any audible issues or changes to that CPU usage.

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

31 Oct 2018

jappe wrote:
31 Oct 2018
antic604 wrote:
31 Oct 2018


Thanks, that's really weird but my question is was it different with Reason 9, 8 or 7?

And if it was better in earlier Reason versions, is it something that Props broke or maybe it's a change in CPU architectures that Props have not programmed for?
That's the problem which makes it so difficult to prove. I don't know if a windows patch, Intel meltdown/spectre patch, drivers or something else causes the non-vst performance problems I experience.
But I experience it on two different windows 10 machines, configured for performance using daw tuning videos.
Computer too slow is very often stopping my work flow these days, and that wasn't a problem for me couple years ago or so.
Scrolling the rack - or even just moving a few-pixel slider makes the DSP meter go up significantly and cause crackles+computer too slow.
If you turn off that horrid CPU usage limit and turn up your buffer size, does that help at all?


My "Default" template for my projects already takes up 2 DSP bars, and I get up to 5 bars pretty quickly but it takes quite a lot after that to get dropouts. If I had the CPU usage limit on I wouldn't be able to do anything in Reason :D

User avatar
Loque
Moderator
Posts: 11175
Joined: 28 Dec 2015

31 Oct 2018

rcbuse wrote:
31 Oct 2018
MattiasHG wrote:
31 Oct 2018

Might've mentioned this before, but this is actually not that wacky. We "spin wait" threads so that they're ready for instructions and don't need to be woken up. This is done to make sure everything's super tight, real-time audio is complex and demanding. We do this in all cases, mostly because we expect people to make songs with multiple devices and tracks.
That is very interesting! That would also explain why I can throw a ton more devices in there without any audible issues or changes to that CPU usage.
That is something i speculated a while back and made some blabla about it...funny thing is: because of Hydlides rant :-D
viewtopic.php?f=4&t=7507685&p=401652&hi ... ce#p401652
Reason12, Win10

User avatar
chimp_spanner
Posts: 2908
Joined: 06 Mar 2015

31 Oct 2018

aeox wrote:
31 Oct 2018
jappe wrote:
31 Oct 2018

That's the problem which makes it so difficult to prove. I don't know if a windows patch, Intel meltdown/spectre patch, drivers or something else causes the non-vst performance problems I experience.
But I experience it on two different windows 10 machines, configured for performance using daw tuning videos.
Computer too slow is very often stopping my work flow these days, and that wasn't a problem for me couple years ago or so.
Scrolling the rack - or even just moving a few-pixel slider makes the DSP meter go up significantly and cause crackles+computer too slow.
If you turn off that horrid CPU usage limit and turn up your buffer size, does that help at all?


My "Default" template for my projects already takes up 2 DSP bars, and I get up to 5 bars pretty quickly but it takes quite a lot after that to get dropouts. If I had the CPU usage limit on I wouldn't be able to do anything in Reason :D
What’s in the template just out of interest?

User avatar
fullforce
Posts: 849
Joined: 18 Aug 2018

31 Oct 2018

MattiasHG wrote:
31 Oct 2018
Might've mentioned this before, but this is actually not that wacky. We "spin wait" threads so that they're ready for instructions and don't need to be woken up.
Wait states. Welcome back to 1991.

Shitty programming.
This is a block of text that can be added to posts you make. There is a 255 character limit.

User avatar
MattiasHG
Reason Studios
Posts: 488
Joined: 16 Jan 2015

31 Oct 2018

fullforce wrote:
31 Oct 2018
MattiasHG wrote:
31 Oct 2018
Might've mentioned this before, but this is actually not that wacky. We "spin wait" threads so that they're ready for instructions and don't need to be woken up.
Wait states. Welcome back to 1991.

Shitty programming.
Thanks! Did you hear this new CD “Nevermind” by Nirvana? It’s radical!

Seriously though, not saying this is good or won’t be changed—I’m no programmer— just trying to explain what you’re seeing when viewing the CPU monitor to avoid confusion. :)

User avatar
Loque
Moderator
Posts: 11175
Joined: 28 Dec 2015

31 Oct 2018

Meeh...i observe this a while now...as soon as someone from Ph is here and answers something, rapidly someone chimes in and tells or asks bs. I never was a member of the PUF, but i get a feeling why it was closed...

Srsly guys...calm down..be objective...be fair...always think, there is a difference between a customer and a company...

Be thankfull that someone from PH is just answering anything here. Do not destroy this. Try to use it to improve Reason, not to rage around. Hdylide did this and he fails hard imo. Guess he had some bad times and i still respect him for his work so i do for PH and most memberes here. They do something for us all. Constructive.
Last edited by Loque on 31 Oct 2018, edited 1 time in total.
Reason12, Win10

User avatar
chimp_spanner
Posts: 2908
Joined: 06 Mar 2015

31 Oct 2018

fullforce wrote:
31 Oct 2018
MattiasHG wrote:
31 Oct 2018
Might've mentioned this before, but this is actually not that wacky. We "spin wait" threads so that they're ready for instructions and don't need to be woken up.
Wait states. Welcome back to 1991.

Shitty programming.
T2: Judgement Day...good year! Still though, no need to be that abrupt. Dude doesn’t have to come here and explain it.

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

31 Oct 2018

chimp_spanner wrote:
31 Oct 2018
aeox wrote:
31 Oct 2018


If you turn off that horrid CPU usage limit and turn up your buffer size, does that help at all?


My "Default" template for my projects already takes up 2 DSP bars, and I get up to 5 bars pretty quickly but it takes quite a lot after that to get dropouts. If I had the CPU usage limit on I wouldn't be able to do anything in Reason :D
What’s in the template just out of interest?
Looking for details?

User avatar
Catblack
Posts: 1020
Joined: 15 Apr 2016
Contact:

31 Oct 2018

MattiasHG wrote:
31 Oct 2018
fullforce wrote:
31 Oct 2018


Wait states. Welcome back to 1991.

Shitty programming.
Thanks! Did you hear this new CD “Nevermind” by Nirvana? It’s radical!

Seriously though, not saying this is good or won’t be changed—I’m no programmer— just trying to explain what you’re seeing when viewing the CPU monitor to avoid confusion. :)
Thanks Mattias for chiming in and giving us a little clarity.
If you ain't hip to the rare Housequake, shut up already.

Damn.

User avatar
Heigen5
Posts: 1505
Joined: 25 Sep 2018
Location: Finland / Suomi

31 Oct 2018

Does anyone know that why a newly loaded song can say, "computer too slow message"?
I mean it would make sense that it would say that only when you pess play..

User avatar
Loque
Moderator
Posts: 11175
Joined: 28 Dec 2015

31 Oct 2018

Heigen5 wrote:
31 Oct 2018
Does anyone know that why a newly loaded song can say, "computer too slow message"?
I mean it would make sense that it would say that only when you pess play..
I noticed some devices that have high CPU peaks while loading. Thats why i disabled that warnings since years. Note, that there is always a core rserved for GUI interaction and everyone today has a 4+ core system, which makes this warning kind of useless. I disiabled it, push my system to the limits all the time and never had any problems.
Reason12, Win10

User avatar
Heigen5
Posts: 1505
Joined: 25 Sep 2018
Location: Finland / Suomi

31 Oct 2018

Loque wrote:
31 Oct 2018
Heigen5 wrote:
31 Oct 2018
Does anyone know that why a newly loaded song can say, "computer too slow message"?
I mean it would make sense that it would say that only when you pess play..
I noticed some devices that have high CPU peaks while loading. Thats why i disabled that warnings since years. Note, that there is always a core rserved for GUI interaction and everyone today has a 4+ core system, which makes this warning kind of useless. I disiabled it, push my system to the limits all the time and never had any problems.
I only said this because, what I said in my "why Reason isn't in idle mode" when no audio is happening per the tracks - thread.

User avatar
jappe
Moderator
Posts: 2437
Joined: 19 Jan 2015

31 Oct 2018

aeox wrote:
31 Oct 2018
jappe wrote:
31 Oct 2018

That's the problem which makes it so difficult to prove. I don't know if a windows patch, Intel meltdown/spectre patch, drivers or something else causes the non-vst performance problems I experience.
But I experience it on two different windows 10 machines, configured for performance using daw tuning videos.
Computer too slow is very often stopping my work flow these days, and that wasn't a problem for me couple years ago or so.
Scrolling the rack - or even just moving a few-pixel slider makes the DSP meter go up significantly and cause crackles+computer too slow.
If you turn off that horrid CPU usage limit and turn up your buffer size, does that help at all?


My "Default" template for my projects already takes up 2 DSP bars, and I get up to 5 bars pretty quickly but it takes quite a lot after that to get dropouts. If I had the CPU usage limit on I wouldn't be able to do anything in Reason :D
I already have it at 95% threshold, and I get crackles even when DSP meter isn't yet red.
Perhaps a problem could be that the DSP meter "calibration" is a bit off on some systems/CPU:s?

This weekend is reserved for troubleshooting, I'll share any findings.

User avatar
Wobbleburger
Posts: 260
Joined: 14 Sep 2018
Location: Austin
Contact:

31 Oct 2018

chimp_spanner wrote:
31 Oct 2018
I think there's a really interesting discussion to be had off the back of this, about how we approach modern music making and what our expectations are. I mean, I'm setting aside people who really do have legit technical/performance complaints. That's another thing entirely. And I'd never suggest that we settle for a sub par product just because things are better now than they used to be but...Reason is still wizardry to me. I started making music in the 90s, with General MIDI on an Atari. Sound design was playing it lower/higher. And I grew up watching my parents using pots and pans for percussion, carving notches into a metronome for a guiro, literally splicing tape with a razor blade. Dad's first sampler was an S900; 63 seconds of total recording time at 7.5khz! I don't even know what they would've done with ONE Serum. And here we are trying to load multiples of ten! ;)

I get it, it's 2018. Things are different. And trust me, I have a wish list at least as long as my forearm. But I think the appeal of Reason, for me, has been that nod to the old way of doing it. And I try to let that guide me in my sound and effect choices. Firstly because it's just easier on my eyes/brain, secondly because it's easier on my laptop, and thirdly because - to use a VERY worn out cliche - less is more. It took me ages to realise that most of the songs I loved were actually really simple. I mean try it; listen to your top 10 favourite songs and really focus on how much is going on at any one time, and what it is about that song that makes it special to you. I can't imagine it's anything that can't be done in Reason, even without the optimisation update.

Performance is important. But it's kind of sad to see so much of the conversation right now dominated by "Reason Performance", like the thing that's holding anyone back is being able to load in another 10 Europas. More synths, more problems ;)

Just realised what an old man I sound like. I'm only 34! I *am* wearing slippers and a gown though...Anyway, again, I'm not invalidating any legitimate complaints and I wanna see Reason grow and improve just as much as anyone else. But I do think it's worth getting some perspective. It's a wonderfully unique, fun and creative DAW. And I'm a filthy fanboy. #noshame
Really well said. I definitely appreciate this. You can't dress up a bad song with more crap. But a good melody (even played on a stock piano patch) sounds good. I blame it on whatever Dubstep mutated into after it came to America. :D
In the 90s, my midi music was on the Baulder's Gate site. That was my life peak.
Reasonite since 2000. My music (and my old midi) can be found here:
https://futurewizard.org

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

31 Oct 2018

guitfnky wrote:
31 Oct 2018
I know it’s sort of irrelevant to where we stand *now*, but honestly, in another 5-10 years or so, I suspect most moderately-powered systems will be able to handle about anything you throw at them.
I remember thinking this 5-10 years ago, and yet - here I am - with my almost 7 year old CPU, and things are getting pretty long in the tooth. The thing about CPU's and software is that: the faster the hardware gets, the more stress developers put in the software. It's all proportional, it would seem.

That said, I can start Reason 1.0 on my current machine, and it goes from double clicking the desktop shortcut to "ready" in about 1.5 seconds. :lol: So come 5-10 years from now (or 15 years from now), I'm sure Reason 10.x will start in about 1.5 seconds on hardware sold in 2028-2033.

Ugh... it's weird to even type those dates. :lol: :lol: :lol:
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

antic604

31 Oct 2018

MattiasHG wrote:
31 Oct 2018
Makes sense? I've said this before but the CPU meter, despite it's name, is not a great way to measure performance. The absolute best way to understand when performance is "bad" is when it impacts the sound of your song (i.e. dropouts, crackles and pops) or the rendering of graphics.
But you can clearly hear in the video (2nd part) that his audio started breaking up and DSP meter was shooting up into red.

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

31 Oct 2018

antic604 wrote:
31 Oct 2018
But you can clearly hear in the video (2nd part) that his audio started breaking up and DSP meter was shooting up into red.
Wasn't that the 3rd part (when he turned on Hyperthreading)? When he ticked the "use multicore audio" box in the 2nd part, the audio played back fine.
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
ast3rix
Posts: 85
Joined: 05 Aug 2018
Contact:

31 Oct 2018

chimp_spanner wrote:
31 Oct 2018
Undistraction wrote:
31 Oct 2018

So you're not trying to improve performance outside of VSTs, and any improvement will be a happy bi-product of that? Guess that means we won't be getting Freeze. So can we expect another patch after this one that improves general Reason performance?
Freeze was never on the cards as far as I know. It was always just about improving Vst performance. Anything else will come in .5 or 11 or whatever!
I was under the assumption it was an overall performance patch which included vst. Yeah my fears surrounding this are warranted. I guess I will go ahead and commit to Ableton fully. I think I’ve waited long enough, but I’m glad they are being open about it so we know what to expect. This feels like a divorce... I loved you for sooo long and now we just can’t seem to get it together.

antic604

31 Oct 2018

EnochLight wrote:
31 Oct 2018
antic604 wrote:
31 Oct 2018
But you can clearly hear in the video (2nd part) that his audio started breaking up and DSP meter was shooting up into red.
Wasn't that the 3rd part (when he turned on Hyperthreading)? When he ticked the "use multicore audio" box in the 2nd part, the audio played back fine.
Technically 3rd part is in 2nd half, but you're right :)

Breach The Sky
Posts: 212
Joined: 14 Jul 2015
Location: Sweden

31 Oct 2018

I can't have hyperthreading on, it totally destroys my performance. Multicore on is much better then off tough. I wonder why that is? I'm not exactly well versed in thread allocation techniques...

VariableX
Posts: 564
Joined: 02 Apr 2018

31 Oct 2018

Loque wrote:
31 Oct 2018
Meeh...i observe this a while now...as soon as someone from Ph is here and answers something, rapidly someone chimes in and tells or asks bs. I never was a member of the PUF, but i get a feeling why it was closed...

Srsly guys...calm down..be objective...be fair...always think, there is a difference between a customer and a company...

Be thankfull that someone from PH is just answering anything here. Do not destroy this. Try to use it to improve Reason, not to rage around. Hdylide did this and he fails hard imo. Guess he had some bad times and i still respect him for his work so i do for PH and most memberes here. They do something for us all. Constructive.
This 100%, well said!
I get the feeling some people on here don't even use Reason and are fanboys of other DAWs and are just trying to be disruptive!

User avatar
6502
Posts: 147
Joined: 18 Nov 2015

31 Oct 2018

fullforce wrote:
31 Oct 2018
MattiasHG wrote:
31 Oct 2018
Might've mentioned this before, but this is actually not that wacky. We "spin wait" threads so that they're ready for instructions and don't need to be woken up.
Wait states. Welcome back to 1991.

Shitty programming.
A wait state is not the same thing as a spin lock, as far as I am aware. A wait state is when a fast CPU waits for slow RAM, for example.

Spin locks are a legitimate way of reducing latency that would be caused by waking up threads.

Are they the best way? I don't know - but I wouldn't necessarily call it <expletive deleted> programming from 1991.

So are you a professional programmer working in applications that require low latency? I would really appreciate any insights into how you've solved these types of thorny problems in the past. I am always looking to expand my knowledge...

User avatar
Blamsoft
RE Developer
Posts: 100
Joined: 16 Jan 2015

31 Oct 2018

Cultor wrote:
29 Oct 2018
EnochLight wrote:
29 Oct 2018
Man. My 8 year old 4-core i7 2600 doesn't even push a bar - maybe 2 - with VK-2 poly patches.
Do you by any chance own the Polymodular System ?
If you do curious what happends when you try the "Epic Plucker" Preset.
Factory bank can be downloaded here: http://blamsoft.com/rack-extensions/polymodular-system/

That preset alone absolutely destroys my CPU i7- 6700k
It turns out that Epic Plucker has the F-16 filter quality on setting 2. This setting is more useful for getting a warm tone on a stereo pair. It generally shouldn't be used in a polyphonic patch.

Regarding VK-2, the filter Algo, and two CPU switches on the back are obvious causes. A less obvious cause is the envelope curve knob. When curve is turned up it can cause voices to stay on longer.
Last edited by Blamsoft on 31 Oct 2018, edited 1 time in total.

User avatar
Adabler
Competition Winner
Posts: 496
Joined: 05 Oct 2017
Location: Oslo

31 Oct 2018

Blamsoft wrote:
31 Oct 2018
It turns out that Epic Plucker has the F-16 filter quality on setting 2. This setting is more useful for getting a warm tone on a stereo pair. It generally shouldn't be used in a polyphonic patch.
Regarding VK-2, the filter Algo, and two CPU switches on the back are obvious causes. A less obvious cause is the envelope curve knob. When curve is turned up it can cause voices to stay on longer.
Don't trust this guy. He is obviously a terminator.
:reason: 12, Win10

Post Reply
  • Information