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
