Thank you, I will read up on it...
Just two more questions:
1.
zi= an.ms_envelope_rect(Tg);
is still buggy, right? At least it behaves very differently than 'zi_lp'
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);
2.
Regarding cpu-hunger, can you tell, which parts of master_me are eating
up most resources?
For instance, I am calling 'Lk2' four times of which three are the
same... does it matter?
Klaus
On 20.07.21 22:49, Stéphane Letz wrote:
> This is the occasion to remind all of you of some debugging tools that can
> help here:
>
> - read https://faustdoc.grame.fr/manual/optimizing/#debugging-the-dsp-code
>
> - especially the interp-trace tool:
> https://github.com/grame-cncm/faust/tree/master-dev/tools/benchmark#interp-tracer
>
> - which gives on master_me_gui.dsp : interp-tracer -trace 4 master_me_gui.dsp
>
> Libfaust version : 2.33.1 (LLVM 12.0.1)
> Compiled with additional options :
> Using interpreter backend
> getName master_me_gui
> ------------------------
> init 44100
> ------------------------
> instanceInit 44100
> ------------------------
> classInit 44100
> ------------------------
> instanceConstants 44100
> ------------------------
> instanceResetUserInterface
> ------------------------
> instanceClear
> ------------------------
> compute 16
> -------- Interpreter 'Inf' trace start --------
> opcode 204 kLog10f int 0 real 0 offset1 -1 offset2 -1
> opcode 11 kLoadIndexedReal int 0 real 0 offset1 16 offset2 2 name fRec21
> opcode 1 kInt32Value int 0 real 0 offset1 -1 offset2 -1
> opcode 0 kRealValue int 0 real 20 offset1 -1 offset2 -1
> opcode 13 kStoreIndexedReal int 0 real 0 offset1 16 offset2 2 name fRec21
> opcode 1 kInt32Value int 0 real 0 offset1 -1 offset2 -1
> opcode 11 kLoadIndexedReal int 0 real 0 offset1 14 offset2 2 name fRec22
> opcode 1 kInt32Value int 0 real 0 offset1 -1 offset2 -1
>
> so does indeed detect the log10(0) failure reported by Dario.
>
> Stéphane
>
>> Le 20 juil. 2021 à 22:40, Dario Sanfilippo <sanfilippo.da...@gmail.com> a
>> écrit :
>>
>> Or you're feeding 0 to a log function. :-)
>>
>> Try this:
>>
>> Lk2 = Lk(0),Lk(2) :> 10 * log10(max(ma.EPSILON)) : -(0.691);
>>
>> Dr Dario Sanfilippo
>> http://dariosanfilippo.com
>>
>>
>> On Tue, 20 Jul 2021 at 22:28, Dario Sanfilippo <sanfilippo.da...@gmail.com>
>> wrote:
>> 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
>
>
> _______________________________________________
> 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
