right!

How can I help you exactly with the FB thing?

Here's some valuable info about the topic (and more compressor details too):
http://www.tangible-technology.com/dynamics/comp_lim_ec_dh_p w2.html

The whole document seems weird at first, but have a closer look at the authors. There's a small section about feedback vs feed-forward at the end.

Will the TDR Feedback Comp remain free? Or only during the beta?

Will be free of course. And the next plug-in releases too.

A new update is available! I fixed a few issues, improved the performance and added an new type of side-chain filter, but it's additionally tweaked by ear to avoid a few worst-cases.

It's a complex filter made of several allpasses in parallel. It has an accurate 3dB/Oct (!) high pass slope below 1kHz, linear up to 5kHz, and fast dropping levels above 5kHz.

The 3dB/Oct high pass slope has an interesting effect that can't approximated with simple filters. The filter is based on the assumption that average music signals have an energy distribution similar to a pink noise signal (which has a slope of 3dB/Oct). The filter tries to equalizes this energy distribution in the sidechain. The sonic effect is that the compressor doesn't constantly "ride" on the lows/mid-low, the IM distortion gets reduced and potential "pumping" artifacts too. My personal favorite filter for the 2 bus.

Very nice But wouldn't that filter be considered a shelf, as DC has the ability to pass? And when you say accurate, I assume many allpasses, as opposed to only a couple filters in a shelf?

Is this compressor similar to the 1176?

@camsr: yes you're right. But DC is still reduced substantially (~25dB). I have a very asymmetric test-file just for the case, and the compressor did not go crazy. So it should be fine.

Shelves are usually made of first or second order filters. But they cannot approximate a 3dB/Oct slope, at least not over a significant range. You always end up with at least 6dB/Oct. I use a 6th order filter to approximate the slope, i.e. it consists of 6 first-order all-passes connected in a special setup.

Looks like this:



0Hz       2kHz    8kHz   20kHz
            ________
      ___---        \_
___---                \




@vaisnava: No, definitely not. The TDR compressor is much better!

Seriously, I don't care about emulations.

Good point, the shelf filter is not exactly comparable in this case. I tested out the EN sidechain mode and it brought out the mids very well. It seemed like a more balanced compression but at the same time lacked a certain character. I just guess I gotta find it's use

The BLEND thing is still confusing. Its units are dB, but when it's set to -20dB I can't figure out what is -20. Maybe a simple proportion would be better.

I like the sound of this but I think CPU performance could be improved.

@camsr: Will re-think the blend display and maybe show both percent and dB at the same time. But I'm not sure how (no room available).

@LAGinz: That Ferrari could be cheaper too. Seriously, no. I'm afraid this isn't possible anymore without compromising the current sonic behavior. I can maybe improve it by ~5% until release, but the code is already highly optimized (SSE2 wherever possible, very efficient algorithms) there isn't much I can do to improve it further.

The concept is to create quality processors without the performance/latency restrictions other, mostly commercial companies simply can't break without risking bankruptcy (there are exceptions, the slate digital compressor/limiter for example is much slower).

Comparably low CPU performance is the price to pay. This plug-in is dedicated to mastering applications, so CPU is not an issue. All other use-cases are not supported (officially).

But you can run your projects at 96kHz (or 88.2kHz), in this case, the plug-in will run much faster because the most demanding part of oversampling can be skipped.

But what about an option to only oversample during offline rendering?

The compressor algorithm must run at least at 176800Hz "by design" (4x 44.1kHz).

Most of all, the feedback loop must be shortened smaller than one sample to sound properly, antialiasing being just a "secondary" benefit. In most cases, little aliasing doesn't matter sonically in compressors, ironically, most amateurish users (no pun) actually like the hard/harsh/noisy/metallic sound of aliased compression/limiting. But the feedback part really sounds horrible without oversampling. This is an essential part of the algorithm I cannot skip without totally changing the sound of the compressor.

Since the algorithm already runs at such a high rate, I was able to add the optional "color" section without problems, especially the HF section which would otherwise pollute the signal with huge amounts of aliasing (much more than the actual compression would do).

Actually, designing such an advanced digital compressor is not about "sticking" lose modules together. All elements must closely interact which each other, the design only works as a whole. The compression algorithm is intentionally "allowed" to fvck around with everything above 1/4 of the bandwidth - because it knows the decimating filter will properly remove that crap later. Now, remove the oversampling and you'll have horrible distortions above 1/4 of your bandwidth, probably everything above 5kHz!

Seriously, there's a gazillion compressors out there "optimized to death". There's actually a reason why the FB comp sounds different.

Again, this processor is build for those who don't care about CPU (like I do). Other audiences are already widely covered and I simply don't have the time and motivation to work on mid-class processors.

Thanks for your great reply! That makes perfect sense - I just had no idea when making mysuggestion.

but trust me, I'd love to make it faster. It's definitely very slow.