Any fix/info yet on the UAD Plugin issue ?

Discuss VST stuff here!
per-anders
Posts: 224
Joined: 09 Jul 2015

21 Sep 2017

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.

User avatar
normen
Posts: 3431
Joined: 16 Jan 2015

21 Sep 2017

per-anders wrote:
21 Sep 2017
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.
No, I won‘t repeat myself, you can ask me specific questions about things that were unclear for you though.

per-anders
Posts: 224
Joined: 09 Jul 2015

21 Sep 2017

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.

avasopht
Competition Winner
Posts: 3932
Joined: 16 Jan 2015

21 Sep 2017

per-anders wrote:
21 Sep 2017
What 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.
Not sure who that's directed at but I'm not just showing off knowledge.

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.

avasopht
Competition Winner
Posts: 3932
Joined: 16 Jan 2015

21 Sep 2017

per-anders wrote:
21 Sep 2017
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.
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.

I'm confused where those two ideas came from, or am I missing something?

per-anders
Posts: 224
Joined: 09 Jul 2015

21 Sep 2017

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?

User avatar
normen
Posts: 3431
Joined: 16 Jan 2015

21 Sep 2017

per-anders wrote:
21 Sep 2017
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.
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.

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

per-anders
Posts: 224
Joined: 09 Jul 2015

21 Sep 2017

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.

User avatar
normen
Posts: 3431
Joined: 16 Jan 2015

21 Sep 2017

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 ^^
per-anders wrote:
21 Sep 2017
Reason's own DSP meter shows a different metric to that shown in other CPU meters, I'm not sure how reliable this is.
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".

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.

per-anders
Posts: 224
Joined: 09 Jul 2015

21 Sep 2017

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.

User avatar
normen
Posts: 3431
Joined: 16 Jan 2015

21 Sep 2017

per-anders wrote:
21 Sep 2017
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 updated my post, you should be able to see in the UAD panel at what buffer size the UAD plugins are run.

User avatar
normen
Posts: 3431
Joined: 16 Jan 2015

21 Sep 2017

So I actually installed Reason 9.5 on my main mixing computer to test this and lo and behold - Reason runs the UAD at 64 samples no matter what..

Image

Why the people that actually wanted to use this setup didn't notice that is beyond me..

User avatar
Blast
Posts: 104
Joined: 22 Oct 2015

21 Sep 2017

normen wrote:
21 Sep 2017
So I actually installed Reason 9.5 on my main mixing computer to test this and lo and behold - Reason runs the UAD at 64 samples no matter what..

Image

Why the people that actually wanted to use this setup didn't notice that is beyond me..
Holy Crap :!: . Never noticed that before, now the question is Why? and do you change that :?:

User avatar
normen
Posts: 3431
Joined: 16 Jan 2015

21 Sep 2017

Blast wrote:
21 Sep 2017
now the question is Why?
See this post for the answer to that question.

User avatar
Blast
Posts: 104
Joined: 22 Oct 2015

21 Sep 2017

normen wrote:
21 Sep 2017
Blast wrote:
21 Sep 2017
now the question is Why?
See this post for the answer to that question.
So are you saying that Props would never fix this issue or that tis issue is next to impossible to fix?

User avatar
normen
Posts: 3431
Joined: 16 Jan 2015

21 Sep 2017

Blast wrote:
21 Sep 2017
So are you saying that Props would never fix this issue or that tis issue is next to impossible to fix?
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.

User avatar
normen
Posts: 3431
Joined: 16 Jan 2015

22 Sep 2017

So I guess @per-anders looked at his UAD panel himself and read exactly what I predicted? Or why the sudden radio silence? Kinda interested myself now at what buffer size Studio1 runs the UAD plugs.

User avatar
etyrnal2
Posts: 97
Joined: 29 Jan 2017
Contact:

22 Sep 2017

spikey wrote:
10 Sep 2017
"Computer too slow to play song"
MISNOMER: ""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
:reason: :record: :recycle: :re: :adapted: :ignition: :essentials: :refill: :rebirth:

WongoTheSane
Moderator
Posts: 1851
Joined: 14 Sep 2015
Location: Paris, France

22 Sep 2017

Topic moved to VST forum.

User avatar
normen
Posts: 3431
Joined: 16 Jan 2015

22 Sep 2017

per-anders wrote:
21 Sep 2017
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.
Any news on the S1 buffer size front? It's in the UAD panel.

per-anders
Posts: 224
Joined: 09 Jul 2015

22 Sep 2017

I haven't had time to check today, I'll give it a run through this weekend.

User avatar
spikey
Posts: 70
Joined: 06 May 2017

23 Sep 2017

per-anders wrote:
21 Sep 2017
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.
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.
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.
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?" :cool:

per-anders
Posts: 224
Joined: 09 Jul 2015

24 Sep 2017

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.

User avatar
normen
Posts: 3431
Joined: 16 Jan 2015

25 Sep 2017

per-anders wrote:
24 Sep 2017
The buffer itself remains at 64 in both Reason and S1 as you'd expect.
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
Posts: 224
Joined: 09 Jul 2015

25 Sep 2017

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.

Post Reply
  • Information
  • Who is online

    Users browsing this forum: No registered users and 11 guests