Should float2fix and fix2float functions go inside the libraries? With
appropriate explanations on when to use them?
Stéphane
> Le 13 juil. 2021 à 06:08, Yann Orlarey <orla...@grame.fr> a écrit :
>
> Hi Julius,
>
> I didn't mention it to simplify my point, but it's absolutely right:
>
> float2fix(n) = *(2^n) : int;
> fix2float(n) = float : /(2^n);
> rms3(n) = _ <: _, (^(2) : float2fix(16) <: _,@(n) : - : +~_ : fix2float(16) :
> /(n) : sqrt : vbargraph("rms3", 0, 1.42)) : attach;
>
> Cheers
>
> Yann
>
>
> Le mar. 13 juil. 2021 à 03:14, Julius Smith <julius.sm...@gmail.com> a écrit :
> Hi Yann,
>
> That looks much better!
>
> However, I think the roundoff error will still grow in the integrator, unless
> the shifted delayed value (which is subtracted) is exactly the same bit
> pattern as its undelayed counterpart. This can be arranged by converting to
> fixed-point and leaving enough guard bits to accommodate the dynamic range
> needed. Alternatively, of course a TIIR version can be implemented.
>
> Cheers,
> Julius
>
> On Mon, Jul 12, 2021 at 3:28 PM Yann Orlarey <orla...@grame.fr> wrote:
> Hi Julius and Dario,
>
> Sliding sums written as:
>
> sliding_sum(n) = (+ ~ _) <: _, @(n) : -;
>
> accumulate errors (because the integral value is ever-growing, its precision
> decrease with time).
>
> This is why it is better to first subtract then integrate as in :
>
> sliding_sum(n) = _ <: _,@(n) : - : +~_ ;
>
> Here is an example that shows the problem. Set the level to the maximum for a
> while (10s), then decrease the level to 0.1 and you will see that the rms2
> value is wrong for this level. Do it again and the rms2 value becomes wrong
> for slightly higher values. etc.
>
> import("stdfaust.lib");
>
> W=4410;
>
> rms1(n) = _ <: _, (^(2) <: _,@(n) : - : +~_ : /(n) : sqrt : vbargraph("rms1",
> 0, 1.42)) : attach;
> rms2(n) = _ <: _, (^(2) <: ba.slidingSum(n) : /(n) : sqrt : vbargraph("rms2",
> 0, 1.42)) : attach;
>
> process = hgroup("Compare RMS", os.osc(440) * vslider("level", 0, 0, 2,
> 0.001) <: rms1(W),rms2(W));
>
>
> here is the equivalent link:
>
> https://faustide.grame.fr/?autorun=1&voices=0&name=rms&inline=aW1wb3J0KCJzdGRmYXVzdC5saWIiKTsKClc9NDQxMDsKCnJtczEobikgPSBfIDw6IF8sICheKDIpIDw6IF8sQChuKSA6IC0gOiArfl8gOiAvKG4pIDogc3FydCA6IHZiYXJncmFwaCgicm1zMSIsIDAsIDEuNDIpKSA6IGF0dGFjaDsKcm1zMihuKSA9IF8gPDogXywgKF4oMikgPDogYmEuc2xpZGluZ1N1bShuKSA6IC8obikgOiBzcXJ0IDogdmJhcmdyYXBoKCJybXMyIiwgMCwgMS40MikpIDogYXR0YWNoOwoKcHJvY2VzcyA9IGhncm91cCgiQ29tcGFyZSBSTVMiLCBvcy5vc2MoNDQwKSAqIHZzbGlkZXIoImxldmVsIiwgMCwgMCwgMiwgMC4wMDEpIDw6IHJtczEoVykscm1zMihXKSk7Cg%3D%3D
>
> Cheers
>
> Yann
>
>
>
> Le dim. 11 juil. 2021 à 23:36, Dario Sanfilippo <sanfilippo.da...@gmail.com>
> a écrit :
> Dear Julius,
>
> On Sun, 11 Jul 2021 at 22:26, Julius Smith <julius.sm...@gmail.com> wrote:
> > This appears to have two inputs, is it possible that something is missing?
>
> Yes, I should have defined it with "_ <: " at the input. Also, it's not a
> solution to our puzzle - sorry for the noise. Let me know if you prefer that
> I wait until I can actually test things before emailing - I've been including
> Faust code as an expression of ideas in conversation, sometimes bad ideas!
> :-).
>
> I feel privileged to be able to interact with you and I've learnt so much
> thanks to our exchanges during my little Faust adventure, so, by all means,
> please do write any ideas that you have. I'm only sorry that I can't always
> keep up with everything, but that's my limitation. :-)
>
>
> > Just to be sure that I understand, when you say to never round, do you
> > imply to never use an integrator? And that also implies using N_w - 1 sums
> > for a sliding window of N_w samples?
>
> I mean that the integrator has to be exact, so that it is "reversible" by
> subtracting what went into it. However, that does not bypass the need for an
> eventual reset.
>
> Here is a debugged and TESTED version of what I was going for:
>
> Great, I'll look into this.
>
>
> import("stdfaust.lib");
>
> durSamples = 8;
> DUR_SAMPLES_MAX = durSamples*2;
>
> sliding_sum(durSamples) = _ : (+ ~ _) <: _, @(int(durSamples)) : -;
> sliding_mean(durSamples) = sliding_sum(durSamples) / durSamples;
>
> process = 1.0 : sliding_sum(durSamples);
>
> However, this does not fully solve the sliding mean problem, except for
> sufficiently short runs.
> Here is a simple test output:
>
> > faust2plot tslidingmean.dsp && tslidingmean
> tslidingmean;
> % Usage: octave --persist thisfile.m
>
> faustout = [ ...
> 1; ...
> 2; ...
> 3; ...
> 4; ...
> 5; ...
> 6; ...
> 7; ...
> 8; ...
> 8; ...
> 8; ...
> ...
>
> I'll post my TIIR solution when I have time to write AND TEST it, unless of
> course someone beats me to it.
>
> I'm really looking forward to this too. Thank you so much for your work. :-)
>
> Dario
>
>
> Cheers,
> Julius
>
>
>
>
> On Sun, Jul 11, 2021 at 2:43 AM Dario Sanfilippo <sanfilippo.da...@gmail.com>
> wrote:
> Hi, Julius.
>
> Sure, I now see what you mean about delay lines, but I'd guess that the
> required sums would make it pretty heavy even if it compiled quickly.
>
> On Sun, 11 Jul 2021 at 09:07, Julius Smith <julius.sm...@gmail.com> wrote:
> 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);
>
> This appears to have two inputs, is it possible that something is missing?
>
> Just to be sure that I understand, when you say to never round, do you imply
> to never use an integrator? And that also implies using N_w - 1 sums for a
> sliding window of N_w samples?
>
> As I suggested earlier, putting the integrator after the difference would at
> least guarantee that the integrator shifts by only N_w * K if the input is a
> constant K, rather than indefinitely as in the case of the integrator being
> first. That's still not a final solution but it does improve things.
>
> Are embedded platforms the main reason why double-precision wouldn't be a
> suitable solution?
>
> Ciao,
> Dario
>
>
> 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
>
>
> --
> "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
>
>
> --
> "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
