On third thought, I now see how subtraction is not exact (it depends on what shifts are needed at addition/subtraction time, which can differ). The idea is to effectively never round, only summation and the delayed subtraction, so that subtraction after the delay is exact, avoiding a TIIR requirement. It should be possible to accomplish this by converting to fixed-point, etc. I'm back to thinking about the TIIR case...
On Sat, Jul 10, 2021 at 12:02 PM Julius Smith <julius.sm...@gmail.com> wrote: > On second thought, I don't see at the moment how anything can go wrong > with this: > > sliding_mean(durSamples) = (+ ~ _) - @(int(durSamples)) : /(durSamples); > > Since there is no rounding involved, the cancellation has to be exact. We > just have to ensure that the implementation does not subtract integrators > that keep going separately, i.e., there needs to be one summer in the > implementation (and the delay line of course). This looks ok to me (but > I'm rushed so apologies if I overlook anything); > > float fVec0[131072]; // 2^17 > > for (int i0 = 0; (i0 < count); i0 = (i0 + 1)) { > fRec0[0] = (float(input0[i0]) + fRec0[1]); > fVec0[(IOTA & 131071)] = float(input1[i0]); > output0[i0] = FAUSTFLOAT((fConst1 * (fRec0[0] - fVec0[((IOTA - iConst0) > & 131071)]))); > fRec0[1] = fRec0[0]; > IOTA = (IOTA + 1); > } > > On Sat, Jul 10, 2021 at 11:24 AM Julius Smith <julius.sm...@gmail.com> > wrote: > >> The obvious conclusion, of course, is to work out the ping-ponged >> truncated integrators, for measurements this long. We just need two 0.4s >> mean calculators that alternate. I'm sure I'll work it out sometime soon >> if nobody beats me to it. I imagine a square wave, select2, the >> sliding-mean unit, a state-clearing mechanism, etc. Gotta do it in the >> cracks of the day, however... it'll be fun! >> >> On Sat, Jul 10, 2021 at 11:08 AM Julius Smith <julius.sm...@gmail.com> >> wrote: >> >>> Actually, the pattern we want kicks in at durSamples = 32 >>> (circular-buffer delay line). >>> >>> On Sat, Jul 10, 2021 at 10:53 AM Julius Smith <julius.sm...@gmail.com> >>> wrote: >>> >>>> > I'm not sure I understand what you mean by allocating a delay line >>>> for the sliding mean, but I'll look into it. >>>> >>>> Here's an example implementation in Faust. The "small test" allocates >>>> a length 8 delay line. >>>> The full test takes too long to compile, but you can see the pattern, >>>> so it's easy to just write it. >>>> >>>> import("stdfaust.lib"); >>>> >>>> // Small test: >>>> durSamples = 8; >>>> DUR_SAMPLES_MAX = durSamples*2; >>>> >>>> // What we really need (but takes a LONG time to compile): >>>> // DUR_SAMPLES_MAX = 2^16; >>>> // durSamples = int(0.5 + 0.4 * ma.SR); >>>> >>>> sliding_mean(durSamples) = _ <: >>>> par(i,DUR_SAMPLES_MAX,ba.if(i<durSamples,@(i),0)) :> /(durSamples); >>>> >>>> process = sliding_mean(durSamples); >>>> >>>> On Sat, Jul 10, 2021 at 1:12 AM Dario Sanfilippo < >>>> sanfilippo.da...@gmail.com> wrote: >>>> >>>>> Dear Julius, thanks for putting it nicely. :) >>>>> >>>>> I'm not sure I understand what you mean by allocating a delay line for >>>>> the sliding mean, but I'll look into it. >>>>> >>>>> A quick improvement to the slidingMean function could be to put the >>>>> integrator after the difference. With a sliding window of .4 sec at 48 >>>>> kHz, >>>>> we should have about 60 dBs of dynamic range when feeding a full-amp >>>>> constant. It should be even better with close-to-zero-mean signals. >>>>> >>>>> import("stdfaust.lib"); >>>>> slidingSum(n) = _ <: _, _@int(max(0,n)) : - : fi.pole(1); >>>>> slidingMean(n) = slidingSum(n)/rint(n); >>>>> t=.4; >>>>> process = ba.if(ba.time < ma.SR * 1, 1.0, .001) <: >>>>> slidingMean(t*ma.SR) , ba.slidingMean(t*ma.SR) : ba.linear2db , >>>>> ba.linear2db; >>>>> >>>>> Ciao, >>>>> Dr Dario Sanfilippo >>>>> http://dariosanfilippo.com >>>>> >>>>> >>>>> On Sat, 10 Jul 2021 at 00:27, Julius Smith <julius.sm...@gmail.com> >>>>> wrote: >>>>> >>>>>> Hi Dario, >>>>>> >>>>>> Ok, I see what you're after now. (I was considering only the VU >>>>>> meter display issue up to now.) >>>>>> >>>>>> There's only 23 bits of mantissa in 32-bit floating point, and your >>>>>> test counts up to ~100k, which soaks up about 17 bits, and then you hit >>>>>> it >>>>>> with ~1/1024, or 2^(-10), which is then a dynamic range swing of 27 bits. >>>>>> We can't add numbers separated by 27 bits of dynamic level using a >>>>>> mantissa >>>>>> (or integer) smaller than 27 bits. Yes, double precision will fix that >>>>>> (52-bit mantissas), but even TIIR methods can't solve this problem. When >>>>>> adding x and y, the wordlength must be on the order of at least >>>>>> |log2(|x|/|y|)|. >>>>>> >>>>>> The situation is not so dire with a noise input, since it should be >>>>>> zero mean (and if not, a dcblocker will fix it). However, the variance >>>>>> of >>>>>> integrated squared white noise does grow linearly, so TIIR methods are >>>>>> needed for anything long term, and double-precision allows the TIIR >>>>>> resets >>>>>> to be much farther separated, and maybe not even needed in a given >>>>>> application. >>>>>> >>>>>> Note, by the way (Hey Klaus!), we can simply allocate a 0.4 second >>>>>> delay line for the sliding mean and be done with all this >>>>>> recursive-filter >>>>>> dynamic range management. It can be a pain, but it also can be managed. >>>>>> That said, 0.4 seconds at 96 kHz is around 15 bits worth >>>>>> (log2(0.4*96000)=15.2), so single-precision seems to me like enough for a >>>>>> simple level meter (e.g., having a 3-digit display), given a TIIR reset >>>>>> every 0.4 seconds. Since this works out so neatly, I wouldn't be >>>>>> surprised >>>>>> if 0.4 seconds was chosen for the gated-measurement duration for that >>>>>> reason. >>>>>> >>>>>> Cheers, >>>>>> Julius >>>>>> >>>>>> >>>>>> On Fri, Jul 9, 2021 at 1:54 PM Dario Sanfilippo < >>>>>> sanfilippo.da...@gmail.com> wrote: >>>>>> >>>>>>> Thanks, Julius. >>>>>>> >>>>>>> So it appears that the issue I was referring to is in that >>>>>>> architecture too. >>>>>>> >>>>>>> To isolate the problem with ba.slidingMean, we can see that we also >>>>>>> get 0 when transitioning from a constant input of 1 to .001 (see code >>>>>>> below). Double-precision solves the issue. Perhaps we could advise >>>>>>> using DP >>>>>>> for this function and the others involving it. >>>>>>> >>>>>>> Ciao, >>>>>>> Dario >>>>>>> >>>>>>> import("stdfaust.lib"); >>>>>>> lp1p(cf, x) = fi.pole(b, x * (1 - b)) >>>>>>> with { >>>>>>> b = exp(-2 * ma.PI * cf / ma.SR); >>>>>>> }; >>>>>>> sig = ba.if(ba.time > ma.SR * 2, .001, 1.0); >>>>>>> t = .4; >>>>>>> process = sig <: ba.slidingMean(t * ma.SR) , lp1p(1.0 / t) , ba.time; >>>>>>> >>>>>>> On Fri, 9 Jul 2021 at 22:40, Julius Smith <julius.sm...@gmail.com> >>>>>>> wrote: >>>>>>> >>>>>>>> I get the zero but not the other: >>>>>>>> >>>>>>>> octave:2> format long >>>>>>>> octave:3> faustout(115200,:) >>>>>>>> ans = >>>>>>>> >>>>>>>> 0 -2.738748490000000e-02 >>>>>>>> 5.555857930000000e-05 >>>>>>>> >>>>>>>> >>>>>>>> On Fri, Jul 9, 2021 at 1:03 PM Dario Sanfilippo < >>>>>>>> sanfilippo.da...@gmail.com> wrote: >>>>>>>> >>>>>>>>> Thanks, Julius. >>>>>>>>> >>>>>>>>> I don't have Octave installed, and I can't see it myself, sorry; >>>>>>>>> if you can inspect the generated values, can you also see if at >>>>>>>>> sample #115200 >>>>>>>>> (48 kHz SR) you get 0 for ms_rec, and, 0.000658808684 for the lowpass? >>>>>>>>> >>>>>>>>> Yes, I might have done something wrong, but the leaky integrator >>>>>>>>> doesn't work well. >>>>>>>>> >>>>>>>>> Ciao, >>>>>>>>> Dario >>>>>>>>> >>>>>>>>> On Fri, 9 Jul 2021 at 21:49, Julius Smith <julius.sm...@gmail.com> >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>>> Here is a longer run that shows Dario's latest test more >>>>>>>>>> completely. I don't think zi_leaky looks right at the end, but the >>>>>>>>>> other >>>>>>>>>> two look reasonable to me. >>>>>>>>>> >>>>>>>>>> Here is the Octave magic for the plot: >>>>>>>>>> >>>>>>>>>> plot(faustout,'linewidth',2); >>>>>>>>>> legend('zi','zi\_leaky','zi\_lp','location','southeast'); >>>>>>>>>> grid; >>>>>>>>>> >>>>>>>>>> I had to edit faust2octave to change the process duration, it's >>>>>>>>>> hardwired. Length option needed! (Right now no options can take an >>>>>>>>>> argument.) >>>>>>>>>> >>>>>>>>>> Cheers, >>>>>>>>>> - Julius >>>>>>>>>> >>>>>>>>>> On Fri, Jul 9, 2021 at 12:01 PM Julius Smith < >>>>>>>>>> julius.sm...@gmail.com> wrote: >>>>>>>>>> >>>>>>>>>>> Hi Dario, >>>>>>>>>>> >>>>>>>>>>> I tried your latest test and it looks plausible in faust2octave >>>>>>>>>>> (see plot attached). >>>>>>>>>>> >>>>>>>>>>> TIIR filters present a nice, juicy Faust puzzle :-) >>>>>>>>>>> I thought about a TIIR sliding average, but haven't implemented >>>>>>>>>>> anything yet. >>>>>>>>>>> You basically want to switch between two moving-average filters, >>>>>>>>>>> clearing the state of the unused one, and bringing it back to >>>>>>>>>>> steady state >>>>>>>>>>> before switching it back in. >>>>>>>>>>> In the case of an.ms_envelope_rect, the switching period can be >>>>>>>>>>> anything greater than the rectangular-window length (which is the >>>>>>>>>>> "warm up >>>>>>>>>>> time" of the moving-average filter). >>>>>>>>>>> >>>>>>>>>>> Cheers, >>>>>>>>>>> - Julius >>>>>>>>>>> >>>>>>>>>>> On Fri, Jul 9, 2021 at 10:49 AM Dario Sanfilippo < >>>>>>>>>>> sanfilippo.da...@gmail.com> wrote: >>>>>>>>>>> >>>>>>>>>>>> Dear Julius, I just pulled and installed Faust 2.33.0. >>>>>>>>>>>> >>>>>>>>>>>> I'm running the test below on caqt and csvplot and I see the >>>>>>>>>>>> same problem: when large inputs are fed in an.ms_envelope_rect, >>>>>>>>>>>> small inputs are truncated to zero afterwards. >>>>>>>>>>>> >>>>>>>>>>>> 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 * ba.if(ba.time > ma.SR * 2, .01, 1.0); >>>>>>>>>>>> process = sig <: zi , zi_leaky , zi_lp , ba.time; >>>>>>>>>>>> >>>>>>>>>>>> I'll look into TIIR filters or have you already implemented >>>>>>>>>>>> those in Faust? >>>>>>>>>>>> >>>>>>>>>>>> Ciao, >>>>>>>>>>>> Dr Dario Sanfilippo >>>>>>>>>>>> http://dariosanfilippo.com >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On Thu, 8 Jul 2021 at 19:19, Julius Smith < >>>>>>>>>>>> julius.sm...@gmail.com> 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> 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 remove the hbargraph altogether, 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 >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> On Thu, 8 Jul 2021 at 00:39, Julius Smith < >>>>>>>>>>>>>> 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> 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 >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On Wed, 7 Jul 2021 at 19:25, Stéphane Letz <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> 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> 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 >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> > 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>> 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>>> 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> >>>>>>>>>>>>>>>>> > > > <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: >>>>>>>>>>>>>>>>> > > > > >>>>>>>>>>>>>>>>> > > > > Hello everyone :) >>>>>>>>>>>>>>>>> > > > > >>>>>>>>>>>>>>>>> > > > > Would someone be up for helping me >>>>>>>>>>>>>>>>> implement an LUFS >>>>>>>>>>>>>>>>> > > loudness >>>>>>>>>>>>>>>>> > > > analyser >>>>>>>>>>>>>>>>> > > > > in faust? >>>>>>>>>>>>>>>>> > > > > >>>>>>>>>>>>>>>>> > > > > Or has someone done it already? >>>>>>>>>>>>>>>>> > > > > >>>>>>>>>>>>>>>>> > > > > LUFS (aka LKFS) is becoming more and >>>>>>>>>>>>>>>>> more the standard for >>>>>>>>>>>>>>>>> > > > loudness >>>>>>>>>>>>>>>>> > > > > measurement in the audio industry. >>>>>>>>>>>>>>>>> Youtube, Spotify and >>>>>>>>>>>>>>>>> > > broadcast >>>>>>>>>>>>>>>>> > > > > stations use the concept to normalize >>>>>>>>>>>>>>>>> loudness. A very >>>>>>>>>>>>>>>>> > > > positive side >>>>>>>>>>>>>>>>> > > > > effect is, that loudness-wars are >>>>>>>>>>>>>>>>> basically over. >>>>>>>>>>>>>>>>> > > > > >>>>>>>>>>>>>>>>> > > > > I looked into it, but my programming >>>>>>>>>>>>>>>>> skills clearly >>>>>>>>>>>>>>>>> > > don't match >>>>>>>>>>>>>>>>> > > > > the level for implementing this. >>>>>>>>>>>>>>>>> > > > > >>>>>>>>>>>>>>>>> > > > > Here is some resource about the topic: >>>>>>>>>>>>>>>>> > > > > >>>>>>>>>>>>>>>>> > > > > https://en.wikipedia.org/wiki/LKFS >>>>>>>>>>>>>>>>> > > <https://en.wikipedia.org/wiki/LKFS> >>>>>>>>>>>>>>>>> > > > <https://en.wikipedia.org/wiki/LKFS >>>>>>>>>>>>>>>>> > > <https://en.wikipedia.org/wiki/LKFS>> >>>>>>>>>>>>>>>>> > > > <https://en.wikipedia.org/wiki/LKFS >>>>>>>>>>>>>>>>> > > <https://en.wikipedia.org/wiki/LKFS> >>>>>>>>>>>>>>>>> > > > <https://en.wikipedia.org/wiki/LKFS >>>>>>>>>>>>>>>>> > > <https://en.wikipedia.org/wiki/LKFS>>> >>>>>>>>>>>>>>>>> > > > > >>>>>>>>>>>>>>>>> > > > > Specifications (in Annex 1): >>>>>>>>>>>>>>>>> > > > > >>>>>>>>>>>>>>>>> > > > >>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>> https://www.itu.int/dms_pubrec/itu-r/rec/bs/R-REC-BS.1770-3-201208-S!!PDF-E.pdf >>>>>>>>>>>>>>>>> > > < >>>>>>>>>>>>>>>>> https://www.itu.int/dms_pubrec/itu-r/rec/bs/R-REC-BS.1770-3-201208-S!!PDF-E.pdf >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> > > > >>>>>>>>>>>>>>>>> > > < >>>>>>>>>>>>>>>>> https://www.itu.int/dms_pubrec/itu-r/rec/bs/R-REC-BS.1770-3-201208-S!!PDF-E.pdf >>>>>>>>>>>>>>>>> > > < >>>>>>>>>>>>>>>>> https://www.itu.int/dms_pubrec/itu-r/rec/bs/R-REC-BS.1770-3-201208-S!!PDF-E.pdf >>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>> > > > > >>>>>>>>>>>>>>>>> > > > >>>>>>>>>>>>>>>>> > > < >>>>>>>>>>>>>>>>> https://www.itu.int/dms_pubrec/itu-r/rec/bs/R-REC-BS.1770-3-201208-S!!PDF-E.pdf >>>>>>>>>>>>>>>>> > > < >>>>>>>>>>>>>>>>> https://www.itu.int/dms_pubrec/itu-r/rec/bs/R-REC-BS.1770-3-201208-S!!PDF-E.pdf >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> > > > >>>>>>>>>>>>>>>>> > > < >>>>>>>>>>>>>>>>> https://www.itu.int/dms_pubrec/itu-r/rec/bs/R-REC-BS.1770-3-201208-S!!PDF-E.pdf >>>>>>>>>>>>>>>>> > > < >>>>>>>>>>>>>>>>> https://www.itu.int/dms_pubrec/itu-r/rec/bs/R-REC-BS.1770-3-201208-S!!PDF-E.pdf >>>>>>>>>>>>>>>>> >>> >>>>>>>>>>>>>>>>> > > > > >>>>>>>>>>>>>>>>> > > > > An implementation by 'klangfreund' in >>>>>>>>>>>>>>>>> JUCE / C: >>>>>>>>>>>>>>>>> > > > > >>>>>>>>>>>>>>>>> https://github.com/klangfreund/LUFSMeter >>>>>>>>>>>>>>>>> > > <https://github.com/klangfreund/LUFSMeter> >>>>>>>>>>>>>>>>> > > > <https://github.com/klangfreund/LUFSMeter >>>>>>>>>>>>>>>>> > > <https://github.com/klangfreund/LUFSMeter>> >>>>>>>>>>>>>>>>> > > > > < >>>>>>>>>>>>>>>>> https://github.com/klangfreund/LUFSMeter >>>>>>>>>>>>>>>>> > > <https://github.com/klangfreund/LUFSMeter> >>>>>>>>>>>>>>>>> > > > <https://github.com/klangfreund/LUFSMeter >>>>>>>>>>>>>>>>> > > <https://github.com/klangfreund/LUFSMeter>>> >>>>>>>>>>>>>>>>> > > > > >>>>>>>>>>>>>>>>> > > > > There is also a free LUFS Meter in JS >>>>>>>>>>>>>>>>> / Reaper by >>>>>>>>>>>>>>>>> > > Geraint Luff. >>>>>>>>>>>>>>>>> > > > > (The code can be seen in reaper, but I >>>>>>>>>>>>>>>>> don't know if I >>>>>>>>>>>>>>>>> > > should >>>>>>>>>>>>>>>>> > > > paste it >>>>>>>>>>>>>>>>> > > > > here.) >>>>>>>>>>>>>>>>> > > > > >>>>>>>>>>>>>>>>> > > > > Please let me know if you are up for >>>>>>>>>>>>>>>>> it! >>>>>>>>>>>>>>>>> > > > > >>>>>>>>>>>>>>>>> > > > > Take care, >>>>>>>>>>>>>>>>> > > > > Klaus >>>>>>>>>>>>>>>>> > > > > >>>>>>>>>>>>>>>>> > > > > >>>>>>>>>>>>>>>>> > > > > >>>>>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>>>>> > > > > Faudiostream-users mailing list >>>>>>>>>>>>>>>>> > > > > >>>>>>>>>>>>>>>>> Faudiostream-users@lists.sourceforge.net >>>>>>>>>>>>>>>>> > > <mailto:Faudiostream-users@lists.sourceforge.net> >>>>>>>>>>>>>>>>> > > > <mailto: >>>>>>>>>>>>>>>>> Faudiostream-users@lists.sourceforge.net >>>>>>>>>>>>>>>>> > > <mailto:Faudiostream-users@lists.sourceforge.net>> >>>>>>>>>>>>>>>>> > > > > <mailto: >>>>>>>>>>>>>>>>> Faudiostream-users@lists.sourceforge.net >>>>>>>>>>>>>>>>> > > <mailto:Faudiostream-users@lists.sourceforge.net> >>>>>>>>>>>>>>>>> > > > <mailto: >>>>>>>>>>>>>>>>> Faudiostream-users@lists.sourceforge.net >>>>>>>>>>>>>>>>> > > <mailto:Faudiostream-users@lists.sourceforge.net >>>>>>>>>>>>>>>>> >>> >>>>>>>>>>>>>>>>> > > > > >>>>>>>>>>>>>>>>> > > > >>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>> https://lists.sourceforge.net/lists/listinfo/faudiostream-users >>>>>>>>>>>>>>>>> > > < >>>>>>>>>>>>>>>>> https://lists.sourceforge.net/lists/listinfo/faudiostream-users >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> > > > >>>>>>>>>>>>>>>>> > > < >>>>>>>>>>>>>>>>> https://lists.sourceforge.net/lists/listinfo/faudiostream-users >>>>>>>>>>>>>>>>> > > < >>>>>>>>>>>>>>>>> https://lists.sourceforge.net/lists/listinfo/faudiostream-users >>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>> > > > > >>>>>>>>>>>>>>>>> > > > >>>>>>>>>>>>>>>>> > > < >>>>>>>>>>>>>>>>> https://lists.sourceforge.net/lists/listinfo/faudiostream-users >>>>>>>>>>>>>>>>> > > < >>>>>>>>>>>>>>>>> https://lists.sourceforge.net/lists/listinfo/faudiostream-users >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> > > > >>>>>>>>>>>>>>>>> > > < >>>>>>>>>>>>>>>>> https://lists.sourceforge.net/lists/listinfo/faudiostream-users >>>>>>>>>>>>>>>>> > > < >>>>>>>>>>>>>>>>> https://lists.sourceforge.net/lists/listinfo/faudiostream-users >>>>>>>>>>>>>>>>> >>> >>>>>>>>>>>>>>>>> > > > > >>>>>>>>>>>>>>>>> > > > > >>>>>>>>>>>>>>>>> > > > > >>>>>>>>>>>>>>>>> > > > > -- >>>>>>>>>>>>>>>>> > > > > "Anybody who knows all about nothing knows >>>>>>>>>>>>>>>>> everything" -- >>>>>>>>>>>>>>>>> > > Leonard >>>>>>>>>>>>>>>>> > > > Susskind >>>>>>>>>>>>>>>>> > > > >>>>>>>>>>>>>>>>> > > > >>>>>>>>>>>>>>>>> > > > >>>>>>>>>>>>>>>>> > > > -- >>>>>>>>>>>>>>>>> > > > "Anybody who knows all about nothing knows >>>>>>>>>>>>>>>>> everything" -- Leonard >>>>>>>>>>>>>>>>> > > Susskind >>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>> > > -- >>>>>>>>>>>>>>>>> > > "Anybody who knows all about nothing knows everything" >>>>>>>>>>>>>>>>> -- Leonard Susskind >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> > -- >>>>>>>>>>>>>>>>> > "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 >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> -- >>>>>>>>>>>>> "Anybody who knows all about nothing knows everything" -- >>>>>>>>>>>>> Leonard Susskind >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> -- >>>>>>>>>>> "Anybody who knows all about nothing knows everything" -- >>>>>>>>>>> Leonard Susskind >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> "Anybody who knows all about nothing knows everything" -- Leonard >>>>>>>>>> Susskind >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> "Anybody who knows all about nothing knows everything" -- Leonard >>>>>>>> Susskind >>>>>>>> >>>>>>> >>>>>> >>>>>> -- >>>>>> "Anybody who knows all about nothing knows everything" -- Leonard >>>>>> Susskind >>>>>> >>>>> >>>> >>>> -- >>>> "Anybody who knows all about nothing knows everything" -- Leonard >>>> Susskind >>>> >>> >>> >>> -- >>> "Anybody who knows all about nothing knows everything" -- Leonard >>> Susskind >>> >> >> >> -- >> "Anybody who knows all about nothing knows everything" -- Leonard Susskind >> > > > -- > "Anybody who knows all about nothing knows everything" -- Leonard Susskind > -- "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