ReaComp knee size bug (FIXED)

[mawi]

The knee size gets very weird when I raise it.


That's the way the knee should be.

[ReaNico]

This is a very old bug, I never knew how to report it.

[mawi]

Just a reminder.

[JamesPeters]

I'm guessing this is testing the 32-bit VST plugin that's not part of Reaper but the ReaPlugs pack, based on the VST plugin tester you're using. (Unless there's one that'll work in Reaper, or a 64-bit version of that tester...)

Does the "built-in" ReaComp in Reaper do this too?

[ashcat_lt]

Originally Posted by JamesPeters

Does the "built-in" ReaComp in Reaper do this too?

Yep, same thing as I reported in this thread

[mawi]

I think it affects all ReaComp versions. You can test it yourself, e.g. with a sine tone. Set the sine tone to -12 dBFS. In ReaComp, set the ratio to infinity:1 (limiter) with the threshold value to -24 dBFS. If you now raise the knee, the GR should also increase and not decrease.

[EvilDragon]

It's called "character", duh!

[ashcat_lt]

Originally Posted by mawi

I think it affects all ReaComp versions. You can test it yourself, e.g. with a sine tone. Set the sine tone to -12 dBFS. In ReaComp, set the ratio to infinity:1 (limiter) with the threshold value to -24 dBFS. If you now raise the knee, the GR should also increase and not decrease.

That doesn't actually prove anything other than that the threshold kind of slides with the knee. Your input signal is low enough that if you raised the threshold 12db you'd also have less GR. In my link, I used a triangle wave which pretty much shows the gain curve itself.

It IS a real phenomenon, though. Has to do with the way the the knee "spreads" around the threshold but the gain reduction is still referenced TO the threshold. Consider that with ratio at inf:1, there is somewhere in the knee where the ratio is 100:1, and an input that hits 100db above the ratio will go out 1db above the threshold, but once it actually gets big enough to get out of the knee and hit the full ratio, it will be reduced to exactly the threshold.

There are two ways to fix this:

1) Make the knee always spread below the threshold, so that full ratio is always reached by the time you hit the set threshold.

2) Reference gain reduction from the top of the knee. This way when you set the ratio to inf, the actual real limit will be somewhere (about half the knee) above the threshold that is set.

Neither one is really "right", though I think the first is probably more intuitive. Both will "break" existing projects to some extent, so if they're going to fix it, it will need to be with a new mode so that we still have the current behavior available where necessary.

In the end, I don't think it makes much difference until you're trying to push it to some real extremes, but it definitely keeps us from reliably using ReaComp as a waveshaper.

[mawi]

@ashcat_lt
I'm sorry, I don't understand what you're writing.

Here the same test but with a different compressor. There you can very well see the GR in a graph (red dot) and how the knee should work.

-12 dBFS sine tone, ratio infinity:1 (limiter), threshold -24 dBFS, Knee from 0 to 24 dB. GR ranges from -12 to -13.5 dB.


-12 dBFS sine tone, ratio infinity:1 (limiter), threshold -12 dBFS, Knee from 0 to 24 dB. GR ranges from 0 to -6 dB.

You can see very well that by raising the knee, the GR does not become less, but larger. That's why I think the knee in the ReaComp is a bug.

[ashcat_lt]

In ReaComp, the knee "spreads" around the threshold so that you start to get some gain reduction below the threshold but don't reach full ratio until somewhere above threshold. What you showed above shows you raising the knee high enough that your signal level won't be triggering the full ratio. GR should be reduced because at that spot on the curve the ratio is lower than it had been. If your input signal was a lot louder, you wouldn't (shouldn't) see that. This in and of itself is not really a bug, but an expected part of that "spreading around".

There IS what I consider a bug. You've identified it, but that one picture you showed in the post I quoted doesn't really prove it. What does prove it is like in my thread where you can watch the signal go through the Knee from a level well below threshold to well above. In that, you see that it is possible for lower inputs to produce outputs louder than those produced by lower inputs. An input of -18dbFS might have an output of -19 while an input at -16 makes an output at -20. Those are just random numbers to illustrate the point, but ultimately that's the problem we're both trying to describe.

[mawi]

Originally Posted by ashcat_lt

What you showed above shows you raising the knee high enough that your signal level won't be triggering the full ratio.

You mean post 7 with my ReaComp test. This was done on purpose to show the bug on the knee.

GR should be reduced because at that spot on the curve the ratio is lower than it had been.

This is the ReaComp bug I showed. The GR has to increase and not decrease when I raise the knee.

If your input signal was a lot louder, you wouldn't (shouldn't) see that.

That's right, so I chose a GR of -12 dB so you can see and hear the bug well.

This in and of itself is not really a bug, but an expected part of that "spreading around".

I totally disagree. Look at post 10. There I show how the knee should work.

There IS what I consider a bug. You've identified it, but that one picture you showed in the post I quoted doesn't really prove it.

You mean the picture in post 7? I think it proves the bug.

What does prove it is like in my thread where you can watch the signal go through the Knee from a level well below threshold to well above.

I think you just found another approach to show the bug.

In that, you see that it is possible for lower inputs to produce outputs louder than those produced by lower inputs. An input of -18dbFS might have an output of -19 while an input at -16 makes an output at -20. Those are just random numbers to illustrate the point, but ultimately that's the problem we're both trying to describe.

I'm sorry, I don't understand that. But I think the bug should have become clear.

[EvilDragon]

Either way probably won't be fixed because it'd screw a LOT of projects up

[ashcat_lt]

Originally Posted by EvilDragon

Either way probably won't be fixed because it'd screw a LOT of projects up

Like I said above, it needs to be a new mode much like they've got that "classic attack" thing.

I am a little disappointed that it hasn't even been addressed that I can recall. Justin jumped right onto the thing with GR topping out at 150. Fixed next version, but I haven't heard a peep on this one.

I fear it's one of those things where it looks like I'm trying to do extreme things that it's not meant to do, but I do believe it affects more typical usage as well. With less extreme settings it's far less noticeable, but it's definitely not right.

But IF this was fixed, it would make ReaComp a super powerful tool. I could throw out all of my JS saturators and save all kinds of CPU ticks in so many of my FX chains!

[EvilDragon]

Yeah, a new mode/checkbox is probably the only way to go about it.

[Justin]

ReaComp is getting a "Quirks" button haha. Moving "classic attack" in there too. Next builds should have this fixed (and same goes for ReaXcomp).

[ashcat_lt]

Originally Posted by Justin

ReaComp is getting a "Quirks" button haha. Moving "classic attack" in there too. Next builds should have this fixed (and same goes for ReaXcomp).

Yay!!! This going to change my whole life.

[ReaNico]

Originally Posted by Justin

ReaComp is getting a "Quirks" button haha. Moving "classic attack" in there too. Next builds should have this fixed (and same goes for ReaXcomp).

That would be great! And option to unlink channels?

[Justin]

The development pre-releases have a fix (and a related ReaXcomp fix).

[mawi]

Thanks a lot! I tested it briefly and it seems to work as expected. Will the ReaPlugs VST FX Suite also be updated?

[ashcat_lt]

AAAAAAAHHHHHHHH!!!!!!



Seriously though. It's a whole new world. Throw out all your saturation plugs. ReaComp is more efficient and more flexible. It's going to save me so many CPU ticks on my live rig.



Thank you for your attention on this matter.