Hello.
On Tue, 20 Jul 2021 at 22:14, Klaus Scheuermann <kla...@posteo.de> wrote:
> Hi Julius,
>
> I don't see a -70db lower limit... where is that?
>
> Besides... because
> zi = an.ms_envelope_rect(Tg);
>
> seems really buggy, I am using Dario's workaround
> lp1p(cf, x) = fi.pole(b, x * (1 - b)) with {
> b = exp(-2 * ma.PI * cf / ma.SR);
> };
> zi_lp(x) = lp1p(1 / Tg, x * x);
>
> which gives me the 'crash'.
>
Unless Tg is 0 at some point, the crash shouldn't come from there.
The crash happens if you start the process with audio file selected as
inputs, hence zeros, so you may be dividing something by the input signals.
Ciao,
Dario
> I cannot switch to double precision in the online faustide, right?
>
> Thanks, Klaus
>
>
> On 20.07.21 21:46, Julius Smith wrote:
>
> Hi Klaus,
>
> Thanks for sharing master_me!
>
> Your envelope looks safe because of the -70 dB lower limit.
>
> You might try running everything in double precision to see if that has
> any effect.
>
> - Julius
>
> On Tue, Jul 20, 2021 at 3:13 AM Klaus Scheuermann <kla...@posteo.de>
> wrote:
>
>> When the input lufs meter goes to '-infinity', the audio mutes and some
>> GUI parts disappear.
>>
>> On July 20, 2021 11:59:57 AM GMT+02:00, "Stéphane Letz" <l...@grame.fr>
>> wrote:
>>>
>>> « crash at silence » ? what does that mean exactly?
>>>
>>> Thanks.
>>>
>>> Stéphane
>>>
>>>>
>>>> Le 20 juil. 2021 à 11:55, Klaus Scheuermann <kla...@posteo.de> a écrit :
>>>>
>>>> Good day to all!
>>>>
>>>> All my TO-DOs are DONE - woohoo :) Here is the
>>>> code:https://faustide.grame.fr/?code=https://raw.githubusercontent.com/trummerschlunk/master_me/master/master_me_gui.dsp
>>>>
>>>> The only thing that still behaves weird is the envelope in the LUFS
>>>> measurement section as it will crash at silence.
>>>> Would anyone have some time to look into it?
>>>>
>>>> Thanks for all your help!
>>>> Klaus
>>>>
>>>> On 17.07.21 18:03, Klaus Scheuermann wrote:
>>>>>
>>>>> Or maybe the 'gating' is better done in my 'leveler' section to keep the
>>>>> continuous lufs metering specs-compliant?
>>>>>
>>>>> I guess that is a good idea ;)
>>>>> This way I can specify the gating characteristics.
>>>>> (I will probably need some help with this...)
>>>>>
>>>>> my TO-DOs:
>>>>> - slider for target loudness in lufs
>>>>> - new leveler section slowly adapting loudness to target loudness
>>>>> - gating: freeze leveler when silence is detected on input
>>>>>
>>>>> Almost there ;)
>>>>>
>>>>> By the way, does an.ms_envelope_rect() work correctly now?
>>>>>
>>>>> Cheers, Klaus
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On 17.07.21 15:30, Klaus Scheuermann wrote:
>>>>>>
>>>>>> Dear Juan Carlos,
>>>>>>
>>>>>> thanks so much for looking into the gating. I agree, we have 'momentary'
>>>>>> (Tg=0.4) and 'short-term' (Tg=3).
>>>>>>
>>>>>> I read some more about the secs from the EBU and I understood, that
>>>>>> 'integrated' is not quite what I need for 'master_me' as it is specified
>>>>>> with a user interaction of play/pause/reset. (from:
>>>>>> https://tech.ebu.ch/docs/tech/tech3341.pdf)
>>>>>>
>>>>>> The ‘EBU Mode’ loudness meter shall at least provide functionality that
>>>>>> enables the user to –
>>>>>> 1. start/pause/continue the measurement of integrated loudness and
>>>>>> Loudness Range simultaneously, that is, switch the meter between
>>>>>> ‘running’ and ‘stand-by’ states;
>>>>>> 2. reset the measurement of integrated loudness and Loudness
>>>>>> Range simultaneously, regardless of whether the meter is in the
>>>>>> ‘running’ and ‘stand-by’ state.
>>>>>>
>>>>>> For master_me, I need a 'long-term' with gating. Or even better
>>>>>> 'variable-term' with gating ;)
>>>>>>
>>>>>> So much for now... Trying to understand your gating code now... :)
>>>>>>
>>>>>> Thanks, Klaus
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> On 16.07.21 21:32, Juan Carlos Blancas wrote:
>>>>>>>
>>>>>>> Hi Klaus,
>>>>>>>
>>>>>>> Glad to hear the project update with M LUFS meters.
>>>>>>>
>>>>>>> I did a little research, scheme and a working sketch in Max, maybe it
>>>>>>> helps you somehow but my code in Faust its not working at the moment,
>>>>>>> kind of lost with this program, 0 intuitive for me... I’m using ba.if
>>>>>>> for the gates, ba.countup+ba.peakhold for resetable counter, and for
>>>>>>> the running cumulative average this formula I found in internet; (
>>>>>>> (counter * _ ) + newValue) / (counter+1) ) ~ _; Main issue how to keep
>>>>>>> track of the values from the gates and compute the running averages
>>>>>>> with an incremental automatic counter until the next manual reset.
>>>>>>> Second round soon when get more free time.
>>>>>>>
>>>>>>> Cheers,
>>>>>>> Juan Carlos
>>>>>>>
>>>>>>> ////////////////////////////
>>>>>>> /* 1770-3 scheme
>>>>>>>
>>>>>>> (M and I):
>>>>>>>
>>>>>>> 1) K-filter (HSF+RLB)—> sliding rect window, integration 400 ms, no
>>>>>>> gate —>
>>>>>>> 2) Update the linear output of the 400 ms sliding rect window every 100
>>>>>>> ms (75% overlap, 10Hz refresh) => get Momentary LUFS (power dB, -0.691
>>>>>>> correction).
>>>>>>> 3) Absolute gate: threshold at -70 LUFS, values below are ignored, take
>>>>>>> the linear values from the 10Hz updated 400 ms sliding window —>
>>>>>>> 4) Counting every value above the gate and calculate the running
>>>>>>> cumulative average, with a manual reset button for the counter —>
>>>>>>> 5) Relative gate: compare the output of the absolute gate with a -10 LU
>>>>>>> drop of the previous averaging —>
>>>>>>> 6) Counting every value above the relative gate and calculate the
>>>>>>> running cumulative average, with a manual reset button for the counter
>>>>>>> => get Integrated LUFS (power dB, -0.691 correction).
>>>>>>>
>>>>>>> (S and LRA):
>>>>>>>
>>>>>>> 1) Sliding rect window, integration 3 sec, no gate —>
>>>>>>> 2) Update the linear output of the 3 sec sliding rect window every 100
>>>>>>> ms (75% overlap, 10Hz refresh) => get Shorterm LUFS (power dB, -0.691
>>>>>>> correction).
>>>>>>> 3) Calculate LRA …
>>>>>>> ………
>>>>>>>
>>>>>>> */
>>>>>>>
>>>>>>> import("stdfaust.lib");
>>>>>>>
>>>>>>> A48kHz = ( /* 1.0, */ -1.99004745483398, 0.99007225036621);
>>>>>>> B48kHz = (1.0, -2.0, 1.0);
>>>>>>> highpass48kHz = fi.iir(B48kHz,A48kHz);
>>>>>>> highpass = fi.highpass(2, 40);
>>>>>>>
>>>>>>> boostDB = 4;
>>>>>>> boostFreqHz = 1430;
>>>>>>> highshelf = fi.high_shelf(boostDB, boostFreqHz);
>>>>>>>
>>>>>>> kfilter = highshelf : highpass;
>>>>>>>
>>>>>>> MAXN = 262144;
>>>>>>> Tg = 0.4;
>>>>>>> Ovlp = 10; // Hz
>>>>>>>
>>>>>>> W = ma.SR*0.4;
>>>>>>> float2fix(n) = *(2^n) : int;
>>>>>>> fix2float(n) = float : /(2^n);
>>>>>>>
>>>>>>> avg400msWindow = kfilter : ^(2) : float2fix(16) <: _,@(W) : - : +~_ :
>>>>>>> fix2float(16) : /(W);
>>>>>>>
>>>>>>> overlap100ms = ba.if( os.lf_pulsetrain(Ovlp) > 0.5, avg400msWindow, !);
>>>>>>> dB = (-0.691 + (10*log10(overlap100ms)));
>>>>>>>
>>>>>>> reset = button("reset") : ba.impulsify;
>>>>>>> gateAbsolute = ba.if( dB > -70, overlap100ms, !);
>>>>>>> counter1 = ba.if( dB > -70.0, 1, 0);
>>>>>>> sampleHold1 = ba.countup(ma.SR*300, 1-counter1+reset) <: _,
>>>>>>> ba.peakhold(1-reset) :> _;
>>>>>>> cumulativeAverage1 = (((sampleHold1*_)+gateAbsolute) /
>>>>>>> (sampleHold1+1)) ~ _;
>>>>>>>
>>>>>>> gateRelative = ba.if( (-0.691 + (10*log10(gateAbsolute))) > (-10.691 +
>>>>>>> (10*log10(cumulativeAverage1))), overlap100ms, !);
>>>>>>> counter2 = ba.if( (-0.691 + (10*log10(gateRelative))) > -70.0, 1, 0);
>>>>>>> sampleHold2 = ba.countup(ma.SR*300, 1-counter2+reset) <: _,
>>>>>>> ba.peakhold(1-reset) :> _;
>>>>>>> cumulativeAverage2 = (((sampleHold2*_)+gateRelative) / (sampleHold2+1))
>>>>>>> ~ _;
>>>>>>> integratedLUFS = (-0.691 + (10*log10(cumulativeAverage2)));
>>>>>>>
>>>>>>> process = _ <: _, ( integratedLUFS : vbargraph("[0]INTEGRATED
>>>>>>> LUFS",-70,0.0)) : attach;
>>>>>>>
>>>>>>> ////////////////////////////
>>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>> El 16 jul 2021, a las 9:57, Klaus Scheuermann <kla...@posteo.de>
>>>>>>>> escribió:
>>>>>>>>
>>>>>>>> Hello Juan Carlos,
>>>>>>>>
>>>>>>>> with great help from the list (thanks!) I could implement (momentary)
>>>>>>>> lufs metering in my project:https://github.com/trummerschlunk/master_me
>>>>>>>>
>>>>>>>>> also thinking about how to do the -70 dB gate and most important the
>>>>>>>>> integrated loudness.
>>>>>>>>
>>>>>>>> Did you give this a thought? I am - once again - a bit lost here.
>>>>>>>> The specs say:
>>>>>>>> (https://www.itu.int/dms_pubrec/itu-r/rec/bs/R-REC-BS.1770-3-201208-S!!PDF-E.pdf)
>>>>>>>>
>>>>>>>> gating of 400 ms blocks (overlapping by 75%), where two thresholds are
>>>>>>>> used:
>>>>>>>> – the first at –70 LKFS;
>>>>>>>> – the second at –10 dB relative to the level measured after
>>>>>>>> application of the first threshold.
>>>>>>>>
>>>>>>>> I guess, the gating can be done with a sliding window too, right? Or
>>>>>>>> is it done in the same window we use for measurement?
>>>>>>>>
>>>>>>>> How do I gate a variable in two stages?
>>>>>>>>
>>>>>>>> Thanks, Klaus
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On 10.07.21 18:15, Juan Carlos Blancas wrote:
>>>>>>>>>
>>>>>>>>> El 10 jul 2021, a las 15:31, Klaus Scheuermann <kla...@posteo.de>
>>>>>>>>> escribió:
>>>>>>>>>>
>>>>>>>>>> Hello Juan Carlos,
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Klaus, I’m using Atom+FaustLive, Max and SC to do the tests, but I
>>>>>>>>>>> get the same crash as you with
>>>>>>>>>>> faustide/editor.https://www.dropbox.com/s/blwtwao7j317db0/test.mov?dl=0
>>>>>>>>>>
>>>>>>>>>> cool, thanks!
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Btw the reading are aprox but not the same as Youlean nor Insight2
>>>>>>>>>>> for instance…
>>>>>>>>>>
>>>>>>>>>> great, that’s promising!
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> also thinking about how to do the -70 dB gate and most important
>>>>>>>>>>> the integrated loudness.
>>>>>>>>>>
>>>>>>>>>> Yes, I was wondering about that too… Just so you have some context,
>>>>>>>>>> I don’t want to replicate an lufs meter, but I want to use lufs it
>>>>>>>>>> in my project master_me, which is meant to stabilise audio during
>>>>>>>>>> streaming events: https://github.com/trummerschlunk/master_me
>>>>>>>>>> For that I would like to be able to adjust the agility of the
>>>>>>>>>> integrated loudness. Also the gating should be adjustable.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Nice project! definitely would be great to add LUFS meters and kind
>>>>>>>>> of a loudness stabilizer with targets.
>>>>>>>>> Best,
>>>>>>>>> Juan Carlos
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On 10. Jul 2021, at 14:47, Juan Carlos Blancas <lav...@gmail.com>
>>>>>>>>>> wrote:
>>>>>>>>>>>
>>>>>>>>>>> Klaus, I’m using Atom+FaustLive, Max and SC to do the tests, but I
>>>>>>>>>>> get the same crash as you with
>>>>>>>>>>> faustide/editor.https://www.dropbox.com/s/blwtwao7j317db0/test.mov?dl=0
>>>>>>>>>>>
>>>>>>>>>>> Btw the reading are aprox but not the same as Youlean nor Insight2
>>>>>>>>>>> for instance…
>>>>>>>>>>> also thinking about how to do the -70 dB gate and most important
>>>>>>>>>>> the integrated loudness.
>>>>>>>>>>>
>>>>>>>>>>> Cheers,
>>>>>>>>>>> Juan Carlos
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> El 10 jul 2021, a las 12:17, Klaus Scheuermann <kla...@posteo.de>
>>>>>>>>>>>> escribió:
>>>>>>>>>>>>
>>>>>>>>>>>> Thanks, Juan :)
>>>>>>>>>>>>
>>>>>>>>>>>> Your code crashes my faustide on firefox and on chromium (both
>>>>>>>>>>>> linux).
>>>>>>>>>>>> Here is the error message:
>>>>>>>>>>>>
>>>>>>>>>>>> ASSERT : please report this message and the failing DSP file to
>>>>>>>>>>>> Faust
>>>>>>>>>>>> developers (file: wasm_instructions.hh, line: 918, version:
>>>>>>>>>>>> 2.32.16,
>>>>>>>>>>>> options: -lang wasm-ib -es 1 -single -ftz 0)
>>>>>>>>>>>>
>>>>>>>>>>>> When 'realtime compile' is active, the only way to gain control
>>>>>>>>>>>> again is
>>>>>>>>>>>> to delete all cookies and cache from the site.
>>>>>>>>>>>>
>>>>>>>>>>>> I'll try Dario's workaround now ;)
>>>>>>>>>>>>
>>>>>>>>>>>> Cheers, Klaus
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> On 09.07.21 18:08, Juan Carlos Blancas wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>> Hi Klaus,
>>>>>>>>>>>>>
>>>>>>>>>>>>> For me ms_envelope and rms_envelope functions are not working
>>>>>>>>>>>>> properly. I’ve done some test in my Mac Pro with High Sierra,
>>>>>>>>>>>>> porting without barograph to Max or Supercollider and I get the
>>>>>>>>>>>>> strange gate behaviour in low levels.
>>>>>>>>>>>>>
>>>>>>>>>>>>> My workaround at the moment is using ba.slidingMeanp instead of
>>>>>>>>>>>>> ms_envelope, but it’s 2x cpu intense, so I guess Dario solution
>>>>>>>>>>>>> of 1plp filter would be the best for the mean square stage.
>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> lp1p(cf, x) = fi.pole(b, x * (1 - b))
>>>>>>>>>>>>>>> with {
>>>>>>>>>>>>>>> b = exp(-2 * ma.PI * cf / ma.SR);
>>>>>>>>>>>>>>> };
>>>>>>>>>>>>>>> zi_lp(x) = lp1p(1 / Tg, x * x);
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Cheers,
>>>>>>>>>>>>> Juan Carlos
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> // Mono Momentary LUFS meter without gate of Julius, using
>>>>>>>>>>>>> slidingMeanp instead of ms_envelope
>>>>>>>>>>>>>
>>>>>>>>>>>>> import("stdfaust.lib");
>>>>>>>>>>>>>
>>>>>>>>>>>>> A48kHz = ( /* 1.0, */ -1.99004745483398, 0.99007225036621);
>>>>>>>>>>>>> B48kHz = (1.0, -2.0, 1.0);
>>>>>>>>>>>>> highpass48kHz = fi.iir(B48kHz,A48kHz);
>>>>>>>>>>>>> highpass = fi.highpass(2, 40);
>>>>>>>>>>>>>
>>>>>>>>>>>>> boostDB = 4;
>>>>>>>>>>>>> boostFreqHz = 1430;
>>>>>>>>>>>>> highshelf = fi.high_shelf(boostDB, boostFreqHz);
>>>>>>>>>>>>> kfilter = highshelf : highpass;
>>>>>>>>>>>>>
>>>>>>>>>>>>> MAXN = 262144;
>>>>>>>>>>>>> Tg = 0.4;
>>>>>>>>>>>>> Lk = kfilter <: _*_ : ba.slidingMeanp(Tg*ma.SR, MAXN) :
>>>>>>>>>>>>> ba.linear2db : *(0.5);
>>>>>>>>>>>>>
>>>>>>>>>>>>> process = _ <: attach(_, Lk : hbargraph("[1]Momentary
>>>>>>>>>>>>> LUFS",-70,0));
>>>>>>>>>>>>>
>>>>>>>>>>>>> //
>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> El 9 jul 2021, a las 16:55, Klaus Scheuermann <kla...@posteo.de>
>>>>>>>>>>>>>> escribió:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Ha, so I was really on to something ;)
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Is the bug in the meter or in the envelope?
>>>>>>>>>>>>>> Would you have a workaround for me to get on with the lufs
>>>>>>>>>>>>>> analyser?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Thanks, Klaus
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On 08.07.21 19:19, Julius Smith wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Hi Dario,
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> The problem seems to be architecture-dependent. I am on a Mac
>>>>>>>>>>>>>>> (latest
>>>>>>>>>>>>>>> non-beta software) using faust2caqt. What are you using?
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I do not see the "strange behavior" you describe.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Your test looks good for me in faust2octave, with gain set to
>>>>>>>>>>>>>>> 0.01 (-40
>>>>>>>>>>>>>>> dB, which triggers the display bug on my system). In
>>>>>>>>>>>>>>> Octave, faustout(end,:) shows
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> -44.744 -44.968 -44.708
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> which at first glance seems close enough for noise input and
>>>>>>>>>>>>>>> slightly
>>>>>>>>>>>>>>> different averaging windows. Changing the signal to a constant
>>>>>>>>>>>>>>> 0.01, I get
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> -39.994 -40.225 -40.000
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> which is not too bad, but which should probably be sharpened
>>>>>>>>>>>>>>> up. The
>>>>>>>>>>>>>>> third value (zi_lp) is right on, of course.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> gain = 0.01; // hslider("Gain [unit:dB]",-70,-70,0,0.1) :
>>>>>>>>>>>>>>> ba.db2linear;
>>>>>>>>>>>>>>> sig = gain; //sig = no.noise * gain;
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On Thu, Jul 8, 2021 at 3:53 AM Dario Sanfilippo
>>>>>>>>>>>>>>> <sanfilippo.da...@gmail.com
>>>>>>>>>>>>>>> <mailto:sanfilippo.da...@gmail.com>> wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Hi, Julius.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I must be missing something, but I couldn't see the behaviour
>>>>>>>>>>>>>>> that
>>>>>>>>>>>>>>> you described, that is, the gating behaviour happening only
>>>>>>>>>>>>>>> for the
>>>>>>>>>>>>>>> display and not for the output.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> If a removethe hbargraphaltogether, I can still see the strange
>>>>>>>>>>>>>>> behaviour. Just so we're all on the same page, the strange
>>>>>>>>>>>>>>> behaviour
>>>>>>>>>>>>>>> we're referring to is the fact that, after going back to low
>>>>>>>>>>>>>>> input
>>>>>>>>>>>>>>> gains, the displayed levels are -inf instead of some low,
>>>>>>>>>>>>>>> quantifiable ones, right?
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Using a leaky integrator makes the calculations rather
>>>>>>>>>>>>>>> inaccurate.
>>>>>>>>>>>>>>> I'd say that, if one needs to use single-precision, averaging
>>>>>>>>>>>>>>> with a
>>>>>>>>>>>>>>> one-pole lowpass would be best:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> import("stdfaust.lib");
>>>>>>>>>>>>>>> zi = an.ms_envelope_rect(Tg);
>>>>>>>>>>>>>>> slidingSum(n) = fi.pole(.999999) <: _, _@int(max(0,n)) :> -;
>>>>>>>>>>>>>>> slidingMean(n) = slidingSum(n)/rint(n);
>>>>>>>>>>>>>>> zi_leaky(x) = slidingMean(Tg*ma.SR, x * x);
>>>>>>>>>>>>>>> lp1p(cf, x) = fi.pole(b, x * (1 - b))
>>>>>>>>>>>>>>> with {
>>>>>>>>>>>>>>> b = exp(-2 * ma.PI * cf / ma.SR);
>>>>>>>>>>>>>>> };
>>>>>>>>>>>>>>> zi_lp(x) = lp1p(1 / Tg, x * x);
>>>>>>>>>>>>>>> Tg = 0.4;
>>>>>>>>>>>>>>> sig = no.noise * gain;
>>>>>>>>>>>>>>> gain = hslider("Gain [unit:dB]",-70,-70,0,0.1) : ba.db2linear;
>>>>>>>>>>>>>>> level = ba.linear2db : *(0.5);
>>>>>>>>>>>>>>> process = sig <: level(zi) , level(zi_leaky) , level(zi_lp);
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Ciao,
>>>>>>>>>>>>>>> Dr Dario Sanfilippo
>>>>>>>>>>>>>>> http://dariosanfilippo.com <http://dariosanfilippo.com>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On Thu, 8 Jul 2021 at 00:39, Julius Smith
>>>>>>>>>>>>>>> <julius.sm...@gmail.com
>>>>>>>>>>>>>>> <mailto:julius.sm...@gmail.com>> wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> I think that the problem is in an.ms_envelope_rect,
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> particularly the fact that it has a non-leaky integrator. I
>>>>>>>>>>>>>>> assume that when large values recirculate in the
>>>>>>>>>>>>>>> integrator, the
>>>>>>>>>>>>>>> smaller ones, after pushing the gain down, are truncated
>>>>>>>>>>>>>>> to 0
>>>>>>>>>>>>>>> due to single-precision. As a matter of fact, compiling
>>>>>>>>>>>>>>> the code
>>>>>>>>>>>>>>> in double precision looks fine here.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I just took a look and see that it's essentially based on
>>>>>>>>>>>>>>> + ~ _
>>>>>>>>>>>>>>> : (_ - @(rectWindowLenthSamples))
>>>>>>>>>>>>>>> This will indeed suffer from a growing roundoff error
>>>>>>>>>>>>>>> variance
>>>>>>>>>>>>>>> over time (typically linear growth).
>>>>>>>>>>>>>>> However, I do not see any noticeable effects of this in my
>>>>>>>>>>>>>>> testing thus far.
>>>>>>>>>>>>>>> To address this properly, we should be using TIIR filtering
>>>>>>>>>>>>>>> principles ("Truncated IIR"), in which two such units
>>>>>>>>>>>>>>> pingpong
>>>>>>>>>>>>>>> and alternately reset.
>>>>>>>>>>>>>>> Alternatively, a small exponential decay can be added: + ~
>>>>>>>>>>>>>>> *(0.999999) ... etc.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> - Julius
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On Wed, Jul 7, 2021 at 12:32 PM Dario Sanfilippo
>>>>>>>>>>>>>>> <sanfilippo.da...@gmail.com
>>>>>>>>>>>>>>> <mailto:sanfilippo.da...@gmail.com>>
>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I think that the problem is in an.ms_envelope_rect,
>>>>>>>>>>>>>>> particularly the fact that it has a non-leaky
>>>>>>>>>>>>>>> integrator. I
>>>>>>>>>>>>>>> assume that when large values recirculate in the
>>>>>>>>>>>>>>> integrator,
>>>>>>>>>>>>>>> the smaller ones, after pushing the gain down, are
>>>>>>>>>>>>>>> truncated
>>>>>>>>>>>>>>> to 0 due to single-precision. As a matter of fact,
>>>>>>>>>>>>>>> compiling
>>>>>>>>>>>>>>> the code in double precision looks fine here.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Ciao,
>>>>>>>>>>>>>>> Dr Dario Sanfilippo
>>>>>>>>>>>>>>> http://dariosanfilippo.com <http://dariosanfilippo.com>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On Wed, 7 Jul 2021 at 19:25, Stéphane Letz
>>>>>>>>>>>>>>> <l...@grame.fr
>>>>>>>>>>>>>>> <mailto:l...@grame.fr>> wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> « hargraph seems to have some kind of a gate in it
>>>>>>>>>>>>>>> that
>>>>>>>>>>>>>>> kicks in around -35 dB. » humm…. hargraph/vbargrah
>>>>>>>>>>>>>>> only
>>>>>>>>>>>>>>> keep the last value of their written FAUSTFLOAT*
>>>>>>>>>>>>>>> zone,
>>>>>>>>>>>>>>> so once per block, without any processing of
>>>>>>>>>>>>>>> course…
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Have you looked at the produce C++ code?
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Stéphane
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Le 7 juil. 2021 à 18:31, Julius Smith
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> <julius.sm...@gmail.com <mailto:julius.sm...@gmail.com>>
>>>>>>>>>>>>>>> a écrit :
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> That is strange - hbargraph seems to have some kind of
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> a gate in it that kicks in around -35 dB.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> In this modified version, you can hear that the sound
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> is ok:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> import("stdfaust.lib");
>>>>>>>>>>>>>>>> Tg = 0.4;
>>>>>>>>>>>>>>>> zi = an.ms_envelope_rect(Tg);
>>>>>>>>>>>>>>>> gain = hslider("Gain [unit:dB]",-10,-70,0,0.1) :
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> ba.db2linear;
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> sig = no.noise * gain;
>>>>>>>>>>>>>>>> process = attach(sig, (sig : zi : ba.linear2db :
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> *(0.5) : hbargraph("test",-70,0)));
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On Wed, Jul 7, 2021 at 12:59 AM Klaus Scheuermann
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> <kla...@posteo.de <mailto:kla...@posteo.de>> wrote:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Hi all,
>>>>>>>>>>>>>>>> I did some testing and
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> an.ms_envelope_rect()
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> seems to show some strange behaviour (at least to me).
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Here is a video
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> of the test:https://cloud.4ohm.de/s/64caEPBqxXeRMt5
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> <https://cloud.4ohm.de/s/64caEPBqxXeRMt5>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> The audio is white noise and the testing code is:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> import("stdfaust.lib");
>>>>>>>>>>>>>>>> Tg = 0.4;
>>>>>>>>>>>>>>>> zi = an.ms_envelope_rect(Tg);
>>>>>>>>>>>>>>>> process = _ : zi : ba.linear2db : hbargraph("test",-95,0);
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Could you please verify?
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Thanks, Klaus
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On 05.07.21 20:16, Julius Smith wrote:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Hmmm, '!' means "block the signal", but attach
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> should save the bargraph
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> from being optimized away as a result. Maybe I
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> misremembered the
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> argument order to attach? While it's very simple in
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> concept, it can be
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> confusing in practice.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> I chose not to have a gate at all, but you can grab
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> one from
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> misceffects.lib if you like. Low volume should not
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> give -infinity,
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> that's a bug, but zero should, and zero should
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> become MIN as I mentioned
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> so -infinity should never happen.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Cheers,
>>>>>>>>>>>>>>>>> Julius
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> On Mon, Jul 5, 2021 at 10:39 AM Klaus Scheuermann
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> <kla...@posteo.de <mailto:kla...@posteo.de>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> <mailto:kla...@posteo.de <mailto:kla...@posteo.de>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Cheers Julius,
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> At least I understood the 'attach' primitive now
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> ;) Thanks.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> This does not show any meter here...
>>>>>>>>>>>>>>>>> process(x,y) = x,y <: (_,_), attach(x, (Lk2 :
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> vbargraph("LUFS",-90,0)))
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> : _,_,!;
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> But this does for some reason (although the
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> output is 3-channel then):
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> process(x,y) = x,y <: (_,_), attach(x, (Lk2 :
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> vbargraph("LUFS",-90,0)))
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> : _,_,_;
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> What does the '!' do?
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> I still don't quite get the gating topic. In my
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> understanding, the meter
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> should hold the current value if the input
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> signal drops below a
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> threshold. In your version, the meter drops to
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> -infinity when very low
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> volume content is played.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Which part of your code does the gating?
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Many thanks,
>>>>>>>>>>>>>>>>> Klaus
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> On 05.07.21 18:06, Julius Smith wrote:
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Hi Klaus,
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Yes, I agree the filters are close enough. I
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> bet that the shelf is
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> exactly correct if we determined the exact
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> transition frequency, and
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> that the Butterworth highpass is close enough
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> to the
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Bessel-or-whatever
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> that is inexplicably not specified as a filter
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> type, leaving it
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> sample-rate dependent. I would bet large odds
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> that the differences
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> cannot be reliably detected in listening tests.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Yes, I just looked again, and there are
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> "gating blocks" defined,
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> each Tg
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> = 0.4 sec long, so that only ungated blocks
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> are averaged to form a
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> longer term level-estimate. What I wrote
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> gives a "sliding gating
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> block", which can be lowpass filtered further,
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> and/or gated, etc.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Instead of a gate, I would simply replace 0 by
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> ma.EPSILON so that the
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> log always works (good for avoiding denormals
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> as well).
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> I believe stereo is supposed to be handled
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> like this:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Lk2 = _,0,_,0,0 : Lk5;
>>>>>>>>>>>>>>>>>> process(x,y) = Lk2(x,y);
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> or
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Lk2 = Lk(0),Lk(2) :> 10 * log10 : -(0.691);
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> but since the center channel is processed
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> identically to left
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> and right,
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> your solution also works.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Bypassing is normal Faust, e.g.,
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> process(x,y) = x,y <: (_,_), attach(x, (Lk2 :
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> vbargraph("LUFS",-90,0)))
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> : _,_,!;
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Cheers,
>>>>>>>>>>>>>>>>>> Julius
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> On Mon, Jul 5, 2021 at 1:56 AM Klaus
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Scheuermann <kla...@posteo.de <mailto:kla...@posteo.de>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> <mailto:kla...@posteo.de <mailto:kla...@posteo.de>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> <mailto:kla...@posteo.de
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> <mailto:kla...@posteo.de> <mailto:kla...@posteo.de
>>>>>>>>>>>>>>> <mailto:kla...@posteo.de>>>> wrote:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> I can never resist these things! Faust
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> makes it too
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> enjoyable :-)
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Glad you can't ;)
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> I understood you approximate the filters
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> with standard faust
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> filters.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> That is probably close enough for me :)
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> I also get the part with the sliding
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> window envelope. If I
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> wanted to
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> make the meter follow slowlier, I would
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> just widen the window
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> with Tg.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> The 'gating' part I don't understand for
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> lack of mathematical
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> knowledge,
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> but I suppose it is meant differently.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> When the input signal
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> falls below
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> the gate threshold, the meter should stay
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> at the current
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> value, not drop
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> to -infinity, right? This is so 'silent'
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> parts are not taken into
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> account.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> If I wanted to make a stereo version it
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> would be something like
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> this, right?
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Lk2 = par(i,2, Lk(i)) :> 10 * log10 :
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> -(0.691);
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> process = _,_ : Lk2 : vbargraph("LUFS",-90,0);
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Probably very easy, but how do I attach
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> this to a stereo
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> signal (passing
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> through the stereo signal)?
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Thanks again!
>>>>>>>>>>>>>>>>>> Klaus
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> I made a pass, but there is a small
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> scaling error. I think
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> it can be
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> fixed by reducing boostFreqHz until the
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> sine_test is nailed.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> The highpass is close (and not a source
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> of the scale error),
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> but I'm
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> using Butterworth instead of whatever
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> they used.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> I glossed over the discussion of
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> "gating" in the spec, and
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> may have
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> missed something important there, but
>>>>>>>>>>>>>>>>>>> I simply tried to make a sliding
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> rectangular window, instead
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> of 75%
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> overlap, etc.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> If useful, let me know and I'll propose
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> it for analyzers.lib!
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Cheers,
>>>>>>>>>>>>>>>>>>> Julius
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> import("stdfaust.lib");
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> // Highpass:
>>>>>>>>>>>>>>>>>>> // At 48 kHz, this is the right highpass
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> filter (maybe a
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Bessel or
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Thiran filter?):
>>>>>>>>>>>>>>>>>>> A48kHz = ( /* 1.0, */ -1.99004745483398,
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> 0.99007225036621);
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> B48kHz = (1.0, -2.0, 1.0);
>>>>>>>>>>>>>>>>>>> highpass48kHz = fi.iir(B48kHz,A48kHz);
>>>>>>>>>>>>>>>>>>> highpass = fi.highpass(2, 40); //
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Butterworth highpass:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> roll-off is a
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> little too sharp
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> // High Shelf:
>>>>>>>>>>>>>>>>>>> boostDB = 4;
>>>>>>>>>>>>>>>>>>> boostFreqHz = 1430; // a little too high
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> - they should give
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> us this!
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> highshelf = fi.high_shelf(boostDB,
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> boostFreqHz); // Looks
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> very close,
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> but 1 kHz gain has to be nailed
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> kfilter = highshelf : highpass;
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> // Power sum:
>>>>>>>>>>>>>>>>>>> Tg = 0.4; // spec calls for 75% overlap
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> of successive
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> rectangular
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> windows - we're overlapping MUCH more
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> (sliding window)
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> zi = an.ms_envelope_rect(Tg); // mean
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> square: average power =
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> energy/Tg
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> = integral of squared signal / Tg
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> // Gain vector Gv = (GL,GR,GC,GLs,GRs):
>>>>>>>>>>>>>>>>>>> N = 5;
>>>>>>>>>>>>>>>>>>> Gv = (1, 1, 1, 1.41, 1.41); // left
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> GL(-30deg), right GR
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> (30), center
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> GC(0), left surround GLs(-110), right
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> surr. GRs(110)
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> G(i) = *(ba.take(i+1,Gv));
>>>>>>>>>>>>>>>>>>> Lk(i) = kfilter : zi : G(i); // one
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> channel, before summing
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> and before
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> taking dB and offsetting
>>>>>>>>>>>>>>>>>>> LkDB(i) = Lk(i) : 10 * log10 : -(0.691);
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> // Use this for a mono
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> input signal
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> // Five-channel surround input:
>>>>>>>>>>>>>>>>>>> Lk5 = par(i,5,Lk(i)) :> 10 * log10 :
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> -(0.691);
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> // sine_test = os.oscrs(1000); // should
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> give –3.01 LKFS, with
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> GL=GR=GC=1 (0dB) and GLs=GRs=1.41 (~1.5 dB)
>>>>>>>>>>>>>>>>>>> sine_test = os.osc(1000);
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> process = sine_test : LkDB(0); // should
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> read -3.01 LKFS -
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> high-shelf
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> gain at 1 kHz is critical
>>>>>>>>>>>>>>>>>>> // process = 0,sine_test,0,0,0 : Lk5; //
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> should read -3.01
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> LKFS for
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> left, center, and right
>>>>>>>>>>>>>>>>>>> // Highpass test: process = 1-1' <:
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> highpass, highpass48kHz;
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> // fft in
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Octave
>>>>>>>>>>>>>>>>>>> // High shelf test: process = 1-1' :
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> highshelf; // fft in Octave
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> On Sat, Jul 3, 2021 at 1:08 AM Klaus
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Scheuermann
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> <kla...@posteo.de <mailto:kla...@posteo.de>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>> --
>> Sent from my Android device with K-9 Mail. Please excuse my brevity.
>> _______________________________________________
>> 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
>
> _______________________________________________
> Faudiostream-users mailing list
> Faudiostream-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/faudiostream-users
>
_______________________________________________
Faudiostream-users mailing list
Faudiostream-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/faudiostream-users
