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
