Fabfilter Pro-C 3

[Ploki]

Not knocking it, I think Fabfilter makes good plugins, but let's not kid ourselves about the cost. The quality gap has shrunk significantly in the past several years to where even free plugins are nothing to scoff at. The pricing for this just isn't competitive, and as far as "catering to professionals" goes, even if it could be had for $70, your songs wouldn't be worse off nor would you be any less of a professional. Besides, better music than you or I could make has been made with much worse tools than we have access to.

All true, but i wasn't alluding to "quality" (esp sound quality) or "at release" quality.

i was alluding more to reliability (how well it works, how fast they fix bugs/release for new systems), efficiency (i can slap fabfilters across any session without even giving a shit about CPU), predictability, and workflow.

With cheaper / free options, these can be hit/miss.
Fabfilter plugins sound fine. Is it the best VariMu in town? Not in the slightest. Is it a comp i can comfortably slap anywhere and know it will survive another apple architecture nuke? easily. Is it a plugin i know won't badger me when i open the session that i need to refresh activation (thanks antares)? Absolutely.

I've spent more money on cheap plugins that went extinct or werent updated and simply stopped working, than i did on ProC2/3. Or plugins that i rarely use and can't be sold.
Given how much I've used ProC2, 60€ ProC3 update is a complete nobrainer for me.

[skarvika]

Not knocking it, I think Fabfilter makes good plugins, but let's not kid ourselves about the cost. The quality gap has shrunk significantly in the past several years to where even free plugins are nothing to scoff at. The pricing for this just isn't competitive, and as far as "catering to professionals" goes, even if it could be had for $70, your songs wouldn't be worse off nor would you be any less of a professional. Besides, better music than you or I could make has been made with much worse tools than we have access to.

All true, but i wasn't alluding to "quality" (esp sound quality) or "at release" quality.

i was alluding more to reliability (how well it works, how fast they fix bugs/release for new systems), efficiency (i can slap fabfilters across any session without even giving a shit about CPU), predictability, and workflow.

With cheaper / free options, these can be hit/miss.
Fabfilter plugins sound fine. Is it the best VariMu in town? Not in the slightest. Is it a comp i can comfortably slap anywhere and know it will survive another apple architecture nuke? easily. Is it a plugin i know won't badger me when i open the session that i need to refresh activation (thanks antares)? Absolutely.

I've spent more money on cheap plugins that went extinct or werent updated and simply stopped working, than i did on ProC2/3. Or plugins that i rarely use and can't be sold.
Given how much I've used ProC2, 60€ ProC3 update is a complete nobrainer for me.

That last point I definitely can sympathize with you on. Many a time I've reflected on the thousands I've spent on unused plugins when I could have purchased hardware instead. Coincidentally, that's precisely why I can't justify spending $200 on any single one unless I'm absolutely sure it'll be a mainstay in my projects for years and/or if it's going to replace multiple plugins and/or significantly speed up workflow as Pro-Q does.
Ah to be young and dumb, dumping hundreds into the reFX preset economy...

[babaji]

So Fabfilter asked for money after 10 years of C2 and people having problem with this?
What about your yearly investments in marketing heavy brands like Arturia, waves, izotope etc?

[bmanic]

That last point I definitely can sympathize with you on. Many a time I've reflected on the thousands I've spent on unused plugins when I could have purchased hardware instead. Coincidentally, that's precisely why I can't justify spending $200 on any single one unless I'm absolutely sure it'll be a mainstay in my projects for years and/or if it's going to replace multiple plugins and/or significantly speed up workflow as Pro-Q does.
Ah to be young and dumb, dumping hundreds into the reFX preset economy...

You'll feel even worse if you go the hardware route, dumping tens of thousands into things that you quickly realize clients don't care one iota about any more. Now you're stuck with a system that requires constant real time bounces or enough investment to be able to do everything in "one go" which quickly ends up being in the hundreds of thousands for modern productions (and it'd still suck doing recalls for clients for tiny changes).. and even then you will have those moments of A/B comparing against similar or identical plugin clones and going "man.. that 2% difference, really? really worth it?".

.. not talking about personal experience here. Nope!!

[Funkybot's Evil Twin]

Yeah, I've got some hardware comps and barely turn them on for the same reasons. Mic preamps, I feel, are a better use of money if you're tracking real instruments/people. I use those all the time.

[musicman691]

EDIT: Oh and do explore Op-El and especially the Vari-Mu emulations. Those are deep deep emulations and more importantly, extensions of famous known compression topologies. The Vari-Mu algorithm goes incredibly deep and is difficult to grasp as there are some hidden features that I discovered only a few days before release. Open up the SideChain panel and use the Side Chain Level control to sort of "bias" the tube pair that does the VariMu thing. I'm not sure if this is a bug or unintended feature but it is NOT the same as simply changing the threshold. It completely changes the behavior and feel of the Vari-Mu algorithm! I really hope it isn't a bug that suddenly gets "fixed" though.. as it's an awesome feature.


Cheers!
bM

I know you don't post over in Gearspace much (if any) anymore but I'm sure you're aware of a problem with the vari-mu bit. Not just me but another person is having an issue with the vari-mu in not having any apparent gain reduction. There is GR shown on the meter in Pro C3 but no apparent GR on the actual audio output. I started a thread over on the Fabfilter forum about this very thing and there's at least one other person with the same issue. It doesn't seem to matter where the threshold is set. If you change algo's everything works as it should. I don't know if this is what you're talking about as a possible bug. If it isn't then FF really needs to document how to work with the various modes particularly vari-mu.

I started an email contact with FF on this as there's no way to file a bug report directly on their website. Been a couple of days so I'll keep waiting.

[Phil B]

So Fabfilter asked for money after 10 years of C2 and people having problem with this?
What about your yearly investments in marketing heavy brands like Arturia, waves, izotope etc?

I, for one, have no problem with it. I just choose not to pay it. I only purchased C-2 six months ago and it was good enough for me then. So, it would take a lot less than $90 for an impulse purchase from me at this point (my upgrade price even with 4 owned products). But I have no problem with Fabfilter asking for it.

I am OK with periodic payments for my DAW, but that's it (and that's for Bitwig, so you can stretch that out to every two years or so)

[fisherKing]

So Fabfilter asked for money after 10 years of C2 and people having problem with this?
What about your yearly investments in marketing heavy brands like Arturia, waves, izotope etc?

I, for one, have no problem with it. I just choose not to pay it. I only purchased C-2 six months ago and it was good enough for me then. So, it would take a lot less than $90 for an impulse purchase from me at this point (my upgrade price even with 4 owned products). But I have no problem with Fabfilter asking for it.

I am OK with periodic payments for my DAW, but that's it (and that's for Bitwig, so you can stretch that out to every two years or so)

C2 is perfectly usable (i got SO much work done with it). but C3 is really that-much better, in terms of sound, options, capabilities. just a thought

[bmanic]

EDIT: Oh and do explore Op-El and especially the Vari-Mu emulations. Those are deep deep emulations and more importantly, extensions of famous known compression topologies. The Vari-Mu algorithm goes incredibly deep and is difficult to grasp as there are some hidden features that I discovered only a few days before release. Open up the SideChain panel and use the Side Chain Level control to sort of "bias" the tube pair that does the VariMu thing. I'm not sure if this is a bug or unintended feature but it is NOT the same as simply changing the threshold. It completely changes the behavior and feel of the Vari-Mu algorithm! I really hope it isn't a bug that suddenly gets "fixed" though.. as it's an awesome feature.


Cheers!
bM

I know you don't post over in Gearspace much (if any) anymore but I'm sure you're aware of a problem with the vari-mu bit. Not just me but another person is having an issue with the vari-mu in not having any apparent gain reduction. There is GR shown on the meter in Pro C3 but no apparent GR on the actual audio output. I started a thread over on the Fabfilter forum about this very thing and there's at least one other person with the same issue. It doesn't seem to matter where the threshold is set. If you change algo's everything works as it should. I don't know if this is what you're talking about as a possible bug. If it isn't then FF really needs to document how to work with the various modes particularly vari-mu.

I started an email contact with FF on this as there's no way to file a bug report directly on their website. Been a couple of days so I'll keep waiting.

--------------
In short / TL;DR

If your incoming signal levels are low, for instance below -9dBFS peak and maybe the RMS levels are around -18dBFS.. then you absolutely 100% have to use the Side Chain Level control or the main Input / Output combination (knobs linked in opposite direction with ALT/Option key). Boost it by at least 10dB, maybe more. Don't be afraid of pushing the input level meter into the red. Once you are closer to 0dBFS operating levels the compressor algorithm becomes a whole lot more predictable, the ratio starts making more sense and the threshold control actually does something.
--------------

Long-winded response below:

Yeah it's extremely highly input level dependent. Meaning if your audio source signal is low in volume it will behave very different compared to how it operates at higher incoming levels. You absolutely must compensate with either the Side Chain Level control or the main Input/Output pair (bottom right corner). However, note that these two options do not create the same results. Using the main input/output controls yield the same result as if your audio source was coming into the plugin at a higher level. Adjusting the Side Chain Level does something different but does indeed bring things into nominal operating levels for Threshold and Ratio to work as you'd expect.

Also remember that it's a sort of feedback system, meaning it will not correspond to normal threshold + ratio amounts of Gain Reduction, no matter how hard you try. You will end up with some signals compressing a lot and some not doing any at all, depending on many different factors (but mainly incoming amplitude plays the biggest role). Thus attack and release controls don't operate exactly as one would expect either. You can have over 100ms of Attack yet it's still constantly reacting to even the smallest of details virtually instantly if the variable biased path differs in amplitude.

Here is a nice little article on Vari-Mu topology. If you can fully grok what is said there you will start to understand WHY these systems are finicky and difficult to setup. You'll also quickly realize why virtually all such hardware has a few set controls and very small ranges.. aka they are "preset" setups tailored to certain ranges).

It's not at all a simple algorithm and perhaps it wasn't a wise choice to include this in Pro-C3 due to the nature of the free and predictable operation it's known for. I suspect the main point of the algorithm is to work in a Mixbus / Mastering / Drumbus context where peak levels almost always are close to 0dBFS or at the very least in the -3dBFS to 0dBFS range. That's when it operates most predictably. If you try to throw it on a backing vocal that was recorded at -20dBFS peaks and average levels even lower, you have literally zero chance of getting any predictable compression going at all.. even if you dump the threshold to -60 (because it's NOT a normal threshold control at all).

Experimentation is the key here and throw ALL your preconceived notions on how compressors should work out the window when you use the Vari-Mu algorithm. Absolutely abuse the Side Chain Level control together with the Ratio, Knee and EQ. Keep incoming levels healthy and loud. Don't forget about the main INPUT and OUTPUT controls. You can link them in opposite directions by holding the ALT/Option key down while tweaking either one of them.

What makes this so interesting and complex is that the Side Chain Level control does NOT equal the main INPUT + OUTPUT gain controls. If you boost the side chain level with +10dB and setup another identical instance but instead boost the INPUT control with +10dB (and compensate on the output with -10dB) you do not get the same results. They do not null.. not even close! This is why I think there may be a quirk in how the tube bias path is split within the model. Whatever the case is, it yields some extremely interesting and very complex compression that can be explored. Personally I'm super happy with the complexity of this beast of an algorithm. It means that there are tons of interesting tonalities and compression systems to explore in the Vari-Mu domain. It's one of the more comprehensive Vari-Mu models out there that gives you the user, a lot of control over it.

The only compressor plugin that goes even further than that is Skynext's Comprendre plugin. That takes these things into yet a completely different level that virtually nobody but crazy people like me tinker with.

Cheers!
bM

[musicman691]

bmanic: Thanks for the explanation. I've used other vari-mu s/w compressors and none of them needed the mucking about that this thing needs according to your explanation. It's NOT a typical vari-mu emulation by any stretch of the imagination. FF really needs to document what you've written here elsewise it'll just gather digital dust and piss off a LOT of users (I know it is for me). This is one of the biggest fails that FF has ever done. Better that it should not have been included because I'm sure there are others that are of the same mind I am.

I'm using it on my 2-bus as a mastering-type situation. I (and others) should be able to switch amongst the various emulations without having to screw around with settings like you mention. That you're happy with the way it works doesn't give me a warm and fuzzy feeling but makes me question your 'expertise'. Shouldn't have to get all in the weeds to get it to work. Looks like I'll be sticking with Pulsar's vari-mu emulation plugin. This is one of those things where FF screwed the pooch (and this coming from a long-time FF user).

[bmanic]

bmanic: Thanks for the explanation. I've used other vari-mu s/w compressors and none of them needed the mucking about that this thing needs according to your explanation. It's NOT a typical vari-mu emulation by any stretch of the imagination. FF really needs to document what you've written here elsewise it'll just gather digital dust and piss off a LOT of users (I know it is for me). This is one of the biggest fails that FF has ever done. Better that it should not have been included because I'm sure there are others that are of the same mind I am.

I'm using it on my 2-bus as a mastering-type situation. I (and others) should be able to switch amongst the various emulations without having to screw around with settings like you mention. That you're happy with the way it works doesn't give me a warm and fuzzy feeling but makes me question your 'expertise'. Shouldn't have to get all in the weeds to get it to work. Looks like I'll be sticking with Pulsar's vari-mu emulation plugin. This is one of those things where FF screwed the pooch (and this coming from a long-time FF user).

Maybe it is a bug? At normal mixbus levels it works just fine here? What are your settings? What are you experiencing as the issue?

[kraster]

bmanic: Thanks for the explanation. I've used other vari-mu s/w compressors and none of them needed the mucking about that this thing needs according to your explanation. It's NOT a typical vari-mu emulation by any stretch of the imagination. FF really needs to document what you've written here elsewise it'll just gather digital dust and piss off a LOT of users (I know it is for me). This is one of the biggest fails that FF has ever done. Better that it should not have been included because I'm sure there are others that are of the same mind I am.

I'm using it on my 2-bus as a mastering-type situation. I (and others) should be able to switch amongst the various emulations without having to screw around with settings like you mention. That you're happy with the way it works doesn't give me a warm and fuzzy feeling but makes me question your 'expertise'. Shouldn't have to get all in the weeds to get it to work. Looks like I'll be sticking with Pulsar's vari-mu emulation plugin. This is one of those things where FF screwed the pooch (and this coming from a long-time FF user).

I don’t think you can realistically expect the controls of a completely different, comparator-based style of compression to map cleanly onto a vari-mu style.

With a vari-mu compressor I’d always treat input gain as the effective threshold, and if threshold and ratio controls exist on a vari-mu they’re usually doing something else (like shifting the operating point or changing the curvature of the transfer curve) — rather than behaving like the typical comparator-based approach used in other compressor styles.

Vari-mu compressors use changes in tube transconductance for gain reduction, effectively pushing the tube into regions where it’s less capable of amplification. At lower input levels there’s very little compression because the tube is operating in the more linear part of the transfer curve.

Input level is what pushes a vari-mu into compression, so it’s the single biggest control you have for instigating gain reduction.

This isn’t “getting into the weeds” — it’s understanding how these designs are supposed to work.

In the case of something like Pulsar's Mu or the various Fairchild emus it's a lot easier since they are direct emus.

FabFilter didn’t screw the pooch here, and bmanic’s understanding is solid. If it’s behaving differently than other “vari-mu” plugins, that’s likely because you’re comparing circuit emulations to an algorithm that’s adapting vari-mu behaviour inside a modern control framework.

[bmanic]

FabFilter didn’t screw the pooch here, and bmanic’s understanding is solid. If it’s behaving differently than other “vari-mu” plugins, that’s likely because you’re comparing circuit emulations to an algorithm that’s adapting vari-mu behaviour inside a modern control framework.

This is exactly it! Said with much better and more intelligent wording than I could ever come up with.

FabFilter squeezed an exact and true Vari-Mu system on to conventional controls and it takes some time to learn the ins and outs of that system.

Easy mode is this: just dump hot input levels into the plugin either via the Side Chain level control or the main in/out level knobs. Then threshold and ratio will be at easy to operate nominal settings. If you need to compare between algorithms, use the A/B slots for that.

[joshmakesmusic]

Huge!!

[NAD]

[...] note that these two options do not create the same results. Using the main input/output controls yield the same result as if your audio source was coming into the plugin at a higher level. Adjusting the Side Chain Level does something different [...]

[...] the Side Chain Level control does NOT equal the main INPUT + OUTPUT gain controls. If you boost the side chain level with +10dB and setup another identical instance but instead boost the INPUT control with +10dB (and compensate on the output with -10dB) you do not get the same results. They do not null.. not even close!

Would it be possible to get perhaps a qualitative if not a technical description of the difference?