Reason 9.5.2 is now available!

This forum is for discussing Reason. Questions, answers, ideas, and opinions... all apply.
User avatar
PelTek
Posts: 10
Joined: 08 May 2017
Location: Greece

23 Sep 2017

jappe wrote:
23 Sep 2017
PelTek wrote:
22 Sep 2017
None of the bugs I reported since beta are fixed, great!!
Hello PelTek,
curious what bugs you refer to?
Well the one has to do with multi out and bypass and the other one has to do with minimizing vst window and not being able to drag and drop from browser.

KevTav
Posts: 331
Joined: 12 Jun 2016

23 Sep 2017

MattiasHG wrote:
22 Sep 2017
You're probably all busy with Reason 10, but we just released Reason 9.5.2—a free maintenance update for Reason 9.5. I thought you should know. :geek:

Here's what's new:
  • Reason 9.5.2 and Reason Essentials 9.5.2 are now compatible with macOS High Sierra
  • Improved file system handling
  • (Mac) Moved location of cache files for plugin screenshots, plugin registry and more
  • Improved plugin window focus handling on Windows, removed associated menu option
  • Fixed an issue with time signatures when importing MIDI
  • Fixed an issue that would cause Maschine to not play the first note in the sequencer
  • Fixed an issue where a VST GUI could sometimes disappear
  • Optimized reading of Remote map files
  • Made plugin window open button remotable, "Proxy Open Plugin Window"

"And we threw in 100 new drum Combinators, and some free Synth Instruments, and...and."

:thumbs_up: :thumbs_up: :thumbs_up: :thumbs_up:

No?
Yamaha DGX-650 (Controller) - Komplete Audio Interface - Asus GR8 2 - Intel Core i7-7700 3.60 GHz - 16GB RAM - Audio Technica ATH M50x - Yamaha HS 80Ms - Reason 10 - Izotope - Cubase - Pro Tools - Ableton - Epiphones - Taylors - SH*TLOAD of Plug-Ins

User avatar
Oquasec
Posts: 2849
Joined: 05 Mar 2017

23 Sep 2017

Each combinator is basically the same thing as another vst.
then they made 2 new sound generators.
Producer/Programmer.
Reason, FLS and Cubase NFR user.

Ad0
Posts: 101
Joined: 13 Jun 2017

23 Sep 2017

Gorgon wrote:
22 Sep 2017
MattiasHG wrote:
22 Sep 2017
And an important thing to understand about hyper threading: Hyper threading works by distributing load better. However, the way audio processing and Reason works when you put multiple devices in one chain (for example as insert fx or create one monster combinator) they are all processed together as one unit since all things must happen before they can render.
That's really shitty programming if you ask me. That is not why multicore was invented.Real multicore processing should distribute the load of any given millisecond to all the cores. The way you have it now is that some cores have to wait on others for rendering. This is very similar to "wait states" which were a thing back in the 90's with the 386/486 processors.
It's not that simple. Logic does the same thing as well. The whole chain has to run on the same core, because overhead with syncing threads etc to do things sequentially (as you have to do with a signal) would outweigh the benefit of distributing the processing across cores. So what is basically done is that you can divide stuff across cores that goes to their own mixer channel.

And routing in Reason can get really complicated, so if you interconnect everything I bet they will be slammed into one core.
To get the best performance I would guess that you would have instrument -> as few effects as possible -> Track, and when the core is nearing 100%, the chain from instrument to track will be moved to another core (affinity).

As a programmer myself I know the challenges involved. If you spawn a bunch of threads to process every single thing in an FX chain, they all have to wait for eachother anyway. a -> b -> c : b needs to know what a did, c needs to know what b did. So there is no gain in more threads, just overhead. So the only thing you can do is at the end point (mixer channel). Then the worker threads processing on each channel can just wait for all of them to complete and then sum them. It gets even more complicated if you have sidechaining etc.

Check out "Logic Pro/Express: Tips for balancing multi-core performance" https://support.apple.com/en-us/HT201838

User avatar
FlowerSoldier
Posts: 470
Joined: 03 Jun 2016

23 Sep 2017

Wow. Super insightful post @Ad0.
Thanks.

per-anders
Posts: 224
Joined: 09 Jul 2015

24 Sep 2017

Gorgon wrote:
22 Sep 2017
MattiasHG wrote:
22 Sep 2017
And an important thing to understand about hyper threading: Hyper threading works by distributing load better. However, the way audio processing and Reason works when you put multiple devices in one chain (for example as insert fx or create one monster combinator) they are all processed together as one unit since all things must happen before they can render.
That's really shitty programming if you ask me. That is not why multicore was invented.Real multicore processing should distribute the load of any given millisecond to all the cores. The way you have it now is that some cores have to wait on others for rendering. This is very similar to "wait states" which were a thing back in the 90's with the 386/486 processors.
Well that’s what the OS scheduler is for. But that’s not always a good thing, too much shifting between cores is very inefficient adding overhead, often the OS scheduler is something your wanting to work against in order to get maximum value out of your CPU cycles.

There are basically two main methods of multithreading stuff - you split up your data and run it through the same program in little blocks on each separate core or you split up the program and run different functions in each core, this is what Reason is apparently doing.

Splitting up data is very very efficient for dealing with lots of data, big image files etc, but it’s limited because each core works in its own data it’s not aware of the data the other cores are working on which means you need a distributor and collector which is single threaded to handle any function that needs to work on the whole dataset. In audio that’s stuff like convolution. It also requires each plugin to be coded in a special way to handle this.

Splitting things up by code is in some ways easier, for example you have two tracks in Reason, each has its own plugins. You compute the first tracks output on one core and the next tracks output on the second core. You mix the results back on you first core. Theoretically this just halved your computation time, and the plugins are nine the wiser. But it’s not as simple as that. There may be many more effects on the first track which would mean it takes a lot longer to compute the second track and so that second core is doing nothing for most of the time. A plugin may not be written to understand that it operates in a multithreaded environment and could cause race situations (crashes when two instances try to access the same portion of memory for read/write). Something may try to access volatile memory or bus and that means that and other threads get threadlocked due to it being a single processing operation etc.

Having your own scheduler, controlling things can dramatically improve efficiency. You don’t want to go opening and closing threads too often as it’s slow, you also don’t want to have more threads than cores for a specific task because that relinquishes some control over what core does what job to the OS scheduler, every time there’s a stop or sleep it’ll switch around, copying caches, wasting time. You want to open as many threads as there are cores, set their affinity and then reuse them for your MP tasks. Every time there’s a spider audio merger/splitter you want to deal with the audio paths in their own distributed jobs in this setup to try and break down the code into small chunks to spread things across the cores.

There’s a balance to be had with MT, too small blocks and things cease to be efficient, it costs more to launch than the execute per core. Too big blocks and it’s too large to fit in the processor cache and you get cache misses and worse as it has to load stuff from RAM which is slow. It’s not trivial stuff, and there are many pitfalls and stuff that seems obvious and common sense can be very wrong.

User avatar
Oquasec
Posts: 2849
Joined: 05 Mar 2017

24 Sep 2017

Reason lets you use numbered versions alongside each other. You need to replace a version with a different build of that one version you have problems with.
Producer/Programmer.
Reason, FLS and Cubase NFR user.

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

24 Sep 2017

per-anders wrote:
24 Sep 2017


Well that’se OS scheduler is for. But that’s not always a good thing, too much shifting between cores is very inefficient adding overhead, often the OS scheduler is something your wanting to work against in order to get maximum value out of your CPU cycles.

There are basically two main methods of multithreading stuff - you split up your data and run it through the same program in little blocks on each separate core or you split up the program and run different functions in each core, this is what Reason is apparently doing.

Splitting up data is very very efficient for dealing with lots of data, big image files etc, but it’s limited because each core works in its own data it’s not aware of the data the other cores are working on which means you need a distributor and collector which is single threaded to handle any function that needs to work on the whole dataset. In audio that’s stuff like convolution. It also requires each plugin to be coded in a special way to handle this.
I wonder if polyphony is implemented by (optionally) allocating a core to a mono note line?

And about implementing split data or split functionality multithreaded...it could use both dynamically, depending on what the engine decides is most opportunistic for each load balancing decision?

avasopht
Competition Winner
Posts: 3932
Joined: 16 Jan 2015

24 Sep 2017

Gorgon wrote:
22 Sep 2017
MattiasHG wrote:
22 Sep 2017
And an important thing to understand about hyper threading: Hyper threading works by distributing load better. However, the way audio processing and Reason works when you put multiple devices in one chain (for example as insert fx or create one monster combinator) they are all processed together as one unit since all things must happen before they can render.
That's really shitty programming if you ask me. That is not why multicore was invented.Real multicore processing should distribute the load of any given millisecond to all the cores. The way you have it now is that some cores have to wait on others for rendering. This is very similar to "wait states" which were a thing back in the 90's with the 386/486 processors.
This is very incorrect

No amount of programming can improve on this. When you have a CHAIN, it is infinitely impossible to process them in parallel because one must be processed before the next. Hyperthreading cannot do a thing about it either.

A single thread isn't magically distributed among cores, and tasks that are not parallelizable cannot be split among cores. Plus there are costs when this is done anyway that might be counterproductive to ultra low latency audio processing.

User avatar
normen
Posts: 3431
Joined: 16 Jan 2015

24 Sep 2017

jappe wrote:
24 Sep 2017
I wonder if polyphony is implemented by (optionally) allocating a core to a mono note line?

And about implementing split data or split functionality multithreaded...it could use both dynamically, depending on what the engine decides is most opportunistic for each load balancing decision?
These decisions are already made. As I and others outlined Reason can only divide up single plugin processes. If the plugins then use MT to do their computations is left to the developer of the plugin. Sometimes it can make sense (as in your polyphony example - with caveats) and sometimes the single-threaded approach is simply the only or at least the better choice.

Edit: But lets be honest, at least for a while we'll always have more tracks than cores, right? So theres no issue either way.

User avatar
normen
Posts: 3431
Joined: 16 Jan 2015

24 Sep 2017

I also don't see any issue with how Reason handles threads or multithreading. If there were issues with scheduling, locks or any of the other smart terms thrown around here we'd notice instantly when moving to a multi core system (or toggling MT in the prefs).

We are talking about low latency processing here. Something that modern computers aren't really made for, they are made for overall throughput. Thats why we have a DSP meter and not a CPU meter in our software. Theres enough people around here that are crazy enough to run their systems at 64 samples (just kidding, if it works it works) - if there was just minute issues with the MT per se that would blow up instantly.

On top of that it's really not magic. I can't think of any framework where MT really is an issue, no matter what approach you chose and this is not exactly a complicated case for threading.

As for VST plugins, their main processing code get executed on some thread that is managed by Reason alright. But like in any other host they then do their thing - including threading - like in any other host. You have to see that VSTs are basically normal applications, Reason is not "between" them and the system, it only gets data from them. And Reason can't create "magic performance degrading threads" either, it creates threads like any other application, probably it even gets threads from the various OSs through some kind of platform independent library -- like any other DAW :)

But Reason running all plugins at 64 samples can create overhead, depending on what the plugin does.

User avatar
QVprod
Moderator
Posts: 3488
Joined: 15 Jan 2015
Contact:

24 Sep 2017

Spyderfyre wrote:
23 Sep 2017
Does anyone know if this update adds support for more than 4 cores?
Reason has supported multiple physical cores for quite some time now. I believe the confusion comes down to virtual cores and the fact that Rewire only runs on I believe 1 core. I stand to be corrected if I'm wrong though. My computer knowledge only goes as far as my personal needs require it to.

per-anders
Posts: 224
Joined: 09 Jul 2015

24 Sep 2017

There are very real problems when it scales negatively. The function of MP is to speed things up, not slow things down.

It's a misconception that multithreading automatically results in improved processing. It's also a misconception that high processor usage indicates effective multithreading.

The effect of MT on latency is of course that the less time the computer spends processing both audio and UI before output the smaller the buffer you require in order to maintain a constant stream without dropouts. Therefore highly efficient and well threaded code is likely to result in a lower required buffer size which in turn results in a lower roundtrip latency. But that's the sum total. The eventual output is to a serial port so of course it's single threaded output.

Look it's entirely possible that the negative scaling is down to a third party, down to plugins not behaving well when implemented in an MP environment. It is however notable that other DAW's do not seem to have these same issues (or at least don't suffer them as badly). The concept behind Reason isn't inherently limited when it comes to multithreading, there are many scholarly articles on efficient multithreading of dependency graphs.

Of course the only reason MT even is an issue is because Reason's performance overall is notably slower than the competition these days, which is a complete reversal of how things used to be, and that could be resolved without even utilizing MT if Reason were to handle caching better (Freezing and UnFreezing automatically for those used to audio terms), and of course introduce layers/grouping (although busing would still allow significant performance gains in a well architected system).

User avatar
normen
Posts: 3431
Joined: 16 Jan 2015

25 Sep 2017

Meh, that again. Let me translate what you just said:

„Multithreading is for making things fast. Heres two random misconceptions nobody in this thread had. If you compute with two processors you compute faster. Some plugins might have issues with multithreading. Multithreading in Reason might improve performance, I don‘t know. Reason is slower than all other DAWs and should freeze automatically.“

See, I still don‘t see any indication for the actual issue people are talking about being real. You CAN put high load on all your CPUs with Reason which is proof alone that the MT works. The „oh so problematic“ UAD issues are down to the buffer size, not any magic performance or threading issues. The plugins that cause issues simply don‘t support low buffer sizes. Nobody showed any evidence for anything else.

If you feel like you have to respond with „yes there is issues“ I ask you to explain it in laymans terms then, not fire a smoke screen of hollow words. Also note that I don't feel like we're talking against each other. I am talking about what we can see and you are talking about what the Props should do - thats two completely different things.

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

25 Sep 2017

per-anders wrote:
24 Sep 2017
There are very real problems when it scales negatively. The function of MP is to speed things up, not slow things down.

It's a misconception that multithreading automatically results in improved processing. It's also a misconception that high processor usage indicates effective multithreading.

The effect of MT on latency is of course that the less time the computer spends processing both audio and UI before output the smaller the buffer you require in order to maintain a constant stream without dropouts. Therefore highly efficient and well threaded code is likely to result in a lower required buffer size which in turn results in a lower roundtrip latency. But that's the sum total. The eventual output is to a serial port so of course it's single threaded output.

Look it's entirely possible that the negative scaling is down to a third party, down to plugins not behaving well when implemented in an MP environment. It is however notable that other DAW's do not seem to have these same issues (or at least don't suffer them as badly). The concept behind Reason isn't inherently limited when it comes to multithreading, there are many scholarly articles on efficient multithreading of dependency graphs.

Of course the only reason MT even is an issue is because Reason's performance overall is notably slower than the competition these days, which is a complete reversal of how things used to be, and that could be resolved without even utilizing MT if Reason were to handle caching better (Freezing and UnFreezing automatically for those used to audio terms), and of course introduce layers/grouping (although busing would still allow significant performance gains in a well architected system).
I am not sure where to start to tell you where you are wrong in your assumptions on multi processing...
1. MP requires a CPU, that can for real process in parallel. The early core and HT CPUs could not, they kind of simulated it. Due to they shared the same ressources, they core could block each other
2. Also today point 1 occurs, related to resources.
3. MT requires even like MP synchronization, which requires the CPU to get into a serial mode or in a special mode, where it can synchronizes its cores. Synchronizing is slow, very CPU intensive. Also the OS has a high load to switch process and threads. That may be a reason to keep a thread in front (always working). Please also note, MT is simulating MP on one core, and therefor you can handle only calculation. Some CPUs may have tricks, to handle parallel code in pipelines of multiple threads, as long as they dont access ressources
4. In fact that means, introducing synchronization introduces an overhead, and therefore reduces the overall performance. Enabling 2 algorthims on one core, could make it slower or blocking more, and may reduce throughput of a single algorithm
5. if you have a short time delay, where all your calculations must be done (realtime processing), you lose overall performance in that cycle for the synchronization, more threads may have a bad impact on the performance too
6. Now, i dont know much about the SDK and if it allows MT or MP. I agree, it should be possible by a RE to use 3 cores for its 3 oscilator pipelines. But in the end, this would block 3 cores for other RE. And scheduling in this case can only be done by Reason itself, or must be switchable (i remember VSTs have that option). PH seem to make the scheduling on a high level, like creating the jobs to be done in a cycle, putting them in a queue and the cores getting them. Same for MT, maybe just different special jobs, that do not block resources too much. So in the end, in Reason, a MT/MP controlled from RE doesnt make sense
7. To the overall performance, i think Reason could be better. Poor performance may be related to architecture, algorithmic or weak programming. All can be addressed, but are expensive to investigate, to redesign, refactor, rewrite, retest. So, imo, this needs and this can be improved and i hope/expect PH will do something here. But dont forget, that Reason has some special things, like its constantly generators like Oscilators or LFOs. Maybe you ever noticed, that if nothing runs, a LFO still produces signals. Also you may noticed, the isolation of each RE. This is expensive to resources. PH said, they didnt isolated them as much as RE, so they can perform better. And they still perform quite bad. Here may come deeper problems in Reason i can only speculate about.

To make it short: Please respect MP coding knowledge, you need to have all information from context, resource, environment and so on. It is a very complex topic. To say, i have 10 cores, everything is now 10 times faster is just wrong.
Reason12, Win10

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

25 Sep 2017

Loque wrote:
25 Sep 2017
per-anders wrote:
24 Sep 2017
There are very real problems when it scales negatively. The function of MP is to speed things up, not slow things down.

It's a misconception that multithreading automatically results in improved processing. It's also a misconception that high processor usage indicates effective multithreading.

The effect of MT on latency is of course that the less time the computer spends processing both audio and UI before output the smaller the buffer you require in order to maintain a constant stream without dropouts. Therefore highly efficient and well threaded code is likely to result in a lower required buffer size which in turn results in a lower roundtrip latency. But that's the sum total. The eventual output is to a serial port so of course it's single threaded output.

Look it's entirely possible that the negative scaling is down to a third party, down to plugins not behaving well when implemented in an MP environment. It is however notable that other DAW's do not seem to have these same issues (or at least don't suffer them as badly). The concept behind Reason isn't inherently limited when it comes to multithreading, there are many scholarly articles on efficient multithreading of dependency graphs.

Of course the only reason MT even is an issue is because Reason's performance overall is notably slower than the competition these days, which is a complete reversal of how things used to be, and that could be resolved without even utilizing MT if Reason were to handle caching better (Freezing and UnFreezing automatically for those used to audio terms), and of course introduce layers/grouping (although busing would still allow significant performance gains in a well architected system).
I am not sure where to start to tell you where you are wrong in your assumptions on multi processing...
1. MP requires a CPU, that can for real process in parallel. The early core and HT CPUs could not, they kind of simulated it. Due to they shared the same ressources, they core could block each other
2. Also today point 1 occurs, related to resources.
3. MT requires even like MP synchronization, which requires the CPU to get into a serial mode or in a special mode, where it can synchronizes its cores. Synchronizing is slow, very CPU intensive. Also the OS has a high load to switch process and threads. That may be a reason to keep a thread in front (always working). Please also note, MT is simulating MP on one core, and therefor you can handle only calculation. Some CPUs may have tricks, to handle parallel code in pipelines of multiple threads, as long as they dont access ressources
4. In fact that means, introducing synchronization introduces an overhead, and therefore reduces the overall performance. Enabling 2 algorthims on one core, could make it slower or blocking more, and may reduce throughput of a single algorithm
5. if you have a short time delay, where all your calculations must be done (realtime processing), you lose overall performance in that cycle for the synchronization, more threads may have a bad impact on the performance too
6. Now, i dont know much about the SDK and if it allows MT or MP. I agree, it should be possible by a RE to use 3 cores for its 3 oscilator pipelines. But in the end, this would block 3 cores for other RE. And scheduling in this case can only be done by Reason itself, or must be switchable (i remember VSTs have that option). PH seem to make the scheduling on a high level, like creating the jobs to be done in a cycle, putting them in a queue and the cores getting them. Same for MT, maybe just different special jobs, that do not block resources too much. So in the end, in Reason, a MT/MP controlled from RE doesnt make sense
7. Mixing in the topic "caching" is a completely different book
8. To the overall performance, i think Reason could be better. Poor performance may be related to architecture, algorithmic or weak programming. All can be addressed, but are expensive to investigate, to redesign, refactor, rewrite, retest. So, imo, this needs and this can be improved and i hope/expect PH will do something here. But dont forget, that Reason has some special things, like its constantly generators like Oscilators or LFOs. Maybe you ever noticed, that if nothing runs, a LFO still produces signals. Also you may noticed, the isolation of each RE. This is expensive to resources. PH said, they didnt isolated them as much as RE, so they can perform better. And they still perform quite bad. Here may come deeper problems in Reason i can only speculate about.

To make it short: Please respect MP coding knowledge, you need to have all information from context, resource, environment and so on. It is a very complex topic. To say, i have 10 cores, everything is now 10 times faster is just wrong.
Reason12, Win10

per-anders
Posts: 224
Joined: 09 Jul 2015

25 Sep 2017

Loque wrote:
25 Sep 2017
per-anders wrote:
24 Sep 2017
There are very real problems when it scales negatively. The function of MP is to speed things up, not slow things down.

It's a misconception that multithreading automatically results in improved processing. It's also a misconception that high processor usage indicates effective multithreading.

The effect of MT on latency is of course that the less time the computer spends processing both audio and UI before output the smaller the buffer you require in order to maintain a constant stream without dropouts. Therefore highly efficient and well threaded code is likely to result in a lower required buffer size which in turn results in a lower roundtrip latency. But that's the sum total. The eventual output is to a serial port so of course it's single threaded output.

Look it's entirely possible that the negative scaling is down to a third party, down to plugins not behaving well when implemented in an MP environment. It is however notable that other DAW's do not seem to have these same issues (or at least don't suffer them as badly). The concept behind Reason isn't inherently limited when it comes to multithreading, there are many scholarly articles on efficient multithreading of dependency graphs.

Of course the only reason MT even is an issue is because Reason's performance overall is notably slower than the competition these days, which is a complete reversal of how things used to be, and that could be resolved without even utilizing MT if Reason were to handle caching better (Freezing and UnFreezing automatically for those used to audio terms), and of course introduce layers/grouping (although busing would still allow significant performance gains in a well architected system).
I am not sure where to start to tell you where you are wrong in your assumptions on multi processing...
1. MP requires a CPU, that can for real process in parallel. The early core and HT CPUs could not, they kind of simulated it. Due to they shared the same ressources, they core could block each other
2. Also today point 1 occurs, related to resources.
3. MT requires even like MP synchronization, which requires the CPU to get into a serial mode or in a special mode, where it can synchronizes its cores. Synchronizing is slow, very CPU intensive. Also the OS has a high load to switch process and threads. That may be a reason to keep a thread in front (always working). Please also note, MT is simulating MP on one core, and therefor you can handle only calculation. Some CPUs may have tricks, to handle parallel code in pipelines of multiple threads, as long as they dont access ressources
4. In fact that means, introducing synchronization introduces an overhead, and therefore reduces the overall performance. Enabling 2 algorthims on one core, could make it slower or blocking more, and may reduce throughput of a single algorithm
5. if you have a short time delay, where all your calculations must be done (realtime processing), you lose overall performance in that cycle for the synchronization, more threads may have a bad impact on the performance too
6. Now, i dont know much about the SDK and if it allows MT or MP. I agree, it should be possible by a RE to use 3 cores for its 3 oscilator pipelines. But in the end, this would block 3 cores for other RE. And scheduling in this case can only be done by Reason itself, or must be switchable (i remember VSTs have that option). PH seem to make the scheduling on a high level, like creating the jobs to be done in a cycle, putting them in a queue and the cores getting them. Same for MT, maybe just different special jobs, that do not block resources too much. So in the end, in Reason, a MT/MP controlled from RE doesnt make sense
7. To the overall performance, i think Reason could be better. Poor performance may be related to architecture, algorithmic or weak programming. All can be addressed, but are expensive to investigate, to redesign, refactor, rewrite, retest. So, imo, this needs and this can be improved and i hope/expect PH will do something here. But dont forget, that Reason has some special things, like its constantly generators like Oscilators or LFOs. Maybe you ever noticed, that if nothing runs, a LFO still produces signals. Also you may noticed, the isolation of each RE. This is expensive to resources. PH said, they didnt isolated them as much as RE, so they can perform better. And they still perform quite bad. Here may come deeper problems in Reason i can only speculate about.

To make it short: Please respect MP coding knowledge, you need to have all information from context, resource, environment and so on. It is a very complex topic. To say, i have 10 cores, everything is now 10 times faster is just wrong.
1 - Are we talking about old CPUs now? The OS thread scheduler can block any core it wants, the purpose of threading is sandboxing and preemptive multitasking at the OS level.
2 - I understand HT if that’s what you’re getting at though I’m not sure what it has got to do with anything I stated in the post you quoted.
3 - I don’t think you understand what thread synchronization is or how it’s done.
4 - Yes and?
5 - Again, and?
6 - OK. I’m confused. What were you reading in my post? I never talked about discretizing individual sub routines within a plugin such as oscillators. I agree there would be no advantage in doing that from a MT context.
7 - Yes there can be many reasons for poor overall performance. But negative scaling is specifically a MT issue. I doubt things like Oscillators are the problem, just because they are time based doesn’t mean they need be constantly calculated, they are a function that takes a time input and gives a value output, whether that time comes from the system clock or the project playhead (or somewhere else). We can only speculate but based on the DSP meter and CPU usage it would seeem the Reason only evaluates what’s needed for audio output and REs at least try to stop evaluation once the output level drops below an epsilon.

Overall I don’t get what you’re antagonistically emphatically agreeing with me over :=? Give me a reason to respect your authority on this topic. I think you may have misread my post.

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

25 Sep 2017

per-anders wrote:
25 Sep 2017
3 - I don’t think you understand what thread synchronization is or how it’s done.
You think wrong...Nothing more to add. Elvis has left the building...
Reason12, Win10

avasopht
Competition Winner
Posts: 3932
Joined: 16 Jan 2015

25 Sep 2017

Propellerhead engineers are probably skimming this thread like:
Image

User avatar
AttenuationHz
Posts: 2048
Joined: 20 Mar 2015
Location: Back of the Rack-1

25 Sep 2017

avasopht wrote:
25 Sep 2017
Propellerhead engineers are probably skimming this thread like:
Image
:thumbs_up: :lol:
It is not too much of an ask for people or things to be the best version of itself!

User avatar
kimothebeatmaker
Posts: 105
Joined: 02 Dec 2016
Location: Texas

25 Sep 2017

Im not sure I understand....im in sequencer view and the button I assigned to open the VST window isn't working. Do I have to set a hotkey for each vst? Does this not work with the VST that is highlight in the Sequencer view? Focus click my Spire VST or Kontakt VST and hit a button on my midi controller should open the VST window...1 button....1 button to open the Window....no?
"Cocaine and Prostitutes"

User avatar
Oquasec
Posts: 2849
Joined: 05 Mar 2017

25 Sep 2017

It must be something to have to maintain a daw and any thirdparty plugins that are made for that daw, and then keeping all the plugins 64bit or 128bit.
Producer/Programmer.
Reason, FLS and Cubase NFR user.

per-anders
Posts: 224
Joined: 09 Jul 2015

25 Sep 2017

normen wrote:
25 Sep 2017
Meh, that again. Let me translate what you just said:

„Multithreading is for making things fast. Heres two random misconceptions nobody in this thread had. If you compute with two processors you compute faster. Some plugins might have issues with multithreading. Multithreading in Reason might improve performance, I don‘t know. Reason is slower than all other DAWs and should freeze automatically.“

See, I still don‘t see any indication for the actual issue people are talking about being real. You CAN put high load on all your CPUs with Reason which is proof alone that the MT works. The „oh so problematic“ UAD issues are down to the buffer size, not any magic performance or threading issues. The plugins that cause issues simply don‘t support low buffer sizes. Nobody showed any evidence for anything else.

If you feel like you have to respond with „yes there is issues“ I ask you to explain it in laymans terms then, not fire a smoke screen of hollow words. Also note that I don't feel like we're talking against each other. I am talking about what we can see and you are talking about what the Props should do - thats two completely different things.
See that's the problem when you try to "translate" what someone else said into the fiction going on in your head.

You just stated exactly what I said was a misconception as apparently your own conception. And then again in this post.

MP's purpose is to speed up processing. Please read. MT's purpose meanwhile depends on where and how it's being utilized and the hardware available. As I stated it's a misconception (that word means "invalid belief" or "misunderstanding" in case it's getting lost in translation, clearly the antonym of whatever you and Loque are translating it to mean) to believe you can just throw on MT and expect speed gains. I'm reiterating because you seemed to imagine that I said the exact opposite, somehow inferring that I'd suggest that it's a panacea, which it aint. Please read what I'm writing, it doesn't require translation into fiction, there are no "hollow" words there just simple facts.

So moving onto that other misconception - High load does not equal high efficiency. Your computer can use all of it's cores at 100% doing nothing at all, just threads waiting on mutex. CPU usage really isn't an indicator that Reason's MT is working well, it's proof only that Reason's MT is using all your cores, that is all. Efficiency boils down to how quickly you get a result from a program, not how much electricity your computer is using to do the job.

Reason has MT that's all. It's efficiency on multiple cores seems less than impressive, even without UAD in the picture.

Some real world tests to back up what I'm saying:

So some actual figures because you as you say you "still don‘t see any indication for the actual issue people are talking about being real", even though others have posted their figures already comparing Reason with other DAW's. Statements like this make me feel like you actually imagine that the whole rest of the world is deluded.

Loading up a nice heavy Respire patch "Lately_2016" and playing some chords on a track, and duplicating to see how many instances Reason could handle, project at 44.1k with a maximum buffer size set at 2048 to give plenty of freedom, the machine is four core (8 inc HT) running WIndows 10. With mult-core disabled Reason managed 4 devices before breaking up, with it enabled it managed another three before crackle reared it's ugly head, with HT another one. Unfortunately Reason (or Respire) didn't respect processor affinity so there was no way to test the efficiency curve at just 2 or 3 physical cores.

Given that this scenario is in many ways a best case - Each track is identical, will have identical execution paths up to the mixer with is doing a simple sum, there should be minimal RAM or Disc usage, there are very few points that require synchronization - this is really lousy scaling. Four times the processing power for ~2x the speedup is poor, bear in mind that the more cores you have the poorer the scaling factor is going to be, meaning that someone with 8 physical cores is more likely to see a 3x speedup than 4x, possibly much less.

I'd love to see some figures from people running machines with more or fewer cores, and newer and older chips so we could see exactly what Reason's real world MP performance is really like.

Anyhow, onto VST's and comparing with the competition because real world examples carry more weight than simply explaining this stuff.

Using Presonus Studio 1 I found a fairly heavy VI and just slapped it onto a track. S1 doesn't offer options to enable or disable MP as a whole, it just does it. So I just set the affinity manually to check it's MP scores (which it had no problems with). S1 played back up to 8 tracks before crackle started to rear it's ugly head on a single core. With two cores S1 managed a surprisingly linear 16 tracks, shifting up to 3 cores we suddenly start to hit the limits of not so much Studio 1's thread handling as my computers memory (hit max here and of course then VM kicks in which decimates performance), allowing only 4 more tracks bringing the total to 20, shifting to all four cores we can somehow add another three tracks, hitting 23, this gives an almost 3x scaling factor at 4 cores, which is much more acceptable but still less than ideal.

There would be some other potential losses in the last core due to system interrupts, but I suspect with a less memory hungry VST it would have managed some impressive figures. S1 never used more than 80% of any core. Oh and something rather nice in there - the S1 resource monitor window allows you to see each VI and it's CPU use individually in realtime which is pretty nice for finding and fixing whatever is slowing stuff down in a project, it allows you to quickly enable/disable each device individually from that window too.

Trying the same trick in Reason with the same VST and same buffer size of 64, and of course no limit on DSP usage here's the figures I get (bearing in mind that Reason's audio output MT causes it to lose output device if you try to set affinity, so all I can do is enable/disable MP/SP and HT). For a single core Reason managed to play back 4 devices before crackle appeared. With all four cores I get up to 8 tracks before crackle appeared, HT worked surprisingly well here adding another 2 tracks.

In my experience and experiments Reason is not only much slower in general, but it's multiprocessing performance is also poorer than the competition. It really shouldn't require anything more said than that. Test it out yourselves, see what figures you come up with.

Whether you can see no fault with Reason you'd still like a faster and better optimized DAW right? To play more tracks and devices back in? I really shouldn't have to defend this sentiment. I stand by what I said at first - Props please look into your MT code. I'll add - and also just performance in general. Is that "laymans" enough for you?
Last edited by per-anders on 25 Sep 2017, edited 2 times in total.

User avatar
AttenuationHz
Posts: 2048
Joined: 20 Mar 2015
Location: Back of the Rack-1

25 Sep 2017

kimothebeatmaker wrote:
25 Sep 2017
Im not sure I understand....im in sequencer view and the button I assigned to open the VST window isn't working. Do I have to set a hotkey for each vst? Does this not work with the VST that is highlight in the Sequencer view? Focus click my Spire VST or Kontakt VST and hit a button on my midi controller should open the VST window...1 button....1 button to open the Window....no?
:|

The open plug-in window button is remotable so it can either be assigned to a hard map if you have a controller that will allow you to edit the the map file or set up each time you open a new project. Each open instance would be a different plug-in window so a different button on your midi keyboard for a different VST window. No one button will open the multiple windows because only one awoverride at a time can be assigned it has to be a different button on the midi controller. You can also not right click to edit override you have to edit it in the options menu. See gif up the top of the first page.

There is an annoying bug that keeps occurring with multiple windows open if you close one window when two are on screen when in the sequencer or mixer windows the rack will pop up when all 3 windows are detached. :(
It is not too much of an ask for people or things to be the best version of itself!

User avatar
kimothebeatmaker
Posts: 105
Joined: 02 Dec 2016
Location: Texas

26 Sep 2017

Thats unfortunate to hear...

I do have a mpk249 which is mappable, but I have no idea how to do it. The thing I dont get it is, I can move up and down the rack with my midi controller, change patches of the device im selected on, with my midi controller with the same buttons. Wish it could be the same with VSTs :( Im sure they can make it happen.
"Cocaine and Prostitutes"

Post Reply
  • Information
  • Who is online

    Users browsing this forum: No registered users and 22 guests