Tokyo Dawn Labs - Feedback Compressor II - beta 3

[FabienTDR]

beta 3 now available for download:
http://www.tokyodawn.net/tdr-feedback-compressor-2/

Changes:

- Fixed a bug introduced in beta 2 that made the compression ineffective.
- Fixed a bug appearing at rates equal or above 88.2kHz.
- corrected some presets.
- New LED graphics.

Many thanks to all contributors!!

[DuX]

mmmmmm only 8 samples of latency, down from 184, and the CPU is down to 1.3% instead of 1.4-1.5. Me likey!

[FabienTDR]

mmmmmm only 8 samples of latency, down from 184, and the CPU is down to 1.3% instead of 1.4-1.5. Me likey!

Yes! But this is only the case for sample-rates above 48kHz.

I'm still asking myself if I should add another super-sonic smoothing filter to improve the 96kHz results even more (currently, the comp runs super fast at rates equal or above 88.2kHz, but the measurements are slightly worse than those with the first oversampling stage). Will have a closer look at it soon.

btw, the cpu should drop again in the next update. Probably about 25%, maybe more.

[DuX]

Well, 96kHz is the "only case" for me, so I'm happy. Really, some plugins apply unnecessary oversampling even when you work at a higher samplerate and don't let you to disable it. But on the other hand, some things can never get oversampled enough. Oversampling is the new witchcraft in DSP, man. Not so new, but as far as plugins are concerned it goes just maybe 5-6 years back. I'm not one of those who think higher sample rate is a solution for everything, though. I think 96k is the shizz [sorry for the US slang, I've been watching "Breaking Bad" series too much lately], and I've been reading and like what Dan Lavry has to say about it. That's considering hardware AD/DA, of course. Computers and DSP is a bit different. Gosh, I don't want to open the Pandora box [again]. All just to say: Thank you for being considerate to us 96k users! As a sidenote, if you think there should be some more super sonic [lol] filtering involved, I wouldn't be against it if you think the results would be worth it. You strike me as a nitpicker so far, in a good sense, since I'm one, too. What doesn't hurt, can't be bad. Everything to about 64 samples of latency is not an issue at all for me. For me.

A little side-question: You don't happen to release Synth, EBM, and Industrial stuff on the TDR label, don't you? I've been browsing your website. It's not that I'm a 100% fan of just these genres only, my taste in music is incredibly wide. I'm just interested in knowing what your label is mostly interested in.

Cheers!

[kvaca]

So that's why I thought of the new one as "much more subtle" than the beta 1. I thought you wanted it that way, since it's meant to be a compressor for mastering and busses, and I never compress more than 6-10dBs anyway, usually 1.5:1 to about 3 or 4:1 at the most, especially on the busses. So I didn't notice it! I did test beta 1 far more thoroughly, though.

If you want to get the most compressed sound out of FB II, just put the "peak crest" to 12dB, that should be more of a peak compressor than RMS compressor. As Fabien said, "Peak Crest" could be described as a blending control between the peak and RMS compression, and RMS is always more subtle, appropriate for busses and mastering. You shouldn't boost the "soft knee", either. For heavy compression leave it at 3dB or lower it to 0. For busses it's better for soft knee to be at 3-6db, or even all the way clockwise.

Having said that, I can't wait to try the fixed one and see how it "squeezes" things, too!

yep-now it can squeeze fine

but-my intentions were not in getting that bricky sound at all, I have found that beta 2 bug when comparing this comp to the best one /splitcomp/...Im using rather rude technique which I would never use in normal situation--as you have written 6-10 db is more than enough for mastering, but if you want to test compressor to clearly hear what compression is it capable of without unpleasant artifacts take over you need to push things really hard

btw-artifacts happen always...in normal situation like in my stress test,only we are not able to hear them as clearly as in stress test, becouse of various reasons...

[paterpeter]

If you want to get the most compressed sound out of FB II, just put the "peak crest" to 12dB, that should be more of a peak compressor than RMS compressor.

Shouldn't it be the other way round? That is, a low peak crest causes more peak compression? A high peak crest will allow more transients to slip through as it raises the threshold for peaks, causing mainly RMS compression.

[kvaca]

If you want to get the most compressed sound out of FB II, just put the "peak crest" to 12dB, that should be more of a peak compressor than RMS compressor.

Shouldn't it be the other way round? That is, a low peak crest causes more peak compression? A high peak crest will allow more transients to slip through as it raises the threshold for peaks, causing mainly RMS compression.

you are totally right BUT...his advice maybe has one reason- remember that if you set the crest 12db you need to set the threshold 12db lower same time to get comparable results in peak level...please try this test on tom or snare drum hit:
set minimum attack and releases and max ratio 7:1 hard knee...and then:
1-set thresh -30 with 0db crest
2-set thresh -42 with 12db crest

compare results...
and you should get similar peak levels BUT very different sound...the 1st being WAY more compressed /like you have correctly supposed/ BUT sametime completely unusable becouse too much distorted...so at least in this case its better to use high crest to get most compressed but still natural sounding results

[DuX]

I've been wondering about how crudely I've explained it, and even misguided you, since I posted it. And besides, you're absolutely right about it being more peak compressor at 0 dB and RMS at 12 dB. I remembered it wrongly. But the thing is, my listening tests, and the dynamic range meter told me that there's a bit more compression happening when the peak crest is all the way to the right, however it is not that simple like saying this is more "peak" compression, and this is more "RMS" compression. I totally oversimplified it too much.

Thankfully, Fabien was so kind to write a manual for FB II, so we can all read and learn about it. This compressor is worth it. It is a little tricky, and you have to know what you're doing. Like, you have to know that in "LIM" mode, peak limiter is locked at 1:7 compression ratio, and when you change the ratio, you only change the ratio of the RMS compressor. In the "COM" mode, you're changing both compression ratios. Tricks like that, you have to remember them, to take advantage of this gem completely.

Thanks Kvaca! Good explanation. People should play with FB II more like that. It's a 100 tricks pony, even though someone might say "it looks simple"! Say "keydiff" button, for instance... it's effect is really interesting, but quite subtle.

Cheers!

[FabienTDR]

Small note about the Peak Crest function:

The "perfect" calibration between Peak and RMS path for a sine is ~3dB. In this sense, the 3dB crest factor can be considered as optimal, at least from the technical point of view. Compression of steady state signals will be fully controlled by the RMS path.

For Crest factors below 3dB, the peak path will begin to "attack" the steady level parts, leading to a very aggressive sound.

In most cases, peak crest values about 5-8dB deliver the most natural sounding compression to my ears.

[karrikuh]

Only tried this out shortly and it seems to be one of the few compressor plugins I can get great results with quickly. Thanks for this!

However, I have to confirm reports I read over @ Gearslutz about very high CPU usage with x64 plugin compared to the x86 version (in my case a factor of 2-3 with Beta 3). Note that I'm using Reaper x64 under Win 7 x64, so the problem really seems to lie in your x64 plugin rather than in Studio One as you have suspected in the Gearslutz thread. Hope you figure it out

[bsalter]

However, I have to confirm reports I read over @ Gearslutz about very high CPU usage with x64 plugin compared to the x86 version (in my case a factor of 2-3 with Beta 3). Note that I'm using Reaper x64 under Win 7 x64, so the problem really seems to lie in your x64 plugin rather than in Studio One as you have suspected in the Gearslutz thread. Hope you figure it out

I'm also having this problem on my system (Cubase 5.5.3, Win 7 x64). In Cubase x64 a single instance of TDR Comp v1 is over 12% on my asio meter. In Cubase x86 it is only 4%. So, I've been the x86 version bridged to x64 with jbridge, and that only takes 4%. Seems to bridge well so far.

Version 2 beta 3 x64 puts my asio meter at about 40%!

[FabienTDR]

@karrikuh, @bsalter:

Yes, there seems to be a performance problem with the x64 version. I have no idea where it comes from yet. The current x64 behaviour is really strange.

Meanwhile, I re-wrote the whole UI code and based it on a much more "modern" library. My plugs used VSTGUI before, they now use the fantastic JUCE library instead. So, some UI details changed, for example, the transfer function graph is now anti-aliased and the SC filter selection is now a combo-box instead. Further on, JUCE greatly helps me to keep up with APPLE's schizophrenic software development politics and finally offer an AU version soon (as well as VST3 and maybe RTAS on the longer run).

I am now about the rewrite the algorithm for high efficiency and will carefully test the x64 behaviour for you guys!

[bsalter]

Fabien,
Thanks for the update, glad to hear of your upcoming dev plans.

Also, I have to offer some compliments; in addition to the usual bus and mastering duties I recently discovered what an amazing job your comp does on piano, when I'm in need of fast and transparent peak control that sounds natural. Beats everything else I've tried!

[FabienTDR]

Thanks, really glad to hear about the good results.

Beside purely technical measurements, I found quality piano recordings to be particularly sensitive and revealing regarding distortion. From my observations, even the slightest trace of harmonic distortion (not even talking about non harmonic distortion) quickly pollutes the piano's distinct harmonic structure in a very audible manner. I added a piano sample to my standard test signal library long time ago... ...was a good idea I guess


BTW, I am about to upload the beta 4 later tonight. I am not really sure, but it seems that I found the source of the x64 problem in a wrong compiler setting. With the beta 4, I measure nearly identical performance for both x86 and x64 versions of Cubase and Reaper.

Contrary to what I said before, the beta 3 definitely has a much worse x64 performance, also on my system. The reason for my earlier confusion is that I didn't use the true beta 3 in my later tests, but a later build which had been fixed by coincidence. LOL

Now, let's hope the beta 4 runs fine on your systems! Many many thanks for all the patience. Later, I'll create a new beta 4 thread and send a newsletter around(subscribe for instant notifications http://www.tokyodawn.net/tdr-feedback-compressor-2/) .

[FabienTDR]

Sorry for the delay, I'm still hunting a particularly evil issue.