Where are the Sonalksis TDM plugins?

They're coming! Have some patience, eh?
I've NEARLY finished this mastering kit, just a few more pixels to poke and samples to mash.

But probably not too late next year.

Dedicated DSP VS Native PlugIn Processing

There is a difference - there are several differences. But they may well not be what
you expect them to be.

CPU Performance. Native processors have left all but the most high-end DSPs standing.
A deep-pipelined microcoded CPU like an Intel Core chip is at least an order of magnitude
faster than, say, a Motorola 56000 class DSP. It's a brutish and inelegant figure with
which to make the comparison, but the clock rate of a Core2 can be set at 3GHz,
whereas one would expect to see a 56000 DSP running at around 200MHz.

Of course, that comparison is entirely unfair- the DSP can do things that the Core2
cannot. The DSP can fetch two items from memory AND perform a multiply-accumulate in ONE
cycle (when coded correctly). That choice of instruction is not arbitrary - the most
common DSP task is to multiply-accumulate and fetch two - it's the heart of FIRs, IIRs
and all manner of other lovely algorithms. That's either three or four instructions
on the Core2, but as for how many clock cycles that would take, it's anyone's guess
- somewhere between 1 and 10 seems likely. Anyone care to correct me?

The Core2 is harder to predict the performance because it depends on many things
- whether the numbers to be loaded are in cache or need to be fetched from RAM
- whether the code is in cache or is being fetched from RAM
- what the Core was doing previously
- what the Core is doing next.

Core processors employ what's known as a pipeline. Different parts of the chip
handle different types of task, and they do so in parallel as far as is possible.
When you write an algorithm for a DSP, at the end, you count the number of lines of
assembly, and can state that the code will use N clock cycles. If you have a list of
algorithms to run, with a list of how long they will take, it's very easy to schedule
them and to know exactly how much processing capacity you need. And it is ENTIRELY reliable
and predictable to do so.

Conversely, it's very easy when writing DSP code to know when you have been inefficient.
You are going to use too many clock cycles. Working with external DSPs, you always end
up optimising to minimise your cycle count - that means using tricks and shortcuts to
get the best approximation to what you want, with as few instructions as possible.
That's great fun, in a nerdy way. For instance, a lot of dynamics processing requires
you to evaluate the mathematical functions log() and exp(). A Motorola DSP doesn't have
a log or exp function - though it does have some instructions that can help approximate it.
So when you code a compressor for that DSP, one of the fun things you have to do is
build a fast log and exp approximator. There are endless tricks. With work, you can
get close to the precision of a standard Native implementation - which are, as near as
is meaningful, exact. You'll spend a lot of clock cycles doing that on a DSP though,
and somewhere you'll find that you can trade off a bit of accuracy for extra speed.

The biggest difference between Motorola DSPs and Native processors is the fixed-point
vs floating-point difference. To make clear the difference, a floating point number
CONTAINS a 24bit fixed-point number, PLUS a scale that it can use to increase range.
A floating point number = fixed point number * 2^scale - that is, a floating point
number is a fixed point number, with a scale that can double or halve it many times.

So how can fixed-point sound better than floating, when floating can do more, is far
more accurate, and we have more processing power to throw at it? My controvertial answer
is - BECAUSE it doesn't have the range. Open up one of your sessions, right now.
Insert a clipper at 0dB after EVERY plugin. What happened? Well, it depends on how hot you
run your session - but if in general just a /little/ bit hot, you just got an overall shine
added to your mix - a noisefloor of digital clip distortion and aliasing that boosted up
your high-frequency energy and made everything a touch noisier. And you did it native!

This is the magic of dedicated DSPs - when your channel goes INTO a DSP plugin, and it's
pretty warm but not clipping, and you then add a few dBs of EQ, you clip that band on
the EQ's output. Clipping means high frequency energy, plus a touch of aliasing noise.
The aliasing noise is likely to be very quiet, but the brain doesn't mind /small/ amounts
because within a mix, it's just noise, and we, as humans, like a bit of noise. Boosting
the high frequency energy is great though - more "warmth" from the clipped bass,
more "openness" from the clipped mid and more "air" from the clipped top.
As far as I can tell, and I must state that it is only a theory, this is what lies beneath
the "bigger mixdowns" sound from using dedicated DSPs. But this is certainly not the ONLY thing.

Developing for dedicated DSP requires an investment cost - it's a filter. The kind of users
who have dedicated DSP systems are those who spend more on software. By developing exclusively
for dedicated DSP, you enter a part of the market where piracy is small (no 16yr-old kids cry
themselves to sleep wishing they could get some new cracks for their pro-DSP rig...),
and where customers are wealthy. It's also a filter in that only developers who are serious
about their algorithms will bother to afford the buy-in cost for development.
Since it's easier to develop for native, everyone and anyone can, and do.
People with deep knowledge of how to write good sounding algorithms, however, will go that
step further and develop for DSP, paying that buy-in cost in the sure knowledge that the
market will receive them.

DSP plugins cost more because the developers need to recover that cost of developing for the
DSP - nowadays people generally write code for Native and then port it to the DSP. Recovering
the cost of the Native version will spread across many many users, whereas the developer needs
the far fewer DSP users to help recover the DSP cost, which would be ill-advisedly passed on to
the Native customers. It's also a question of standing. Selling £20 DSP plugins would just seem
ridiculous to the market. It would not be likely be taken seriously.

If you want to add in a Motorola style clip to your plugin, the rough code is:
if (x>1) x=1;
if (x<-1) x=-1;

Blogging Question

Hi,

I've not been posting much recently. A big part of this is... well... I'm just deep in development work, and I'm pretty sure you're not too interested in how I refactored my UI component class (although, it's a great story... but perhaps not one for parties)... Any requests for info on anything? I miss blogging, and I'm feeling out of ideas for stuff to tell y'all...

The ongoing development process

Hi,

Here's a heads-up for interested parties.

All the plugin UIs are pretty much finished, names are decided, and so forth, so now all that remains is final tweakage of the DSP, presets, gluing extra features in, and tidying up (optimising). Then a month of beta, during which time I'll be making 2.04 more shiny ready for release... with luck you'll be tweaking by xmas.
You also get a free app to download your license files off the server too, because lots of people have trouble with the registration process, and it's not rocket science to write an app to do it for you :)
We could even put a check for updates in there (and not automatically run on startup, which is just damned annoying)..

It's been lots of fun to see the new UIs come together. I'm adding in the last touches for K-metering tomorrow, and I'll probably spend a while making the graphs even sexier.

More to follow :)

Why Chris Randall is the coolest.

In case you didn't know, you better get to know:


http://www.analogindustries.com/blog/entry.jsp?msgid=1192130114442

'cause it's like that, and that's the way it is...