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
>>
>
_______________________________________________
Faudiostream-users mailing list
Faudiostream-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/faudiostream-users
