Hi Dario, I think Zolzer's hysteresis is to prevent "chatter" back and forth between AT and RT when the signal level is approximately constant yielding a wobbly nearly constant target gain from the "static curve". I suppose it should be larger than the "ripple" in the envelope follower. I would prefer a "state machine", however, in which the AT phase is followed by the Hold phase, followed by the RT phase, allowing new AT phases to preempt anything going on. I don't see any need to be in a hurry to get into the RT phase, since it typically lasts a long time anyway. In fact, RT could be infinity yielding a permanent level adjustment preventing clipping at the largest amplitude seen so far. However, having it float back to nominal is typical and expected in a limiter (1/2 sec in limiter_1176_R4). That said, Zolzer's limiter should probably do what he says, but we don't know what "small" means. When the level is constant, and AT is reached, randomly switching between AT and RT should have little effect (AT doesn't want to go anywhere and RT just wants to float down very slowly). During an attack, however, switching back and forth would interrupt the exponential rise of the attack with short horizontal RT segments (going the wrong way), which would add needless distortion to the attack. I would rather look at the sign of the difference between the current gain and the new gain target coming out of the static curve, and use AT when positive and RT when negative, like an.amp_follower_ud.
- Julius On Sun, May 24, 2020 at 12:32 PM Dario Sanfilippo < [email protected]> wrote: > Hello. > > I apologise for the email overload. > > On Sun, 24 May 2020 at 10:31, Dario Sanfilippo <[email protected]> > wrote: > >> Thanks, Julius. >> >> I think that there's an error in my code. When I calculate the >> coefficients for smooth, I check if the slope is positive to select AT, RT >> otherwise. I'm thinking that if the limiter is in the AT phase, the gain >> curve must be decreasing and vice versa, right? So I should check for coeff >> = ba.if(in - in' < 0, AT, RT); >> >> Zölzer says that: "A small hysteresis curve determines whether the >> control factor is in the attack or release state". I'm not sure if >> checking for the slope gives the same result but I don't know how to >> implement a hysteresis curve. >> > > A basic hysteresis module would be this: > > import("stdfaust.lib"); > hysteresis(alpha, beta, x) = loop ~ _ > with { > loop(fb) = ba.if(x <= alpha, 0, ba.if(x >= beta, 1, fb)); > }; > process = hysteresis; > > Zölzer talks about a small hysteresis, but how small? In my thinking, the > alpha and beta thresholds can be set as the slopes of line functions with > periods AT and RT. The magnitude of the exponential slopes of the AT and RT > filters is always greater than the slopes of line functions at those rates. > Hence, if the input is strong or weak enough to properly dis/charge the > filters, that should be enough to make *hysteresis* switch. That happens > here: > > smooth(in) = coeff * in : + ~ * (1 - coeff) > with { > coeff = ba.if(hysteresis(in' - in), AT, RT); // inverted input > slope > }; > hysteresis(in1) = loop ~ _ > with { > loop(fb) = ba.if(in1 <= alpha, 0, ba.if(in1 >= beta, 1, fb)); > alpha = -1 / (t_r / 1000) / ma.SR; // negative threshold for RT > beta = 1 / (t_a / 1000) / ma.SR; // positive for AT > }; > > Full code here: > https://github.com/grame-cncm/faustlibraries/commit/7f4d0a3660b24a50349fd856228ea2b859c0d3f2 > . > > Maybe I'm doing something wrong but I'd still go for the basic limiter if > I had to choose. > > Dario > > > >> Despite correcting that, the behaviour of limiter_Z doesn't look too >> different. >> >> Dario >> >> On Sun, 24 May 2020 at 04:32, Julius Smith <[email protected]> >> wrote: >> >>> Interesting! >>> >>> Attached is my updated test and the plot it generates. At this point I >>> would go for "basic" with a reduced delay. The lookahead avoids the >>> initial overshoot, at the expense of adding 9 ms of audio latency, and that >>> can be reduced. It looks like the attack of Zolzer's is still adapting, so >>> maybe that can be pulled back. >>> >>> Cheers, >>> - Julius >>> >>> On Sat, May 23, 2020 at 5:56 PM Dario Sanfilippo < >>> [email protected]> wrote: >>> >>>> >>>> Great, my pleasure. >>>> >>>> Here attached is also Zölzer's algorithm. I'll need to double-check and >>>> see if all is correct but it might be a good starting point. >>>> >>>> Dario >>>> >>>> >>>> On Sat, 23 May 2020 at 23:31, Julius Smith <[email protected]> >>>> wrote: >>>> >>>>> Cool, these are great to have for evaluation, learning, and variety of >>>>> choice, thanks! >>>>> >>>>> - Julius >>>>> >>>>> On Sat, May 23, 2020 at 2:24 PM Dario Sanfilippo < >>>>> [email protected]> wrote: >>>>> >>>>>> >>>>>> Thanks for testing, Julius. >>>>>> >>>>>> I'll see if I can get the limiter in Zölzers book in the next few >>>>>> days and I'll do another PR with that if I manage. >>>>>> >>>>>> I've also just added the stereo version of the other limiter: >>>>>> https://github.com/grame-cncm/faustlibraries/pull/37/commits/12763e053c7fb84371cfaa17bf89f2c9a1821418 >>>>>> . >>>>>> >>>>>> Dario >>>>>> >>>>>> >>>>>> On Sat, 23 May 2020 at 22:10, Julius Smith <[email protected]> >>>>>> wrote: >>>>>> >>>>>>> Since the delay for the input path is our "lookahead delay", setting >>>>>>> it to the attack time sounds ideal to me. >>>>>>> >>>>>>> On Sat, May 23, 2020 at 12:54 PM Julius Smith < >>>>>>> [email protected]> wrote: >>>>>>> >>>>>>>> I've been happy with limiter_1176_R4_mono, but I'll now compare it >>>>>>>> to limiter_basic_mono, by offering both with a checkbox to choose, and >>>>>>>> listen for the difference (see attached test program). >>>>>>>> My limiter needs are merely to turn hard-clipping into >>>>>>>> soft-clipping for voice and tonal instruments. >>>>>>>> >>>>>>>> I believe the "limiter slope" is the compression ratio to use above >>>>>>>> threshold (4 in the case of limiter_1176_R4_mono). >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On Sat, May 23, 2020 at 3:57 AM Dario Sanfilippo < >>>>>>>> [email protected]> wrote: >>>>>>>> >>>>>>>>> >>>>>>>>> Hi, Julius. I understand. >>>>>>>>> >>>>>>>>> See this: >>>>>>>>> https://github.com/grame-cncm/faustlibraries/pull/37/commits/8f1bd1ba78ff4919637a9bfd9ec635225cfb4ba5 >>>>>>>>> . >>>>>>>>> >>>>>>>>> That's a basic lookahead limiter based on this post: >>>>>>>>> http://iem.at/~zmoelnig/publications/limiter/. >>>>>>>>> >>>>>>>>> This algorithm is even simpler: it just calculates the amplitude >>>>>>>>> profile using a peak-holder and it smooths out attack and release >>>>>>>>> using, >>>>>>>>> respectively, a one-pole lowpass and a peak envelope. Those filters >>>>>>>>> are >>>>>>>>> based on the e^(-2pi) time constant (Chamberlin's design for 1pole >>>>>>>>> filters). This time constant works in this case as the input delay is >>>>>>>>> set >>>>>>>>> by the attack of the system, so the amplitude profile to calculate the >>>>>>>>> scaling factor roughly reaches its maximum after the attack time. The >>>>>>>>> release time might be changed with some other constant, if more >>>>>>>>> appropriate. >>>>>>>>> >>>>>>>>> Personally, I'm satisfied with it but I also designed it for my >>>>>>>>> specific case, that is, stability in self-oscillating systems. I >>>>>>>>> needed a >>>>>>>>> cheap solution with low distortion; I'm not sure if this works well >>>>>>>>> for >>>>>>>>> most applications. People are invited to test and comment. >>>>>>>>> >>>>>>>>> I had a look at Zölzer's limiter, pp 231 and 232, but I don't >>>>>>>>> quite understand what "the slope of the limiter" is. What do you >>>>>>>>> think? He also doesn't mention a specific delay for the input >>>>>>>>> path but I'd assume that it is the same as the attack time. >>>>>>>>> >>>>>>>>> Dario >>>>>>>>> >>>>>>>>> >>>>>>>>> On Sat, 23 May 2020 at 01:38, Julius Smith <[email protected]> >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>>> Hi Dario, >>>>>>>>>> >>>>>>>>>> Yes the current limiter is simply a compressor, using the usual >>>>>>>>>> (causal) amplitude follower, that applies a ratio of 4 starting >>>>>>>>>> halfway up >>>>>>>>>> (-6 dB). Please feel free to make us a new one that is nicer! >>>>>>>>>> >>>>>>>>>> Julius >>>>>>>>>> >>>>>>>>>> On Fri, May 22, 2020 at 11:19 AM Dario Sanfilippo < >>>>>>>>>> [email protected]> wrote: >>>>>>>>>> >>>>>>>>>>> Hello, list. >>>>>>>>>>> >>>>>>>>>>> Am I missing something with co.limiter_1176_R4_mono? I see that >>>>>>>>>>> there is no lookahead mechanism inside and, if I test it with a >>>>>>>>>>> song at >>>>>>>>>>> +60dB, the output of the limiter is rather consistently at about 25 >>>>>>>>>>> dB. >>>>>>>>>>> >>>>>>>>>>> Best, >>>>>>>>>>> Dario >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> Faudiostream-users mailing list >>>>>>>>>>> [email protected] >>>>>>>>>>> https://lists.sourceforge.net/lists/listinfo/faudiostream-users >>>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> "Anybody who knows all about nothing knows everything" -- Leonard >>>>>>>>>> Susskind >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> "Anybody who knows all about nothing knows everything" -- Leonard >>>>>>>> Susskind >>>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> "Anybody who knows all about nothing knows everything" -- Leonard >>>>>>> Susskind >>>>>>> >>>>>> >>>>> >>>>> -- >>>>> "Anybody who knows all about nothing knows everything" -- Leonard >>>>> Susskind >>>>> >>>> >>> >>> -- >>> "Anybody who knows all about nothing knows everything" -- Leonard >>> Susskind >>> >> -- "Anybody who knows all about nothing knows everything" -- Leonard Susskind
_______________________________________________ Faudiostream-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/faudiostream-users
