Page 2 of 3
Re: Any fix/info yet on the UAD Plugin issue ?
Posted: 21 Sep 2017
by per-anders
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.
Re: Any fix/info yet on the UAD Plugin issue ?
Posted: 21 Sep 2017
by normen
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.
Re: Any fix/info yet on the UAD Plugin issue ?
Posted: 21 Sep 2017
by per-anders
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.
Re: Any fix/info yet on the UAD Plugin issue ?
Posted: 21 Sep 2017
by avasopht
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.
Re: Any fix/info yet on the UAD Plugin issue ?
Posted: 21 Sep 2017
by avasopht
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?
Re: Any fix/info yet on the UAD Plugin issue ?
Posted: 21 Sep 2017
by per-anders
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?
Re: Any fix/info yet on the UAD Plugin issue ?
Posted: 21 Sep 2017
by normen
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
Re: Any fix/info yet on the UAD Plugin issue ?
Posted: 21 Sep 2017
by per-anders
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.
Re: Any fix/info yet on the UAD Plugin issue ?
Posted: 21 Sep 2017
by normen
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.
Re: Any fix/info yet on the UAD Plugin issue ?
Posted: 21 Sep 2017
by per-anders
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.
Re: Any fix/info yet on the UAD Plugin issue ?
Posted: 21 Sep 2017
by normen
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.
Re: Any fix/info yet on the UAD Plugin issue ?
Posted: 21 Sep 2017
by normen
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..
Why the people that actually wanted to use this setup didn't notice that is beyond me..
Re: Any fix/info yet on the UAD Plugin issue ?
Posted: 21 Sep 2017
by Blast
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..
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
Re: Any fix/info yet on the UAD Plugin issue ?
Posted: 21 Sep 2017
by normen
Blast wrote: ↑21 Sep 2017
now the question is Why?
See
this post for the answer to that question.
Re: Any fix/info yet on the UAD Plugin issue ?
Posted: 21 Sep 2017
by Blast
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?
Re: Any fix/info yet on the UAD Plugin issue ?
Posted: 21 Sep 2017
by normen
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.
Re: Any fix/info yet on the UAD Plugin issue ?
Posted: 22 Sep 2017
by normen
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.
"Computer too slow to play song"
Posted: 22 Sep 2017
by etyrnal2
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
Re: Any fix/info yet on the UAD Plugin issue ?
Posted: 22 Sep 2017
by WongoTheSane
Topic moved to VST forum.
Re: Any fix/info yet on the UAD Plugin issue ?
Posted: 22 Sep 2017
by normen
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.
Re: Any fix/info yet on the UAD Plugin issue ?
Posted: 22 Sep 2017
by per-anders
I haven't had time to check today, I'll give it a run through this weekend.
Re: Any fix/info yet on the UAD Plugin issue ?
Posted: 23 Sep 2017
by spikey
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?"
Re: Any fix/info yet on the UAD Plugin issue ?
Posted: 24 Sep 2017
by per-anders
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.
Re: Any fix/info yet on the UAD Plugin issue ?
Posted: 25 Sep 2017
by normen
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?
Re: Any fix/info yet on the UAD Plugin issue ?
Posted: 25 Sep 2017
by per-anders
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.