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