UAD-1: DX or VST?

[Dave Labrecque]

What's the conventional wisdom on which is better to run in SAW? Or are there pros/cons to each?

[earthpig]

I dont even bother installing the dx versions of the plugins in my setup. vsti seems to work fine.

Also the new limiter is fantastic ! :D

[Perry]

What's the conventional wisdom on which is better to run in SAW? Or are there pros/cons to each?


Hi Dave,

Yeah....definitely I would run the VST versions. The UAD-1 natively is a VST program. The Direct X support was added later and is brought about through the use of a VST "wrapper". It's an added complexity and as far as I know was essentially meant as a work around for programs with no vst support.

I wouldn't even install the Direct X versions unless I knew that I needed those somewhere (plus you could always add them later if the need did arise).

Hope this helps.. all the best,

Perry

[Dave Labrecque]

Thanks, Perry. That's exactly the kind of thing I wanted to know about. Bob
said something recently about DX being able to do something with buffers
that VST couldn't, if I understood right. Any idea what that's about, and
how it might play a role here?

And hey, you should know that there's someone using your name who
left an identical reply on the other forum.

Dave

[Dave Labrecque]

So much to buy, so little money! :)

[spiritman]

I only use the VST Uad's after Bob did all the work to make them work so ssssmmmmmmoooootttthhhhhh.......

[Bob L]

Dave,

The DirectX protocol will let plugins absorb buffers and return buffer sizes different from what they take in... VST will not do this (as far as I know... correct me if I'm wrong anyone), which is why there are latency issues with plugs that need to absorb some starting buffers before doing their calciulations and returning their first buffer of processed data. They will usually return blank buffers while they absorb the data they need, then the processed data is returned late.

I doubt you will gain with the UAD or most plugs that focused on VST... they will not take advantage of the buffer size manipulation usually, because it was not part of their original design plan.

SAWStudio native plugs can manipulate buffer sizes also, which is how Jon's latency compensator works.

Of course the real complexity comes for the app engine that has to accept various buffer sizes from different tracks and buffer them in such a way that all tracks come out in sync... this is one of the more complex areas of the SAWStudio engine, and it is what allows plugs like the Sonic Foundry (Sony) Time Compressor to work in realtime, even on multiple tracks and output tracks.

Bob L

[AudioAstronomer]

The new VST spec is supposed to take care of abusing different buffer sizes... I think we're about 4-6 months from an official release on it. the cubase/nuendo 3 rumours are abounding right now and there was supposed to be a new VST (3.0) with them.

[TotalSonic]

this is one of the more complex areas of the SAWStudio engine, and it is what allows plugs like the Sonic Foundry (Sony) Time Compressor to work in realtime, even on multiple tracks and output tracks.

Bob L

and one of the features that makes me mighty happy as SAW user!!

Best regards,
Steve Berson

[Bob L]

Funny how you are talking about a buffer size changing engine in 4 to 6 months... do you realize I have been doing it since SAWPro... over 5 years ago. :)

Bob L

[AudioAstronomer]

Funny how you are talking about a buffer size changing engine in 4 to 6 months... do you realize I have been doing it since SAWPro... over 5 years ago. :)

Bob L

Oh, I do ;)

It's a kick in the face in fact. Thinking for a long time... nah you CANT do that, to find out some genius has already been doing it for years. Blah :)

[Perry]

Funny how you are talking about a buffer size changing engine in 4 to 6 months... do you realize I have been doing it since SAWPro... over 5 years ago. :)

Bob L


:eek: :D :) :cool: