I was looking at an.peak_envelope(time, in) On Tue, Jul 20, 2021 at 1:42 PM Dario Sanfilippo <sanfilippo.da...@gmail.com> wrote:
> 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 > -- "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
