Hi, Julius.
On Mon, 25 May 2020 at 03:14, Julius Smith <julius.sm...@gmail.com> wrote:
> 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
>
I agree with your points. I think that the mechanism that you describe is
implemented in the basic limiter and it works rather well.
Let's see if Zölzer answers my email for clarification and we can then try
to improve the design and consider whether it should be added to the
library or not.
Dario
>
>
> On Sun, May 24, 2020 at 12:32 PM Dario Sanfilippo <
> sanfilippo.da...@gmail.com> wrote:
>
>> Hello.
>>
>> I apologise for the email overload.
>>
>> On Sun, 24 May 2020 at 10:31, Dario Sanfilippo <
>> sanfilippo.da...@gmail.com> 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 <julius.sm...@gmail.com>
>>> 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 <
>>>> sanfilippo.da...@gmail.com> 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 <julius.sm...@gmail.com>
>>>>> 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 <
>>>>>> sanfilippo.da...@gmail.com> 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 <julius.sm...@gmail.com>
>>>>>>> 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 <
>>>>>>>> julius.sm...@gmail.com> 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 <
>>>>>>>>> sanfilippo.da...@gmail.com> 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 <
>>>>>>>>>> julius.sm...@gmail.com> 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 <
>>>>>>>>>>> sanfilippo.da...@gmail.com> 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
>>>>>>>>>>>> Faudiostream-users@lists.sourceforge.net
>>>>>>>>>>>> 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
Faudiostream-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/faudiostream-users
