Any fix/info yet on the UAD Plugin issue ?

Discuss VST stuff here!
User avatar
spikey
Posts: 70
Joined: 06 May 2017

09 Sep 2017

Just checking- I would like to use 9.5x more but waiting for this to be fixed 1st...

Yea I know, I may have to wait a bit longer.. :(

FYI for those that don't already know, all my UAD plugins (and everything else) run just dandy in Logic X and Cubase 9.
And when loaded in Reason 9.5, they screech to a halt with a few "I can't continue" (think train wreck) messages that follow.


Late 2009 iMac
2.6 ghz quad core.
16 gigs ram
Sierra OS (latest releases)

Hauser+Quaid
Posts: 147
Joined: 06 Jun 2017

09 Sep 2017

Will probably be a while yet for a proper fix. Sorry to hear you're still having problems. I've been running UAD ok personally (it does consume Reason CPU cycles even though it's not supposed to of course), but aside from that hiccup I can get at least 50% usage from my UAD with no problems whatsoever. But I have a PCIe card, don't know if that has something to do with the difference in experience.

User avatar
MannequinRaces
Posts: 1543
Joined: 18 Jan 2015

09 Sep 2017

Move this post to the VST forum... might get better feedback there.

User avatar
spikey
Posts: 70
Joined: 06 May 2017

10 Sep 2017

But I have a PCIe card, don't know if that has something to do with the difference in experience.
Could be that u being right off the bus makes the difference? Being that my Apollo Quad interface is "Firewire", could that be an issue? Doesn't seem to bother any of my other hosts.

I just tried loading a "Legacy" LA2A UAD plugin on an Arturia synth (that loaded just fine before the UAD was loaded in), and immediately got the "Computer too slow to play song" message! Of course, those same plugins/components work just fine together in Cubase 9, Logic X, etc etc.... At least on my system, it doesn't appear to be a UAD issue.

Move this post to the VST forum... might get better feedback there.
Tried there already- got the same results- zilch, no, nothing. I remember the Propellerhead folks saying a few months back that they were "talking" to UAD to try and figure out some answers. I just wanted a short and sweet status report on where we were at.

User avatar
normen
Posts: 3431
Joined: 16 Jan 2015

17 Sep 2017

To compare the plugin performance properly set a 64 samples buffer size in the other DAW as Reason runs all plugins on 64 samples, regardless of the set audio buffer size. Changing that would be a MASSIVE change in how Reason works with audio in general.

So QED, Reason should best have its own plugin format ;)

per-anders
Posts: 224
Joined: 09 Jul 2015

17 Sep 2017

If that's the case then I disagree, the Props should fix Reason and RE's so that everything can handle different buffer sizes.

User avatar
normen
Posts: 3431
Joined: 16 Jan 2015

17 Sep 2017

per-anders wrote:
17 Sep 2017
If that's the case then I disagree, the Props should fix Reason and RE's so that everything can handle different buffer sizes.
"Fix"? Why? Theres more than enough DAWs that cater to these kinds of needs. Reason caters to the needs of people who like to do modulation and crazy routing. I could go on to explain why using 64 samples as a processing block size is a good idea in that context. I could also explain why adding some processing where the data has to be sent via FireWire or PCI to a DSP chip for processing and then back to the CPU to be routed back into the signal chain is a bad idea in that context..

But anyway, that is kind of my point, why adapt Reason? So that it can be like all other DAWs? Get one of those other DAWs then :)

Although I guess its too late already, I am also looking for another software that does what Reason DID back in the day - be a great synth rack. For all other things I went completely back to Logic. So it already happened, Reason became a mediocre DAW instead of a genius synth rack - so maybe they should simply do what you say and make it work like all other DAWs.

Edit: Sorry, that was a bit of frustration speaking there. As I said it would be a major change in Reason, I don't think it would be even possible - if you want I can explain why that is so. Maybe its possible to somehow "emulate" a bigger buffer size for specific plugins though - at a cost. At any instance its shoehorning something onto Reason that just doesn't fit there.

per-anders
Posts: 224
Joined: 09 Jul 2015

17 Sep 2017

What do you mean "cater to these kinds of needs?".

You mean the need to be able to run a project without your DAW keeling over?

Or the need for advertised features to function correctly?

Or the need to be able to use effects in a DAW?

Or the need to be able to correctly support the platforms that you integrate into your software?

I don't see how yet another whole new plugin API is going to be a better option than simply adding a buffer size parameter and telling people to get their plugins up to date (while feeding existing legacy RE's chunks of 64 samples to make up the full buffer size as picked by the user). A new plugin format just seems like an expensive and time consuming project for all involved and another bar for entry into the Reason environment rather than an enabler of new tools.

Also incorrect to imagine that larger block size would be less efficient in a node network. The trouble with node networks is that their efficiency is in pull rather than push functions. Branching itself is the killer for node network efficiency with streaming data, so In order for any node network to be efficient at stream execution especially in an MP environment dynamic block sizes actually make far more sense (as well as correctly written code and optimization within the nodes themselves, ideally the whole network should be compiled), and especially larger than chunks of size 64 or less where you'll likely end up with more overhead from thread management than cost from execution.

seqoi
Posts: 417
Joined: 12 Aug 2017

18 Sep 2017

normen wrote:
17 Sep 2017
To compare the plugin performance properly set a 64 samples buffer size in the other DAW as Reason runs all plugins on 64 samples, regardless of the set audio buffer size. Changing that would be a MASSIVE change in how Reason works with audio in general.

So QED, Reason should best have its own plugin format ;)
It is interesting i am seeing other people claim all over this forum yet when i ask noone answer.

Can you tell me how do you know that Reason runs all plugins on 64 samples, regardless of the audio buffer size setup? That would actually explain a lot of VST problems. Especially UAD and Acustica ones. See my thread here please viewtopic.php?f=47&t=7502998

I would like to know is this 64 buffer official and where do people get this info about Reason handling plugins at 64 buffers regardless of everything?

IMO if this is true then it is an issue and not form user side but from Propellerheads side. And how do you know that this is Massive change? Are you actually a PH developer? If you are then could you give us more info on this?

I mean there is a reason (not Reason app) why we have buffer sizes in ASIO driver settings and there is a obvious reason that 99% of other DAW applications respect that buffer size so why does Reason run at 64 buffer regardless of everything? Can you tell us?

seqoi
Posts: 417
Joined: 12 Aug 2017

18 Sep 2017

normen wrote:
17 Sep 2017

"Fix"? Why? Theres more than enough DAWs that cater to these kinds of needs. Reason caters to the needs of people who like to do modulation and crazy routing. I could go on to explain why using 64 samples as a processing block size is a good idea in that context. I could also explain why adding some processing where the data has to be sent via FireWire or PCI to a DSP chip for processing and then back to the CPU to be routed back into the signal chain is a bad idea in that context..
I see you edited your post but i sincerely disagree and i respect your opinion but it's wrong logic totally (in my opinion).

I remember six month ago people over at KVR claimed that it is impossible for Reason to have PDC (delay compensation) because Reason have routing from other world and that this alone would eat tremendous CPU. . People pointed to these Reason users that there are already other DAW apps with same routing capabilites and they all support PDC whatsoever for decades. Obviously that bold statements came from Reason people which never coded a thing in their life. Yet today we have PDC in Reason and world is spinning. They also claimed VST is impossible in Reason yet we have it here. I now realize you are not PH developer so how can you claim that they can not change 64 buffer thing if this is even true?!

Why your logic is wrong in my opinion (by your logic they should not fix anything even though i have found PH response where they admitted UAD issue and said they will fix it) is that if they offer you VST (i literally bought it because of that and i am glad i did) then VST should work. Simple as that.

It is not my concern how will they make it work they advertised they support VST. They did not anywhere tell me "we support VST but performance is degraded". See my other threads. I could spit out more. The point is they should make it work. Not even that, they told us they are working on a fix. So while i respect you you may look at other people situations from different angle. If i am running a plugin in 5 different apps and it behave ok, in Reason it behave far worse - where is problem then?

Anyway i think Reason is amazing i produced tracks and ideas in three weeks more then complete year behind. It just need time to mature when it comes to VST and proper support for UA etc.

User avatar
normen
Posts: 3431
Joined: 16 Jan 2015

18 Sep 2017

seqoi wrote:
18 Sep 2017
I remember six month ago people over at KVR claimed that it is impossible for Reason to have PDC (delay compensation) because Reason have routing from other world and that this alone would eat tremendous CPU. . People pointed to these Reason users that there are already other DAW apps with same routing capabilites and they all support PDC whatsoever for decades. Obviously that bold statements came from Reason people which never coded a thing in their life. Yet today we have PDC in Reason and world is spinning. They also claimed VST is impossible in Reason yet we have it here. I now realize you are not PH developer so how can you claim that they can not change 64 buffer thing if this is even true?!
Well and now we have half-assed plugin delay compensation. The exact core of what those guys (I suppose) said was impossible HAS NOT BEEN IMPLEMENTED. The routing inside Reason IS NOT COMPENSATED, only the mixer channels are (that bit of routing that works like in any other DAW), even my plugin can do more in that regard - if anything they were proved right. And I haven't seen anybody who said VST wasn't "possible", just that it was improbable and maybe even unwanted - maybe because of things like this? ;) Now problems like these eat away at the Props time. And note I didn't say making UAD plugins work (better) is impossible, just that it would be shoehorning.

And about the 64 samples.. I will attempt to explain whats the issue here..

(This below works the same in VST, AU, RE, what have you, its simply how plugins are done)

Okay so a plugin in its core is simply a bit of code that does some math on samples, right? So it gets a certain amount of samples all at once and then the DAW lets it "do its thing" on those samples and afterwards the DAW comes back and picks up the (now changed) samples. So in the simplest form a gain plugin would loop though all the samples and multiply them by 0.5, making the volume 6dB lower.

So this happens again and again while the DAW runs, each time the DAW calls the code with [buffer size] amount of samples. When this happens the plugins also read the current parameter settings, for example the "0.5" in the example. And this is where the issue lies. This means that the plugins processing buffer size defines the maximum modulation frequency for parameters! The amount of samples means a certain amount of time, hence a certain maximum frequency that can be represented.

See, if the plugin runs at 64 samples thats 44.100/64 = 689, meaning a maximum modulation frequency of 689/2 = 345Hz. If the plugin runs at 512 samples that pushes that frequency down to 43Hz!

So, since Reason is basically "made for modulation" it DOES make VERY MUCH sense to have plugins ALWAYS process only 64 samples at a time. And since they made this decision early and base a lot of things around it PLUS all plugins (not just REs) work like this - adding support for different processing buffer sizes would AT LEAST mean that some synths can't be modulated properly with lower settings. You can just as well start writing a new DAW in that case.

Edit: Please note that "But VST synths can modulate quickly" isn't the point here - they do that internally - its about external parameter/CV modulation.

olive6741
Posts: 294
Joined: 11 May 2016

19 Sep 2017

Very good and clear and precise explanation on why in Reason it's different... This is a very important thing we need to remember when we use Reason, and why we use it: modulation. So then CV's interest... so RE are nice because made for. And I suppose I can deduct problems with some Vst arises in Reason because they are maybe not so optimized to be "externally" modulated that fast (with that part of coding taking more time than what it generally/should take in a 'proper' RE) but maybe I'm wrong? Just asking...

User avatar
normen
Posts: 3431
Joined: 16 Jan 2015

19 Sep 2017

Its rather that some are not optimized to run at such low processing buffer sizes - the modulation frequency thing depends on the same thing but I guess thats not the important bit in the VST world. There IS ways to solve this but all of them involve added latency and somebody (Uaudio OR the Props) adding an ugly workaround for a marriage that is pretty forced in the first place.

seqoi
Posts: 417
Joined: 12 Aug 2017

20 Sep 2017

Normen thanks for answering other people i am sure will find it useful but....i did not asked about what are 64 samples and their explanation and relation to frequency rate i know that sorry i was not clear enough. My english is bad.

I wanted to ask - where did people read about Reason working at 64 samples internally regardless of ASIO buffer? Who told them that ? Where is that info? That is what i asked. I can't find that in Manual.
normen wrote:
19 Sep 2017
Well and now we have half-assed plugin delay compensation. The exact core of what those guys (I suppose) said was impossible HAS NOT BEEN IMPLEMENTED. The routing inside Reason IS NOT COMPENSATED, only the mixer channels are (that bit of routing that works like in any other DAW), even my plugin can do more in that regard
You say only the mixer channels are compensated but that's all what it need should be compensated anyway :o I think there is misunderstanding here or we both talk about different things. Question: why would you want to compensate anything which is not connected to mixer out therefore it does not produce sound? All daws work the same that way. Example You have VST instruments or effects. And instrument is added to daw, then series of FX is added to it. Some of instruments or FXes add delay in to chain. Delay is (example) 500 samples. All other channels are aligned to that delay of 500 samples and you have perfect sync and phase response. There is no magic to it nor there is some sort of obscure unreal audio routing which can't be compensated. If a plugin report latency correctly through output and if PDC is implemented in right way it will be compensated.

Why would you want to compensate delay of a device which is not connected anywhere that does not make any sense. But if it is connected somewhere then it should report total latency in that chain at the end of a channel and be compensated which is what other DAWs do.

normen wrote:
19 Sep 2017
And I haven't seen anybody who said VST wasn't "possible", just that it was improbable and maybe even unwanted - maybe because of things like this? ;)


Oh the fact you did not saw it does not make it non existent :) I saw many times people claimed over at KVR that VST is impossible because Reason have otherwordly routing where VST does not fit. Not only that they said RE is invented for that sole purpose and that RE is far superior then VST. but let's forget this now.


So basically you want to tell me that 64 samples is there because 64 samples is some sort of standard for Reason amazing routing capability and that is technical standard or limitation which can't be developed better ?

And that Reason PDC is half-assed because there is no other way around it and that PH in order to make this right can only sacrifice Reason further to make it more compatible?

Normen what will you say if i can point you to a DAWs which have the same audio routing capability of Reason, same FX routing capability of Reason and everything is perfectly compensated. And these DAWs are out there for decade or more and they respect ASIO buffer size and they do not work internally at 64 samples? And all VST works just fine there? And PDC does not eat CPU cycles..

Offtopic: I am puzzled why does Reason people think Reason is impossible to have this? I always get impression that most of Reason folks think their DAW is some sort of obscure super advanced application and all development solutions inside of Reason is batshit from other space engraved in stone and can not be changed because it is best the best out there the very best lalala. Where this mentality come from? Marketing? What?

Like it never occur to them that for example some development choices in Reason was not right or it was right for current vision in their history but it may not be right now when Reason want to adapt to new things as VST. I mean is it so hard to say: ok things really does not work good allow PH some time to fix this (which is what they are literally doing and they even said they will fix UA issues and all that).

No you have a case where numerous people report wrong things and then there is like x4 more people trying to marginalize or convince people with issues that problem is actually not that bad, not needed whatever.

It feels weird for old persons like me. I don't get it. What the heck?

User avatar
normen
Posts: 3431
Joined: 16 Jan 2015

20 Sep 2017

You say only the mixer channels are compensated but that's all what it need should be compensated anyway
Oh wow, you really do not see how you can do Routings in Reason where you would need PDC outside of the mixer...
Oh the fact you did not saw it does not make it non existent
Well I didn't see it and you didn't give me any example of somebody saying VST isn't possible either. I mean its like the Yeti, if it does exist you should be able to show me, right?
So basically you want to tell me that 64 samples is there because 64 samples is some sort of standard for Reason amazing routing capability and that is technical standard or limitation which can't be developed better.
No - I think I explained pretty well what the issue is, I don't know how to explain it better, sorry if it went over your head. Question: Why don't you get agitated about UAD not supporting 64 samples buffer size? Don't they claim to support the VST standard as well? Isn't 64 samples a valid value in VST? Oh - it works in other DAWs? Well other VST plugins work in Reason as well, so...
Normen what will you say if i can point you to a DAWs which have the same audio routing capability of Reason
You don't know if it has THE SAME capabilities. Can it really modulate parameters at over 300Hz? etc. etc. This is just as dumb as a teacher pointing to somebody else saying "well he can do it" - its a different thing.

As for how I know all this - well I did write a RE and also VSTs, I suppose you didn't :)

seqoi
Posts: 417
Joined: 12 Aug 2017

21 Sep 2017

Thank you Normen for very constructive and insightful creative post. Just as i pre-pictured above something is not quite right there when anyone question anything about Reason.

Oh and thanks for finally not providing any source of 64 samples claim and why it need to be stone engraved. You being a RE developer does not mean you have last word in tech, on the contrary it saddens me to see childish perception in potential you carry. Truly sad. I am starting to understand i am talking with very important person here.

Moreover finding funny post at KVR is not the same as looking for Yeti. Very stupid comparison. I just googled RE is Superior to VST and found a Propellerhead CEO claiming VST is a mess and RE is superior format. Literally. No wonder his userbase talk further about that now i get it.

You have nice drift off to other topics and pretending like you don't know what i am talking about but i am not gonna buy it.

Aha i understand it. It is UAD fault. Uad perform like right at 99% of 10 other DAW systems well across Mac and Win, Reason added VST support, UAD behave drastically worse but it's UAD problem even after Propellerhead themselves addressed it's their fault and they are working on fix. I see, but internet Normen is telling me it's UAD who sould fix this. Yeah it does make sense. Like completely. Thanks Normen.

Moreover for your info (i have UAD) - uad runs just fine at ASIO buffer of 64 samples, RME audio card ;)

Normen your 64 samples explanation totally crashed my brain. Yeah you are right about that one.

Oh to not make it on Yetis and all that supposedly funny jokes: Bitwig can connect and route anything to anything at audio rate, Mulab completely modular like completely you can connect everything to everything, fully PDC does not require magical 64 samples buffer, FL Studio patcher connect anything to anything PDCed with their Patcher, Jeskola Buz modular, DDMF Meta chainer plugin allow you to connect everything to everything even create crossovers, all PDCed inside any host which support PDC.

But it's ok Normen thinks and claim Reason PDC is "halfass", it can not be done because there is 64 samples buffer engraved at cryptonite planet and everyone else doing it right for last 15 years is wrong. On top of that he's a RE developer and a VST dveloper. He developed a total of 1 device, a free RE device which is now completely like 99% obsolete since PH added PDC https://shop.propellerheads.se/product/ ... ple-delay/ (that could explain your agenda though) and he programmed VST plugins but no one is aware of their existence in any internet database. I visited your website. Zero VST listed. Ok mister thanks again. (and i have to give you credit and respect for your audio engineering and setting up concert stages none of which have anything with what we talk about).

edit: i wasn't ware of it but there is mute/foe function. Sadly i'll have to use it for the first time. Bye mister and good luck with everything.

User avatar
normen
Posts: 3431
Joined: 16 Jan 2015

21 Sep 2017

Oh wow. I shouldn‘t try to EXplain to people who just want to COMplain.

avasopht
Competition Winner
Posts: 3931
Joined: 16 Jan 2015

21 Sep 2017

seqoi wrote:
21 Sep 2017

Oh and thanks for finally not providing any source of 64 samples claim and why it need to be stone engraved. You being a RE developer does not mean you have last word in tech, on the contrary it saddens me to see childish perception in potential you carry. Truly sad. I am starting to understand i am talking with very important person here.
You can measure the internal batch size, and it is indeed 64 samples (how to measure it explained here).

RE and VST developers have to know this otherwise they wouldn't be able to properly supply the DAW with the right number of samples.

It's also something developers can measure with 100% certainty.
seqoi wrote:
21 Sep 2017
Moreover for your info (i have UAD) - uad runs just fine at ASIO buffer of 64 samples, RME audio card
You might also want to invoke any live mode in the DAW if it has one (Logic does) otherwise the DAW may still process internally in a larger batch size.

per-anders
Posts: 224
Joined: 09 Jul 2015

21 Sep 2017

Modulation and other automated or driven UI data can be supplied as a stream within a node network, the same as the audio data. If Reason isn’t doing this already then it’s not fully leveraging its architecture, VST certainly operates in this way. Block size is irrelevant to any such capability.

User avatar
normen
Posts: 3431
Joined: 16 Jan 2015

21 Sep 2017

per-anders wrote:
21 Sep 2017
Modulation and other automated or driven UI data can be supplied as a stream within a node network, the same as the audio data. If Reason isn’t doing this already then it’s not fully leveraging its architecture, VST certainly operates in this way. Block size is irrelevant to any such capability.
Nah, most plugins operate the way I said (see the VST example code here). Solving it the way you say would be even worse, that would mean all plugins have to change, good luck trying to convince all plugin developers to change their plugins for just one host.

per-anders
Posts: 224
Joined: 09 Jul 2015

21 Sep 2017

Tell that to the developers using side chaining. A totally new API or standard as you were suggesting would require the exact same amount of rewriting (probably more so).

It’s also worth remembering that just because a plugin expects 64 samples doesn’t mean that restricts its host to using a buffer of no more or less than 64 samples. It just means that processing must occur in 64 sample blocks. The function of buffer size is not to dictate the block size within the application.

I also have no idea what any of this has to do with UAD plugins correctly utilizing external DSPs with Reason.

User avatar
normen
Posts: 3431
Joined: 16 Jan 2015

21 Sep 2017

per-anders wrote:
21 Sep 2017
Tell that to the developers using side chaining. A totally new API or standard as you were suggesting would require the exact same amount of rewriting (probably more so).

It’s also worth remembering that just because a plugin expects 64 samples doesn’t mean that restricts its host to using a buffer of no more or less than 64 samples. It just means that processing must occur in 64 sample blocks. The function of buffer size is not to dictate the block size within the application.

I also have no idea what any of this has to do with UAD plugins correctly utilizing external DSPs with Reason.
Side chains are just the same amount of samples at the same time, its basically like processing 4 instead of 2 channels...

And I repeatedly said that you could introduce additional latency for plugins to simulate a larger buffer size for external plugins but my whole point is that it is trying to bring things together that don‘ fit together.

As for a „totally new API“, that already exists, its called RE :) You were suggesting that plugins should „get their data as streams in a node environment“ - whatever that is supposed to mean exactly its simply not how plugins work today.

avasopht
Competition Winner
Posts: 3931
Joined: 16 Jan 2015

21 Sep 2017

per-anders wrote:
21 Sep 2017
Tell that to the developers using side chaining. A totally new API or standard as you were suggesting would require the exact same amount of rewriting (probably more so).
Side chaining is basically VSTs being given another audio channel input. REs can do this to the nth degree. There are a few REs that input and output audio CV.
per-anders wrote:
21 Sep 2017
It’s also worth remembering that just because a plugin expects 64 samples doesn’t mean that restricts its host to using a buffer of no more or less than 64 samples. It just means that processing must occur in 64 sample blocks. The function of buffer size is not to dictate the block size within the application.
I think you're misunderstanding the relevance.

Basically audio plugins are processed in batches because processing them 1 sample at a time is slow. When a plugin is first called to process data the CPU has to load the code into cache for faster access.

Anyway, Reason made a decision in version 1 to process all instruments in batches of 64 frames to synchronize with CV.

When a DAW host demands a plugin to render a batch of samples it must give back that exact amount of samples. It can still internally process in longer batches, but to do that requires a bit of a workaround. If your VST doesn't have that workaround then it will process in however many blocks of samples the host demands in that batch. The workaround involves creating a separate thread and synchronizing its output in larger batches with the host's demands for rendering smaller batches (with a significant delay).

In laymens terms, a VST could, but most don't. There is also a cost in that workaround. Doing this means you cannot have low latency processing and monitoring, but if you need to, as seems to be the case here, then it's a must.

The subject of VST performance comes down to this, and there's the theoretical possibility of thread scheduling playing a role.

per-anders
Posts: 224
Joined: 09 Jul 2015

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.

User avatar
normen
Posts: 3431
Joined: 16 Jan 2015

21 Sep 2017

per-anders wrote:
21 Sep 2017
What do you think a stream is exactly?
In computer programming its a place where you can repeatedly get access to a certain amount of data samples. Like the entry method of REs and VSTs. What do you think it is?

Post Reply
  • Information
  • Who is online

    Users browsing this forum: No registered users and 10 guests