Matching Gain Before And After Effects
-
@fpelle Sorry this was 3 years ago and I don't have that snippet anymore, I'm no longer using HISE or making virtual instruments, I just stick around here and follow what people are up to
-
@iamlamprey wah! But what happend to neat player?
-
@d-healey the source is still on github, i stopped because it was bleeding money and i lost the motivation to keep making instruments (sampling, editing, etc)
-
@iamlamprey Oh that's a shame. It seemed like you were onto a good thing.
-
I could use something like this.
The level going into my scriptnode effect is X the level coming out is Y. Is there a scriptnode method to work out the difference and apply the reverse to a gain module so I get roughly the same volume out as in?
-
@d-healey Didn't we go over this? :face_with_tongue:
-
@aaronventure Apparently not, see my last post in the thread
-
@d-healey
You need an automatic gain detector and gain updater to compensate the I/O gain difference in the scriptnode, right?Which kind of effects will there be?
-
@orange Yeah. I have a convolution node followed by a filter.
-
@d-healey The thing is there's no real method afaik. You don't wan't to apply the gain difference to each samples, so there should be an integration happening somewhere. I think two enveloppe followers for IN & OUT signal with same settings should give you the difference you need. Then from here, I guess it's a matter of dB calculation.
I tried in the past. I'm sure it can work but I stopped before going further once I just told myself this would necessarily create some gain fluctuation at some point. The user won't have the possibility to get the control over these fluctuation, and they will also be frequency dependant.
In my opinion, gain compensation should be a fixed value determined during effect development, but that is just me thinking :man_shrugging: (or a value that is changed with some FX parameters)
-
@d-healey I think, each effect needs different approach.
For example the gain compensation method used for preamp modeling and the method used for reverb are different from each other.Christoph suggested this normalizing method for the convolution reverb a while ago.
HiseSnippet 1495.3oc0X8zaaTDEeVmLND2Vfp1BWmKHbjJF6RnTARTm3jzZAN0pNDUNElr6X6Qd2YV1c1jXPbhK8Fm6M9HvUt0u.bpeQ3a.7d6t16t0tINVsEgsj0Nu4My768989yrtaf1VDFpCHVqevXeAw5pzdiUlgsFxkJR6cHVuKsCOzHBXIh1drOOLT3PrrV4An.q0WkD+4uu+1bWtxVjIhPNTKsEeqzSZxj1s42Hcc2i6HNP5kS6Ma11VqZoc0Q.dVgVm3ysGwGH1mipUhRrJuqiznC5Y3FQHny1Zmw8FpOUkn+gxP4wtBbPCROXiRDSZMT55zchsFRHVq1MyxWIwxuIsizQNUdlG38imfksh79.qRmGjZbIfjUNHsZBjtNsmcfz2jMChmqPaq.BoOGb04gRhtDqmSaoAETlZd7Qh8BfASWP06Vu9sYvOa7U8iT1FoVwzp80FwiTU2nxOWY8J+RE1KOU+9ycN7XBztthf4NMxtAm2Bqph7NVDba1Ib2HwTEAyunOs7h4SsSr5bJpUsURyi7Eoi2S65f9J74YY.RpaCd56ZuC2vQRIUFnmuHvHQ3Xsi3DHpNghVmtiHbjQ6Cw0yvePji1IxkaJFNg4MoS.9iBbHRTpPoYb97pKQLV8yMFaQg30ockF6gyGiklCFAO0aBLllYdM5t86KrMY.bU5dOYYSCqu3ogzjyuRZZHbl3ge0zgr8dRiBfX+Hushbj58jtHFnVVf4LIq7ozrL.+.gOOPbftqKeb0Ptmuq3w.vuM6XWs8ndxeRLaZieBt1F0np8PtRIbCWlrqxulpXQdrNxHUC5vMAxy.6Er+dPsaaQqTzg9fRXhUx353XLXomP4DO3efOoS1XpCClrwjIykStuvbpNXTLGk9LXKIDRXrS9n9m0frkqq9zVZOeYZnKPLwx5pcG6OTqj1nnDMlfzs7zQvgjB2GxCOfKcwX8CEAgwaxZz50fuPb99ZGv4P2iaCNwwc4lgXBCV7AhNEA0rmFkV.WEBTfsXRetDOB.GOzLi6xsRtpMIAj3HHcqTxt1N7PbVatK4PjaQfRv8DUmlhOT0qgv5DsaTrin.huEsuzEZJDVKuJKKHwofX3ylT0LWZP9QPhaaki3rIa3tP.pCTQNdYoLdGoJ0nRzoC+rBiIc4Av8APniV6zQPrP1RypKks7r5o8LBeLGqfrQhSSbP4khNwxP8ZifLytPtzGcyeq4k6nqP6FHbDPQBxL69Eb7e+ym0xgbqhG+u+rm8myd7Oevebql3wC81fRSPF9k9z2r4Lm9SewhY7M+Uu+J13Wi9PYqHCYlsg7lmyuFsSjqQZFFH3Nyw5yki8dXhj3Hth6NNDfTgrrOLtt.TLtVQkVv7rlzdBCyLTFxLZVWAeDiqbXQgBPnfAMNfeb0FFOLVPtTYlJFhqdtkRJiM+mFZWlhm.39l11+.dv.gIL8dPJgcRA03RfscvRQ1bnUwQhy7CxXEbl0nIa5+UEFxyPEPYA54lSombZrfbyCnR0IfuL1wO.J4ypdJDvv3.szWLHhG3vB0vrbC6Gi.ZLTN.n+PliV8wFrQ+orH+Md4p8klghZkih9H3P8iLrulA8hZvtOqZiZ0YeZrvMXeIK9g3qPkeOVCti5wQCx0rXwo3qD2BA1LwqhgKTO1JWt4ZKetITo5UlaN4fmYq2Jxn8fR0NS6GlF.j2FJv+2Hi+mpvBR+evj8DyLcD1xig66T4h5cWLga832D3NNaeYx4JSwfshbQ43M5+CTQJ5KvBH8DHpM3k+6EtfKfTpvEPJX5qb9l98lSuw60bg5MV3VA.du.K+0vUDlON9garyKteRrcOOsFZQLaW5Ma9V3NBWk9XQnv7JhCJVSdasdjGO9J7K2aX+13EN731A5iRqKfASuSrDHnRE+2PsNsCNl0fbRZ2G7MCHdRG4Q113ql9IMHj4ul6rDq4yVh0r4RrlOeIVycWh07EKwZt24tF7emKMsCKUBB5taxEGr1Ug80iqlP9WbbZh+C
Original post:
https://forum.hise.audio/topic/8211/normalizing-audio-in-convolution-node/6
-
@orange Read Aarron's post from a few hours ago in this thread :face_with_tongue:
That normalization thing doesn't appear to be the same as makeup gain
-
@orange You're right, the approach depends on the FX itself, and on the result you want to achieve too (transparent, or as part of the effect)...
Christoph's example seems to act like a compressor, this proves the gain fluctuation issue one might have
So, should the gain compensation act as a compressor (or expander) with noticeable fluctuations, or transparently with non-input-level-dependency (apart from parameter indexation) should be the question one wants to ask first.
-
@ustk Maybe I'm too simple but my thought is if a human can look at the input volume level before, and adjust a gain knob so the output level is the same as the input, why can't this be done automatically?
-
the example of input dependency giving nasty fluctuations, might be:
- An input containing all frequencies
- A LPF in the effect, let say set to 1KHz
-> The difference between input an output will vary for high frequencies, leading to effect pumping while the output frequency content doesn't change (because those high freq are not passing through)
in short, the gain of the effect will fluctuate because of the input, while the effect itself doesn't sound different.
-
@ustk If the attack/release is slow enough it should smooth out the pumping?
-
@d-healey Saying this is just another way for what I am saying too.
A user compensating manually IS a fixed compensation (the user is not moving the knob permanently while the signal changes). So this is the "automatic" case covered by parameter compensation. (so automatic, but fixed because not input dependent, only parameter dependent)Compensation by IN/OUT comparison will necessarily introduce comp/expand like behaviour, more or less noticeable depending on the integration time (Smooth parameter in Chris's example, or att/rel of an enveloppe follower, or any integration value that a comparison requires if you don't want a sample to sample accuracy (which would be even nastier anyway)
-
@ustk said in Matching Gain Before And After Effects:
(the user is not moving the knob permanently while the signal changes
Sure they are, the knob is automatable for exactly this purpose. If the input goes up during playback they can bring down the output, and vice versa.
So maybe what I need is a threshold for the amount of variation to compensate for?
-
@d-healey said in Matching Gain Before And After Effects:
@ustk If the attack/release is slow enough it should smooth out the pumping?
Exactly you are right, reducing is not removing though, so if this is not an issue then you can go this way.
The issue is that if you reduce the integration time, it won't react fast enough and let the difference "pass-through" without being taken into account. You see, in the end you'll have a compressor/expander setting questioning. Fast enough to react or slow enough to be transparent? -
So maybe what I need is a threshold for the amount of variation to compensate for?
You are now describing limiter/compressor/expander