Any fix/info yet on the UAD Plugin issue ?
-
- Posts: 224
- Joined: 09 Jul 2015
Well done for looking it up. That should help you understand what I was saying.
Now help me understand what it is you’re saying. Because as far as I can tell all you’re saying with extreme verbage is that you don’t feel Reason should support the VST format and UAD plugins. The trouble of course with that is that it does support VST right now, just apparently with some teething troubles compared to the competition. The OP has every right to request improvement.
Now help me understand what it is you’re saying. Because as far as I can tell all you’re saying with extreme verbage is that you don’t feel Reason should support the VST format and UAD plugins. The trouble of course with that is that it does support VST right now, just apparently with some teething troubles compared to the competition. The OP has every right to request improvement.
No, I won‘t repeat myself, you can ask me specific questions about things that were unclear for you though.per-anders wrote: ↑21 Sep 2017Well done for looking it up. That should help you understand what I was saying.
Now help me understand what it is you’re saying. Because as far as I can tell all you’re saying with extreme verbage is that you don’t feel Reason should support the VST format and UAD plugins. The trouble of course with that is that it does support VST right now, just apparently with some teething troubles compared to the competition. The OP has every right to request improvement.
-
- Posts: 224
- Joined: 09 Jul 2015
Whether you like it or not Reason now supports the VST format. The Propellerheads are even reselling VSTs in their shop. It’s not going away. This thread should not be about personal prejudices and protectionism.
As far as I can tell you know nothing about what the OP is asking, so unless anyone else has anything relevant to offer the answer to the OP’s question is - Nothing yet.
As far as I can tell you know nothing about what the OP is asking, so unless anyone else has anything relevant to offer the answer to the OP’s question is - Nothing yet.
Not sure who that's directed at but I'm not just showing off knowledge.per-anders wrote: ↑21 Sep 2017What do you think a stream is exactly?
Also this still has nothing to do with UAD plugin support that I can see. You’re trying to show off your knowledge and experience but unless you have something that’s concrete and relevant then I’m just not sure what your point is at all.
Here's what's concrete:
1. Processing in 64 frame matches can increase CPU load a fair bit.
2. Reason always processes in batches of 64 frames (I even provided a link above to the test you can perform to confirm).
Some DAWs have a specific option called live mode to process plugins in smaller batch sizes.
I see zero protectionism or prejudices.
Last edited by avasopht on 21 Sep 2017, edited 1 time in total.
I don't think anyone is saying reason shouldn't support VSTs, nor was anyone saying the op doesn't have a right to request an improvement.per-anders wrote: ↑21 Sep 2017Well done for looking it up. That should help you understand what I was saying.
Now help me understand what it is you’re saying. Because as far as I can tell all you’re saying with extreme verbage is that you don’t feel Reason should support the VST format and UAD plugins. The trouble of course with that is that it does support VST right now, just apparently with some teething troubles compared to the competition. The OP has every right to request improvement.
I'm confused where those two ideas came from, or am I missing something?
-
- Posts: 224
- Joined: 09 Jul 2015
Earlier on in the thread the suggestion was made to another forum user to compare other DAWs with a buffer size of 64, which is honestly ludicrous on so many levels as an excuse for Reasons poor performance with UAD plugins being apparently forced to work in native mode.
As an explanation for poor general performance sure it makes sense but related to UAD plugins which are known for their low CPU hit in systems running with quite small buffer sizes thanks to utilizing external DSP, not so much. Anyhow I suggested that the Props should fix this sorry state of affairs and the answer came back more or less (as far as I can see) that - No they shouldn’t because that’s not what Reason is about, there are other DAWs if you need working VST support and most of all I don’t want to have to redo my plugins.
None of this of course seems to offer any insight into the original question though. I can’t speak for the OP but I’m no wiser as to why UAD plugins aren’t apparently working correctly or efficiently with Reason for some users, nor when a fix may happen from either the Props or the UAD teams. Honestly I’m not even clear on whether this has been marked as a known bug at this point or even if the Props or UAD are aware. From the way the OP talks it sounds like it’s some known thing, but does anyone have a link to where the Props stated that they’re even looking into this?
As an explanation for poor general performance sure it makes sense but related to UAD plugins which are known for their low CPU hit in systems running with quite small buffer sizes thanks to utilizing external DSP, not so much. Anyhow I suggested that the Props should fix this sorry state of affairs and the answer came back more or less (as far as I can see) that - No they shouldn’t because that’s not what Reason is about, there are other DAWs if you need working VST support and most of all I don’t want to have to redo my plugins.
None of this of course seems to offer any insight into the original question though. I can’t speak for the OP but I’m no wiser as to why UAD plugins aren’t apparently working correctly or efficiently with Reason for some users, nor when a fix may happen from either the Props or the UAD teams. Honestly I’m not even clear on whether this has been marked as a known bug at this point or even if the Props or UAD are aware. From the way the OP talks it sounds like it’s some known thing, but does anyone have a link to where the Props stated that they’re even looking into this?
Uhm, no. Sending your audio from the CPU via a Firewire or PCI bus to a DSP chip and then back in to the CPU is NOT a recipe to get low latency or use small buffer sizes. It simply isn't. You do realize that an UAD is EXACTLY the same as running your audio though an audio interface into some analog hardware and then back in, right? Every single channel that is supposed to get FX is routed via the Firewire/PCI bus.per-anders wrote: ↑21 Sep 2017UAD plugins which are known for their low CPU hit in systems running with quite small buffer sizes thanks to utilizing external DSP, not so much.
The point of external DSP for UAD is mainly copy protection - for the Apollo or professional ProTools systems its being able to run DSP BEFORE the audio gets into the CPU, avoiding the added latency, not for running many plugins. Thats why ProTools added native processing, in terms of raw THROUGHPUT a CPU runs circles around the typical Sharc DSP chips. Where the DSP chip shines is low latency, however not if you mix in the CPU
Edit: Note I do have an UAD Apollo Quad and have been on the UAD train since UAD 1
-
- Posts: 224
- Joined: 09 Jul 2015
Both Firewire and especially PCIe have more than enough bandwidth and a small enough handshake to deal with this task. The issue is how efficiently you deal with the protocol and batching, that's down to UAD.
In any case, I ran the test. Studio 1 at 64 samples vs Reason at 64 samples. A short stereo audio loop streaming off of an SSD. The projects at 44.1k. A 4 core machine with hyperthreading bringing it up to 8 virtual cores in total. A UAD Quad Apollo working via Firewire (worst possible scenario). The UAD Studer emulation running with the FX - Grunge preset, one instance per track.
Both were capable of hitting the DSP max of the Apollo on my setup (which is 15 instances). However there were differences. Studio 1 maintained a very low CPU usage across all cores from start to finish during this test, overall CPU usage was in the 2-3% range (it's own meter gave me 9% usage which is slightly higher than I'd expect but nothing much), the rest pretty much idling. Reason started out with at least that and as soon as a single instance of a UAD plugin was added core usage shot up across the board doubling DSP. Reason also suffered dropouts/crackle at 64 samples buffer size (which Studio 1 did not).
Interestingly, raising the buffer size itself had initially minimal impact on core usage according to the Resource Monitor application, however within Reason itself it caused the DSP monitor to go up sharply to 3/4 usage. Over time the average usage shown in the Resource Monitor did however eventually stabilize at 25%. Removing Hyperthreading brought the usage back down to 9%, and disabling MP from the preferences reduced usage further down to 6%. Using the Task Manager to reduce the affinity down to a single core Reason showed CPU usage back down to 5%. Meanwhile of course Reason showed no difference in it's own DSP monitoring, and continued to run 32 threads at all times.
The behavior was present in other "real world" projects heavily dependent on RE's too, however when fewer UAD plugins were present the DSP meter display in Reason behaved in a slightly more accurate manner.
Overall Reason's MT behavior leaves a lot to be desired and seems to be very far from linear, instead actually resulting in greater overhead in many situations. I don't have time right now to debug Reason's thread and memory usage, locking, drops, scheduling etc, but it's obviously not working as it should, however this goes outside of the scope of this thread.
It's probably reasonable to extrapolate from all of this that in the end Reason's own overhead is what's killing it in this situation as compared to the competition. There is an unexpected jump in usage when using a UAD plugin but I cannot reproduce the OP's figures with UAD plugins on my system, however Reason's own DSP meter shows a different metric to that shown in other CPU meters, I'm not sure how reliable this is.
In any case, I ran the test. Studio 1 at 64 samples vs Reason at 64 samples. A short stereo audio loop streaming off of an SSD. The projects at 44.1k. A 4 core machine with hyperthreading bringing it up to 8 virtual cores in total. A UAD Quad Apollo working via Firewire (worst possible scenario). The UAD Studer emulation running with the FX - Grunge preset, one instance per track.
Both were capable of hitting the DSP max of the Apollo on my setup (which is 15 instances). However there were differences. Studio 1 maintained a very low CPU usage across all cores from start to finish during this test, overall CPU usage was in the 2-3% range (it's own meter gave me 9% usage which is slightly higher than I'd expect but nothing much), the rest pretty much idling. Reason started out with at least that and as soon as a single instance of a UAD plugin was added core usage shot up across the board doubling DSP. Reason also suffered dropouts/crackle at 64 samples buffer size (which Studio 1 did not).
Interestingly, raising the buffer size itself had initially minimal impact on core usage according to the Resource Monitor application, however within Reason itself it caused the DSP monitor to go up sharply to 3/4 usage. Over time the average usage shown in the Resource Monitor did however eventually stabilize at 25%. Removing Hyperthreading brought the usage back down to 9%, and disabling MP from the preferences reduced usage further down to 6%. Using the Task Manager to reduce the affinity down to a single core Reason showed CPU usage back down to 5%. Meanwhile of course Reason showed no difference in it's own DSP monitoring, and continued to run 32 threads at all times.
The behavior was present in other "real world" projects heavily dependent on RE's too, however when fewer UAD plugins were present the DSP meter display in Reason behaved in a slightly more accurate manner.
Overall Reason's MT behavior leaves a lot to be desired and seems to be very far from linear, instead actually resulting in greater overhead in many situations. I don't have time right now to debug Reason's thread and memory usage, locking, drops, scheduling etc, but it's obviously not working as it should, however this goes outside of the scope of this thread.
It's probably reasonable to extrapolate from all of this that in the end Reason's own overhead is what's killing it in this situation as compared to the competition. There is an unexpected jump in usage when using a UAD plugin but I cannot reproduce the OP's figures with UAD plugins on my system, however Reason's own DSP meter shows a different metric to that shown in other CPU meters, I'm not sure how reliable this is.
Interesting. Can we be sure that Studio1 doesn't use a larger buffer size behind the scenes like Logic does? (I am asking, I don't know and don't care to investigate about S1 right now) Edit: Oh wait, you can just look in the UAD panel, d'oh ^^
The DSP meter basically shows a percentage of the duration of one buffer. That percentage is the time that had to be spent actually processing the data.
Processing doesn't just involve the CPU crunching numbers (which is what a CPU meter shows), its also copying data from the USB bus to memory, copying data to a Firewire bus, copying data in memory in general and even the CPU doing other things like handling file streams, handling interrupt requests from your graphics card and other things. So you could get 100% DSP load while having almost 0% CPU load and vice versa you could have very low DSP load while having relatively high CPU load.
DSP usage isn't the same as CPU usage. DSP usage is the amount of time that is used to process [buffer size] samples - and this time its the actual buffer size, even in Reason The computer can obviously not take more time to process one buffer than it lasts - thats when you get crackles and a "computer too slow message".per-anders wrote: ↑21 Sep 2017Reason's own DSP meter shows a different metric to that shown in other CPU meters, I'm not sure how reliable this is.
The DSP meter basically shows a percentage of the duration of one buffer. That percentage is the time that had to be spent actually processing the data.
Processing doesn't just involve the CPU crunching numbers (which is what a CPU meter shows), its also copying data from the USB bus to memory, copying data to a Firewire bus, copying data in memory in general and even the CPU doing other things like handling file streams, handling interrupt requests from your graphics card and other things. So you could get 100% DSP load while having almost 0% CPU load and vice versa you could have very low DSP load while having relatively high CPU load.
-
- Posts: 224
- Joined: 09 Jul 2015
S1 has a form of dropout avoidance, however it was set to what it describes as "Minimum", which obviously doesn't mean the same thing as none, but there's no way of being able to determine what that case is.
I understand that, however the fact remains that S1 maintains a much lower so called "DSP" usage and CPU usage than Reason across the board.
I understand that, however the fact remains that S1 maintains a much lower so called "DSP" usage and CPU usage than Reason across the board.
I updated my post, you should be able to see in the UAD panel at what buffer size the UAD plugins are run.per-anders wrote: ↑21 Sep 2017S1 has a form of dropout avoidance, however it was set to what it describes as "Minimum", which obviously doesn't mean the same thing as none, but there's no way of being able to determine what that case is.
I understand that, however the fact remains that S1 maintains a much lower so called "DSP" usage and CPU usage than Reason across the board.
Holy Crap . Never noticed that before, now the question is Why? and do you change that
If you read the whole thread you'll see that one solution I and others repeatedly suggested would be to have a global setting that makes all (or maybe even certain - but that would require even more work) VST plugins use a different buffer size. This would however mean that they ALWAYS introduce latency in the signal flow, even if they wouldn't have to. They also couldn't be modulated as fast as normal devices - let alone the fact that the latency would mess up modulation anyway.
But again, the whole Reason idea is based on an engine where everything works closely "in sync" and as per my explanation in that post the 64 samples thing is their solution to achieve that. Reason does its stuff "for real" in realtime - more like an analog studio. Most other hosts play with the fact that they don't actually have to keep everything in sync, they can play tracks in advance and give them larger buffers etc. which is great and certainly what I'd recommend if you plan to play 10s of Kontakt instruments. But trying to weave that into Reason would mean too many compromises to what made Reason great in the first place - probably a reason why some people actually seem a bit threatened by VST support in Reason.
As I tried to indicate in my very first post here - Reason is simply quite different, its made for a different thing.
spikey wrote: ↑10 Sep 2017MISNOMER: ""Computer too slow to play song" ""Computer too slow to play song"
WRONG. It's REASON tat's TOO SLOW to play song!!
How well would a piano or guitar sell that could not play the song? They wouldn't
This is a GRAVE problem.
Ever since VTS introduction Reason has been running like a gimp dog -- and i don't even use VSTs
-
- Moderator
- Posts: 1851
- Joined: 14 Sep 2015
- Location: Paris, France
Topic moved to VST forum.
Any news on the S1 buffer size front? It's in the UAD panel.per-anders wrote: ↑21 Sep 2017S1 has a form of dropout avoidance, however it was set to what it describes as "Minimum", which obviously doesn't mean the same thing as none, but there's no way of being able to determine what that case is.
I understand that, however the fact remains that S1 maintains a much lower so called "DSP" usage and CPU usage than Reason across the board.
-
- Posts: 224
- Joined: 09 Jul 2015
I haven't had time to check today, I'll give it a run through this weekend.
Exactly what I need- a simple step by step way to configure Reason to work with my Apollo firewire interface and plugins, which works SUPER with Logic X, Cubase 9x but crashes Reason with error messages every time I load a UAD plugin into Reason. Now, before anyone says it let me, I do NOT have to jump thru hoops to run UAD plugins in Cubase or Logic X, they just run. I want REASON to act the same way and it should without having to get degrees in programming.per-anders wrote: ↑21 Sep 2017Also this still has nothing to do with UAD plugin support that I can see. You’re trying to show off your knowledge and experience but unless you have something that’s concrete and relevant then I’m just not sure what your point is at all.
That could also be read as "changing the way Reason has painted their way into a corner programming wise, and THEN adding VST Plugin support and asking it to work as other hosts do, was a pretty stupid idea?"But trying to weave that into Reason would mean too many compromises to what made Reason great in the first place - probably a reason why some people actually seem a bit threatened by VST support in Reason.
-
- Posts: 224
- Joined: 09 Jul 2015
Ok, tested today.
In both Reason and Studio 1 the plugin requires 576 samples, regardless of how many instances of that plugin there are (remember this device is asynchronous so this value only represents plugin delay, not a block on processing that would impact the overall performance at any buffer size).
The buffer itself remains at 64 in both Reason and S1 as you'd expect.
I tried to find out about the "Audio-Dropout Protection" setting and this is what I found - https://support.presonus.com/hc/en-us/a ... toring-FAQ
In this case though all the UAD plugins were functioning correctly, non ommited. Each additional plugin used up another 1% of the FW bandwidth. The plugin bandwidth did not fluctuate at all, the DSP usage likewise was identical in both Reason and S1, the buffer did not change according to the control panel. S1 just handled it all better.
In both Reason and Studio 1 the plugin requires 576 samples, regardless of how many instances of that plugin there are (remember this device is asynchronous so this value only represents plugin delay, not a block on processing that would impact the overall performance at any buffer size).
The buffer itself remains at 64 in both Reason and S1 as you'd expect.
I tried to find out about the "Audio-Dropout Protection" setting and this is what I found - https://support.presonus.com/hc/en-us/a ... toring-FAQ
In this case though all the UAD plugins were functioning correctly, non ommited. Each additional plugin used up another 1% of the FW bandwidth. The plugin bandwidth did not fluctuate at all, the DSP usage likewise was identical in both Reason and S1, the buffer did not change according to the control panel. S1 just handled it all better.
S1 runs all plugins at 64 samples, always? I almost can't believe that..? Why would it do that? How do you run plugins that require larger buffer sizes?per-anders wrote: ↑24 Sep 2017The buffer itself remains at 64 in both Reason and S1 as you'd expect.
-
- Posts: 224
- Joined: 09 Jul 2015
That’s only if the buffer is set to 64 for the project. It’s the same as for Reason. The plugin buffer doesn’t reflect the project settings and never will, it’s the latency that the plugin introduces on the Apollo. For both Reason and S1 while using a project sample buffer size of 64 the plugin buffer in the UAD control panel shows 576 samples. Different plugins will introduce different latencies obviously.
-
- Information
-
Who is online
Users browsing this forum: Google [Bot], Sogou [Spider] and 5 guests