URS Plugins ...

PaulBrewer

Do any of the brothers use URS plugins ?

Ole Rupert reckons if he had to chose only 1 x plug-in to use the URS chan strip would be the one.

http://www.ursplugins.com/ursStripPro.html

I see they say -

High Res 48 bit "Double Precision" processing
The URS Strip TDM version features Hi Resolution 48-bit TDM and URS Classic Console Strip Native features 64-bit "Double Precision" processing
for increased clarity and headroom with unparalleled gain reduction. Hi Resolution "Double Precision" processing helps to avoid internal clipping in the Digital Domain.

Does that imply the native sounds better than the TDM ?

trackmixstudio

I have been using Channel Strip Pro and Saturation for about a year.
I commented on it in a recent liquid mix thread.
It is a great plugin. The eq is not as aggressive as waves ssl and works better on bass and vocals for me. The compressors are really nice on it.
Saturation goes on every channel for me with a tiny touch of 15ips tape sim.
You would hardly notice it in isolation but it makes a big difference.
There was a huge thread on gearslutz about CSP where it was hailed as the best channel strip ever.

PaulBrewer

trackmixstudio wrote: »

.
There was a huge thread on gearslutz about CSP where it was hailed as the best channel strip ever.

Sorry Mick , I'm repeating myself ....

What's your take on the TDM/Native difference ?

DamagedTrax

ive only demo'd it but found it pretty good.

i own the saturation and like mick i love it.

if they combined the 2 they'd have a seriously killer channel strip to equal the UAD 88rs

trackmixstudio

PaulBrewer wrote: »

Sorry Mick , I'm repeating myself ....

What's your take on the TDM/Native difference ?

I can't comment on that. I am running logic.

PaulBrewer

trackmixstudio wrote: »

I can't comment on that. I am running logic.

Ok - in this instance the theoretical superior.

PaulBrewer

I don't know enough about that area to have an opinon.

Is a TDM plugin entirely different to a Native - even though they do the same things ? I don't know ...

DamagedTrax

TDM is more expensive because its for a smaller market and needs to be coded from the ground up. theres zero differance in sound quality.. and there cant be anyway as most TDM plugs ship with the native version so that the end user can interchange between them according to cpu needs.

kfoltman

PaulBrewer wrote: »

Does that imply the native sounds better than the TDM ?

Yes. Not because of 48-bit vs 64-bit difference, but because TDM is a fixed-point architecture, which theoretically creates all sorts of problems for plugin authors (limited dynamic range possibly leading to clipping and general difficulties in digital filter implementation).

Of course, when used correctly, even 48 bits should give enough resolution for any real life situation.

The higher price is most likely due to higher development cost - things that are trivial to implement with floating point architecture, require extra care on fixed point to avoid filter instability due to truncated coefficients, coefficients exceeding integer range, oscillations on least significant bit and other programming problems. Also, on all DSP architectures, using assembler instead of C is pretty much a requirement. The same doesn't make as much sense on modern general-purpose CPUs. It is uncommon to write FPU assembler code by hand, and even more uncommon to outperform any decent optimizing C compilers.

woodsdenis

PaulBrewer wrote: »

Sorry Mick , I'm repeating myself ....

What's your take on the TDM/Native difference ?

from Stephen Massey

There are frequent debates in the Pro Tools community about which plugin format sounds better, RTAS or TDM. There is no technical reason why an RTAS plugin can not output an identical bit stream as its TDM counterpart (and vice versa). If significant sonic deviation is found between the formats, then it is likely the result of programmer error. The algorithm for each must be coded separately and distinctly using different programming languages, which easily results in implementation inconsistencies. Furthermore, if the creator isn't extremely meticulous while testing and comparing them, then these mistakes can end up in the released product. This has happened with my past designs on a couple of occasions and I have seen it in other vendors' products as well. If you experience this problem with any of my current plugins, please shoot me an email. Otherwise, neither architecture is more magical sounding than the other and any discrepancies you've heard are likely addressed by this more mundane explanation.

AFAIK TDM plugins are programmed at the machine code level, while RTAS are programmed in C or whatever and then compiled down to machine code..

PaulBrewer

woodsdenis wrote: »

from Stephen Massey

There are frequent debates in the Pro Tools community about which plugin format sounds better, RTAS or TDM. There is no technical reason why an RTAS plugin can not output an identical bit stream as its TDM counterpart (and vice versa). If significant sonic deviation is found between the formats, then it is likely the result of programmer error. The algorithm for each must be coded separately and distinctly using different programming languages, which easily results in implementation inconsistencies. Furthermore, if the creator isn't extremely meticulous while testing and comparing them, then these mistakes can end up in the released product. This has happened with my past designs on a couple of occasions and I have seen it in other vendors' products as well. If you experience this problem with any of my current plugins, please shoot me an email. Otherwise, neither architecture is more magical sounding than the other and any discrepancies you've heard are likely addressed by this more mundane explanation.

Ah ! So they are MEANT to be the same but MAY not be ...! Interesting..

I suppose that raises the whole argument of buying the (usually?) cheaper Native Plugins to run on your Fast Ram maxed 'puter ? ... and save yourself a bundle.

PaulBrewer

kfoltman wrote: »

Yes. Not because of 48-bit vs 64-bit difference, but because TDM is a fixed-point architecture, which theoretically creates all sorts of problems for plugin authors (limited dynamic range possibly leading to clipping and general difficulties in digital filter implementation).

Of course, when used correctly, even 48 bits should give enough resolution for any real life situation.

The higher price is most likely due to higher development cost - things that are trivial to implement with floating point architecture, require extra care on fixed point to avoid filter instability due to truncated coefficients, coefficients exceeding integer range, oscillations on least significant bit and other programming problems. Also, on all DSP architectures, using assembler instead of C is pretty much a requirement. The same doesn't make as much sense on modern general-purpose CPUs. It is uncommon to write FPU assembler code by hand, and even more uncommon to outperform any decent optimizing C compilers.

You speak with some authority kfoltman.
Is this an area of your expertise ?

woodsdenis

PaulBrewer wrote: »

Ah ! So they are MEANT to be the same but MAY not be ...! Interesting..

I suppose that raises the whole argument of buying the (usually?) cheaper Native Plugins to run on your Fast Ram maxed 'puter ? ... and save yourself a bundle.

But you still need TDM for ADC and zero latency etc. Even so with the new Nahalem processors in Macs and PCs it will/has already make HD reduntant, power wise until.....

Digi releases the new HD :eek::eek::eek::eek:

PaulBrewer

woodsdenis wrote: »

But you still need TDM for ADC :

Of course ...

New HD? - deliver us from all Harm Sacred Lamb of Jesu ...:eek:

kfoltman

PaulBrewer wrote: »

You speak with some authority kfoltman.
Is this an area of your expertise ?

Well, it depends on what you expect.

I did write some native audio processing plugins - but nothing "pro" and almost all of them were freeware or open source. Some plugins for ancient amateur audio software called Buzz, and some plugins for Linux audio APIs (Calf audio plugin pack). I don't know RTAS, but having to deal with a couple of other audio plugin standards in the past (Buzz, VST2, Fruityloops, LADSPA, DSSI, LV2), I don't expect it to be significantly different in terms of programming difficulty.

I've also tried writing some fixed-point audio processing code for a Chameleon device, based on Motorola fixed-point DSP (56307?), similar to the one used by TDM platform. Unfortunately, nothing interesting came out of it. But it gave me enough experience to personally find out how fixed point DSPs are an utter pain in the neck to code for, comparing to x86.

Also, my daily job involves software engineering and heavily optimised C and C++ code. Nothing audio-related though.

PaulBrewer

kfoltman wrote: »

Well, it depends on what you expect.

I did write some native audio processing plugins - but nothing "pro" and almost all of them were freeware or open source. Some plugins for ancient amateur audio software called Buzz, and some plugins for Linux audio APIs (Calf audio plugin pack). I don't know RTAS, but having to deal with a couple of other audio plugin standards in the past (Buzz, VST2, Fruityloops, LADSPA, DSSI, LV2), I don't expect it to be significantly different in terms of programming difficulty.

I've also tried writing some fixed-point audio processing code for a Chameleon device, based on Motorola fixed-point DSP (56307?), similar to the one used by TDM platform. Unfortunately, nothing interesting came out of it. But it gave me enough experience to personally find out how fixed point DSPs are an utter pain in the neck to code for, comparing to x86.

Also, my daily job involves software engineering and heavily optimised C and C++ code. Nothing audio-related though.

You think that's good ?
I wrote a program to move a drill on the X,Y axis (where to drill) and the Z axis (to actually drill a hole ) in 1980 in Hexidecimal !

Floating Point that ! :mad:

Seriously, it's interesting to have an educated under the hood observation here. Ta.

studiorat

kfoltman wrote: »

I've also tried writing some fixed-point audio processing code for a Chameleon device, based on Motorola fixed-point DSP (56307?), similar to the one used by TDM platform. Unfortunately, nothing interesting came out of it. But it gave me enough experience to personally find out how fixed point DSPs are an utter pain in the neck to code for, comparing to x86.

Hello World!


Oh yeah I love my URS plug-ins...

kfoltman

studiorat wrote: »

Hello World!

LOL! No, that wouldn't have required writing assembler code. The LCD and the rest of the panel was handled by a Coldfire microcontroller(?), and the SDK contained some sort C compiler for it.

No, it was a rather boring delay effect. Possibly with some lame 1st order filter in the feedback loop to make it more interesting, don't remember. It was somewhere around 2002 or 2003, when a rackmounted uploadable-firmware-based audio device with 2x16 character LCD, a couple of knobs and buttons, MIDI, stereo analog in/out and a single dedicated DSP was still considered a good idea

PaulBrewer

I'm pleased to announce Audio Warehouse has been appointed Irish Dealer for URS plugins !

I'm looking forward to get URS out and about more on the Irish scene.