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
