I’ve found the metering for gain reduction to be a little odd on the native Renoise standard compressor. I just ran some tests and it doesn’t seem to be functioning how I’d expect…
Firstly i noticed that if you set the ratio to 1.000:1, it’s still possible to get gain reduction if you set a low threshold… This shouldn’t happen as having a ratio of 1.000:1 shouldn’t alter the compression transfer curve…? For instance, on 1.000:1 ratio with a low threshold it says I’m getting upto 3db of reduction. Surely I shouldn’t be getting any reduction at all on this ratio? I found that knocking the compressor in and out and comparing the peak values on my master track, it is reducing the peak value by 0.6db (again it shouldn’t be anything?). My test session is simple with no other plugins running.
I’ve also been playing around with some interesting nulling between tracks today and I found that if you setup so that two tracks are nulling, and then add a cabinet simulator on bypass on one of the tracks, it doesn’t null anymore as it should. I take it that the cabinet simulator introduces a tiny amount of latency because it is impulse based? And it retains this latency when it is bypassed. I had the Latency Plugin Delay Compensation switched on - you’d think that this would stop this happening…
It’s a minor thing tbh, but a drawback of this is that if you mix a cabinet simulator on a send track with the original track signal, you’ll probably get some slight comb filter/phase weirdness. Then again, you’ll seldom do this as the plugin has a wet/dry mix anyway… Unless you’re getting into some more complicated parallel processing. But at the moment it seems the PDC for this particular plugin doesn’t quite work properly - maybe it reports an incorrect latency? or none at all?
Note : I didn’t listed the latency produced by the Multiband Device although some of us have noticed some unexpected latencies especially when placed on a send track. Theorically, the Multiband Device is based on filters and filters have no latency problems, so it should be a zero latency thing.
Theorically those latencies create a phase difference, that could lower or block destructive interferences and cancellations.
For example, in a track 01 track, just add for example a "send’ device, send to s01,“keep source”, a gainer with phase inversion, then a gater you’ve switched off. Even if the gater is off, the device itself will create a small latency in the track timeline and will neutralize the antiphase.
The PDC means “plugin” delay compensation, so is is just able to compensate latencies on the VST/VSTis/AU plugins and not the native devices that are NOT working on the same code framework.
Hey… Yes, I just tried your example, and if the gate is switched off, then yes, I get a complete null, as expected - right?
and it nulls with a bus comp switched off, a standard comp switched off, etc… which is how i’d think beacuse the PDC is working. but put a cab sim in and it doesn’t null, hence i don’t think the PDC is quite accurate for this plugin
Was going to ask when I saw these on the other thread but I didn’t.
Is there a missing zero on the two I have highlighted?
Wonder because they are the only ones longer on a normal track than a send and I find 50-60mS a bit too much to believe. The extra ~10mS for the rest being on a Send is bad/hard enough.
A plugin is something “external”. VST plugings are built on a very specific framework defined by Steinberg. This framework is different from the very specific way Renoise is working internally. DSP devices are not VST devices.
To compensate phase differences you will need a phase compensator.
yes, you’re right, I’ve forgot a zero. sorry. I’m so lazy.
Incorrect, as you’ll see with your own example - switch the PDC on and off - you’ll get different results!
With PDC off, your example works as you described, having the gate in the chain will mean you’ll hear sound (and if you listen carefully the resultant sound is a comb filtered one due to the delay time differences, the sum has a different character to track 01 on its own).
With the PDC on, if the gate is in the Device Chain, it will null with the send, and if it’s not there, it will also null with the send (to me, this seems more “proper”)
I can’t really see why people wouldn’t have PDC switched on to be honest, especially if you do lots of parallel processing etc. I can cope with the miniscule extra latency it adds into the whole system (I tend not to use many heavy plugins anyway) and things generally behave as I’d expect. (except for the cab sim, as I was saying…)
Yes I see what you are saying with the “plugins” terminology, but if I’m gonna get a bit pedantic… The Renoise native devices are actually shown in the “Select/Organise Plugins” list, so I dunno… OK, they’re not external… But native devices/native plugins… It’s interchangable?!
You got me ha ha ha. . Well the gater-based example I’ve provided only works when automatic plugin delay compensation is OFF. When saying that a DSP is not a VST I wanted to find a reason or an excuse that could explain why the cabinet simulator is not properly compensated by the PDC system. After that, I don’t know how the PDC is exactly working internally and how the hell the cabinet latency isn’t properly detected and then properly compensated.
Workaround idea : if the PDC does not work, maybe if you 've got a normal track signal you’ve sent in a “send track” with “keep source”, and if you’ve got a cabinet active in the send track, the only way to avoid side effects, would be to add an inactive cabinet simulator device in the source signal in the source track. It is not a true multitrack compensation, but maybe could avoid the comb side effect you described. I did not took time to fully test it but it could work, tell me what you think about this idea.
