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