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
