Re: [Faudiostream-users] lufs loudness analyser

[Julius Smith]

I had some Faust-time today, so attached is your code (tlufs2.dsp) with
filters installed straight from the spec (only 48 kHz sampling supported).
You probably want to replace my sine test with your own external sine-input
test.

- Julius

On Fri, May 13, 2022 at 12:22 PM Julius Smith 
wrote:

> In that case, you could choose "MIT with GPL components".
> It's very easy to swap out a compressor, and the original simple
> compressor family I wrote is STK-4.3 licensed, so that's ready to go.
> I am happy to keep improving them if there is no better version available.
> One item on my list in that category is "release to threshold", but my
> ears have not yet wanted it, so I've been holding off.
> (I tend to devise bottom-up custom-crafted compression and use it
> very sparingly.)
>
> Thanks,
> Julius
>
>
> On Fri, May 13, 2022 at 3:50 AM Klaus Scheuermann 
> wrote:
>
>> I guess I can't apply MIT license, as some of the compressors I use are
>> GPLv3, right?
>>
>> For instance co.RMS_FBcompressor_peak_limiter_N_chan
>>
>>
>>
>> On Thu, 2022-05-12 at 22:27 -0700, Julius Smith wrote:
>> > >  l make it MIT - or what would be the best suiting license for
>> > > master_me
>> >
>> > MIT would be awesome!  I personally go with the STK-4.3 license,
>> > which I interpret as MIT plus a non-binding request to contribute
>> > useful modifications that are distributed.
>> >
>> > - Julius
>> >
>> >
>> > On Thu, May 12, 2022 at 2:00 PM Klaus Scheuermann 
>> > wrote:
>> > > Ok, so what I find strange is that the official specs paper does
>> > > not
>> > > specify the exact filter...
>> > >
>> > > I set up faustlive today with atom as an editor - pretty happy with
>> > > it
>> > > for now and -double precision works :)
>> > >
>> > > Good night!
>> > > Klaus
>> > >
>> > > On Thu, 2022-05-12 at 13:12 -0700, Julius Smith wrote:
>> > > > I see that the reaper loudness meter is LGPL.  Since I require
>> > > > MIT-
>> > > > level license freedom in the Faust world (for my consulting
>> > > > work), I
>> > > > won't look at that.
>> > > > It sounds like we want to tweak the filter designs to give -18
>> > > > LUFS
>> > > > for the tones you shared from Reaper.
>> > > > The main unknown parameter, as I recall, is the shelf transition
>> > > > frequency, but one could also try to compensate the frequency-
>> > > > warping
>> > > > from the bilinear transform.
>> > > >
>> > > > I compile Faust at the command line, by the way:
>> > > >
>> > > > faust2caqt -double tlufs2.dsp
>> > > > open tlufs2.app
>> > > >
>> > > > - Julius
>> > > >
>> > > > On Thu, May 12, 2022 at 3:14 AM Stéphane Letz 
>> > > > wrote:
>> > > > >
>> > > > > > double precision is not available in faustide, right?
>> > > > >
>> > > > > Yes still not.
>> > > > >
>> > > > > > I will try and
>> > > > > > install faustlive today.
>> > > > >
>> > > > > Yes. You can use « -double »  in FL «Compilation / FAUST
>> > > > > Compiler
>> > > > > Options »
>> > > > >
>> > > > > > Or would you recommend some other ide
>> > > > > > solution? (I am on arch linux.)
>> > > > > >
>> > > > >
>> > > > > Stéphane
>> > > > >
>> > > > >
>> > > > >
>> > > > > ___
>> > > > > 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
>>
>
>
> --
> "Anybody who knows all about nothing knows everything" -- Leonard Susskind
>


-- 
"Anybody who knows all about nothing knows everything" -- Leonard Susskind


tlufs2.dsp
Description: Binary data
___
Faudiostream-users mailing list
Faudiostream-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/faudiostream-users

Re: [Faudiostream-users] lufs loudness analyser

[Julius Smith]

In that case, you could choose "MIT with GPL components".
It's very easy to swap out a compressor, and the original simple compressor
family I wrote is STK-4.3 licensed, so that's ready to go.
I am happy to keep improving them if there is no better version available.
One item on my list in that category is "release to threshold", but my ears
have not yet wanted it, so I've been holding off.
(I tend to devise bottom-up custom-crafted compression and use it
very sparingly.)

Thanks,
Julius


On Fri, May 13, 2022 at 3:50 AM Klaus Scheuermann  wrote:

> I guess I can't apply MIT license, as some of the compressors I use are
> GPLv3, right?
>
> For instance co.RMS_FBcompressor_peak_limiter_N_chan
>
>
>
> On Thu, 2022-05-12 at 22:27 -0700, Julius Smith wrote:
> > >  l make it MIT - or what would be the best suiting license for
> > > master_me
> >
> > MIT would be awesome!  I personally go with the STK-4.3 license,
> > which I interpret as MIT plus a non-binding request to contribute
> > useful modifications that are distributed.
> >
> > - Julius
> >
> >
> > On Thu, May 12, 2022 at 2:00 PM Klaus Scheuermann 
> > wrote:
> > > Ok, so what I find strange is that the official specs paper does
> > > not
> > > specify the exact filter...
> > >
> > > I set up faustlive today with atom as an editor - pretty happy with
> > > it
> > > for now and -double precision works :)
> > >
> > > Good night!
> > > Klaus
> > >
> > > On Thu, 2022-05-12 at 13:12 -0700, Julius Smith wrote:
> > > > I see that the reaper loudness meter is LGPL.  Since I require
> > > > MIT-
> > > > level license freedom in the Faust world (for my consulting
> > > > work), I
> > > > won't look at that.
> > > > It sounds like we want to tweak the filter designs to give -18
> > > > LUFS
> > > > for the tones you shared from Reaper.
> > > > The main unknown parameter, as I recall, is the shelf transition
> > > > frequency, but one could also try to compensate the frequency-
> > > > warping
> > > > from the bilinear transform.
> > > >
> > > > I compile Faust at the command line, by the way:
> > > >
> > > > faust2caqt -double tlufs2.dsp
> > > > open tlufs2.app
> > > >
> > > > - Julius
> > > >
> > > > On Thu, May 12, 2022 at 3:14 AM Stéphane Letz 
> > > > wrote:
> > > > >
> > > > > > double precision is not available in faustide, right?
> > > > >
> > > > > Yes still not.
> > > > >
> > > > > > I will try and
> > > > > > install faustlive today.
> > > > >
> > > > > Yes. You can use « -double »  in FL «Compilation / FAUST
> > > > > Compiler
> > > > > Options »
> > > > >
> > > > > > Or would you recommend some other ide
> > > > > > solution? (I am on arch linux.)
> > > > > >
> > > > >
> > > > > Stéphane
> > > > >
> > > > >
> > > > >
> > > > > ___
> > > > > 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
>


-- 
"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

Re: [Faudiostream-users] lufs loudness analyser

[Klaus Scheuermann]

I guess I can't apply MIT license, as some of the compressors I use are
GPLv3, right?

For instance co.RMS_FBcompressor_peak_limiter_N_chan



On Thu, 2022-05-12 at 22:27 -0700, Julius Smith wrote:
> >  l make it MIT - or what would be the best suiting license for
> > master_me
> 
> MIT would be awesome!  I personally go with the STK-4.3 license,
> which I interpret as MIT plus a non-binding request to contribute
> useful modifications that are distributed.
> 
> - Julius
> 
> 
> On Thu, May 12, 2022 at 2:00 PM Klaus Scheuermann 
> wrote:
> > Ok, so what I find strange is that the official specs paper does
> > not
> > specify the exact filter...
> > 
> > I set up faustlive today with atom as an editor - pretty happy with
> > it
> > for now and -double precision works :)
> > 
> > Good night!
> > Klaus
> > 
> > On Thu, 2022-05-12 at 13:12 -0700, Julius Smith wrote:
> > > I see that the reaper loudness meter is LGPL.  Since I require
> > > MIT-
> > > level license freedom in the Faust world (for my consulting
> > > work), I
> > > won't look at that.
> > > It sounds like we want to tweak the filter designs to give -18
> > > LUFS
> > > for the tones you shared from Reaper.
> > > The main unknown parameter, as I recall, is the shelf transition
> > > frequency, but one could also try to compensate the frequency-
> > > warping
> > > from the bilinear transform.
> > > 
> > > I compile Faust at the command line, by the way:
> > > 
> > > faust2caqt -double tlufs2.dsp
> > > open tlufs2.app
> > > 
> > > - Julius
> > > 
> > > On Thu, May 12, 2022 at 3:14 AM Stéphane Letz 
> > > wrote:
> > > > 
> > > > > double precision is not available in faustide, right?
> > > > 
> > > > Yes still not.
> > > > 
> > > > > I will try and
> > > > > install faustlive today.
> > > > 
> > > > Yes. You can use « -double »  in FL «Compilation / FAUST
> > > > Compiler
> > > > Options »
> > > > 
> > > > > Or would you recommend some other ide
> > > > > solution? (I am on arch linux.)
> > > > > 
> > > > 
> > > > Stéphane
> > > > 
> > > > 
> > > > 
> > > > ___
> > > > 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

Re: [Faudiostream-users] lufs loudness analyser

[Julius Smith]

> We should at least determine where the mismatches are coming from

It just dawned on me that the obvious test for ruling out filter
approximation error is to type in the given literal coefficients and test
only at 48 kHz.
Those numbers could always be switched in for the 48kHz case.
The filter to use (twice) is then tf2(b0,b1,b2,a1,a2), using numbers
entered straight from the spec.
The generalized definitions can be used only at other sampling rates.

- Julius

On Thu, May 12, 2022 at 11:20 PM  wrote:

> Something here to look at possibly ?
>
> https://x42-plugins.com/x42/x42-meters
>
> With the source code :
>
> https://github.com/x42/meters.lv2
>
> Stéphane
>
> > Le 13 mai 2022 à 07:58, Julius Smith  a écrit :
> >
> > > Ok, so what I find strange is that the official specs paper does not
> specify the exact filter...
> >
> > I know!  That really surprised me as well.  The first stage in the spec
> (Rec. ITU-R BS.1770-4 5) is clearly a shelf filter, and that could be
> specified generically for any sampling rate.  Instead they give us a table
> of filter coefficients for 48 kHz sampling!  They note: "Implementations at
> other sampling rates will require different coefficient values, which
> should be chosen to provide the same frequency response that the specified
> filter provides at 48 kHz".  Unfortunately that is not possible!  (But it
> can be approximated.)   We thus have to GUESS the shelf parameters (or
> spherical head size and air parameters, etc., if deriving it that way).
> The second stage is a simple 2nd-order highpass filter, probably a
> Butterworth (the zeros were surely mapped from analog infinity), but again
> we only get a table of numbers to guess from.  I did note that Butterworth
> roll-off was a bit too fast below cutoff, so maybe it's a Bessel filter.
> WHY DON'T THEY JUST TELL US?
> >
> > Zooming out, given this level of extremely simple yet poorly specified
> signal processing, and the crudeness of the loudness model itself (see
> Zwicker, Moore, Glasberg, Baer, et al. for way better loudness modeling), I
> don't take the details as anywhere near "gospel", and I consider my
> guesses/approximations so far to be more than adequate.  However, I can
> also see the value of matching other LUFS meters as closely as possible,
> and of course there could be some other bug somewhere that's causing the
> discrepancies you are seeing.  We should at least determine where the
> mismatches are coming from for sure, and if there are no bugs, try to tweak
> them out.
> >
> > Cheers,
> > - Julius
> >
> >
> > On Thu, May 12, 2022 at 2:00 PM Klaus Scheuermann 
> wrote:
> > Ok, so what I find strange is that the official specs paper does not
> > specify the exact filter...
> >
> > I set up faustlive today with atom as an editor - pretty happy with it
> > for now and -double precision works :)
> >
> > Good night!
> > Klaus
> >
> > On Thu, 2022-05-12 at 13:12 -0700, Julius Smith wrote:
> > > I see that the reaper loudness meter is LGPL.  Since I require MIT-
> > > level license freedom in the Faust world (for my consulting work), I
> > > won't look at that.
> > > It sounds like we want to tweak the filter designs to give -18 LUFS
> > > for the tones you shared from Reaper.
> > > The main unknown parameter, as I recall, is the shelf transition
> > > frequency, but one could also try to compensate the frequency-warping
> > > from the bilinear transform.
> > >
> > > I compile Faust at the command line, by the way:
> > >
> > > faust2caqt -double tlufs2.dsp
> > > open tlufs2.app
> > >
> > > - Julius
> > >
> > > On Thu, May 12, 2022 at 3:14 AM Stéphane Letz  wrote:
> > > >
> > > > > double precision is not available in faustide, right?
> > > >
> > > > Yes still not.
> > > >
> > > > > I will try and
> > > > > install faustlive today.
> > > >
> > > > Yes. You can use « -double »  in FL «Compilation / FAUST Compiler
> > > > Options »
> > > >
> > > > > Or would you recommend some other ide
> > > > > solution? (I am on arch linux.)
> > > > >
> > > >
> > > > Stéphane
> > > >
> > > >
> > > >
> > > > ___
> > > > 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
___
Faudiostream-users mailing list
Faudiostream-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/faudiostream-users

Re: [Faudiostream-users] lufs loudness analyser

[letz]

Something here to look at possibly ?

https://x42-plugins.com/x42/x42-meters

With the source code :

https://github.com/x42/meters.lv2

Stéphane

> Le 13 mai 2022 à 07:58, Julius Smith  a écrit :
> 
> > Ok, so what I find strange is that the official specs paper does not 
> > specify the exact filter...
> 
> I know!  That really surprised me as well.  The first stage in the spec (Rec. 
> ITU-R BS.1770-4 5) is clearly a shelf filter, and that could be specified 
> generically for any sampling rate.  Instead they give us a table of filter 
> coefficients for 48 kHz sampling!  They note: "Implementations at other 
> sampling rates will require different coefficient values, which should be 
> chosen to provide the same frequency response that the specified filter 
> provides at 48 kHz".  Unfortunately that is not possible!  (But it can be 
> approximated.)   We thus have to GUESS the shelf parameters (or spherical 
> head size and air parameters, etc., if deriving it that way).  The second 
> stage is a simple 2nd-order highpass filter, probably a Butterworth (the 
> zeros were surely mapped from analog infinity), but again we only get a table 
> of numbers to guess from.  I did note that Butterworth roll-off was a bit too 
> fast below cutoff, so maybe it's a Bessel filter.  WHY DON'T THEY JUST TELL 
> US?
> 
> Zooming out, given this level of extremely simple yet poorly specified signal 
> processing, and the crudeness of the loudness model itself (see Zwicker, 
> Moore, Glasberg, Baer, et al. for way better loudness modeling), I don't take 
> the details as anywhere near "gospel", and I consider my 
> guesses/approximations so far to be more than adequate.  However, I can also 
> see the value of matching other LUFS meters as closely as possible, and of 
> course there could be some other bug somewhere that's causing the 
> discrepancies you are seeing.  We should at least determine where the 
> mismatches are coming from for sure, and if there are no bugs, try to tweak 
> them out.
> 
> Cheers,
> - Julius
> 
> 
> On Thu, May 12, 2022 at 2:00 PM Klaus Scheuermann  wrote:
> Ok, so what I find strange is that the official specs paper does not
> specify the exact filter...
> 
> I set up faustlive today with atom as an editor - pretty happy with it
> for now and -double precision works :)
> 
> Good night!
> Klaus
> 
> On Thu, 2022-05-12 at 13:12 -0700, Julius Smith wrote:
> > I see that the reaper loudness meter is LGPL.  Since I require MIT-
> > level license freedom in the Faust world (for my consulting work), I
> > won't look at that.
> > It sounds like we want to tweak the filter designs to give -18 LUFS
> > for the tones you shared from Reaper.
> > The main unknown parameter, as I recall, is the shelf transition
> > frequency, but one could also try to compensate the frequency-warping
> > from the bilinear transform.
> > 
> > I compile Faust at the command line, by the way:
> > 
> > faust2caqt -double tlufs2.dsp
> > open tlufs2.app
> > 
> > - Julius
> > 
> > On Thu, May 12, 2022 at 3:14 AM Stéphane Letz  wrote:
> > > 
> > > > double precision is not available in faustide, right?
> > > 
> > > Yes still not.
> > > 
> > > > I will try and
> > > > install faustlive today.
> > > 
> > > Yes. You can use « -double »  in FL «Compilation / FAUST Compiler
> > > Options »
> > > 
> > > > Or would you recommend some other ide
> > > > solution? (I am on arch linux.)
> > > > 
> > > 
> > > Stéphane
> > > 
> > > 
> > > 
> > > ___
> > > 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



___
Faudiostream-users mailing list
Faudiostream-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/faudiostream-users

Re: [Faudiostream-users] lufs loudness analyser

[Julius Smith]

> Ok, so what I find strange is that the official specs paper does not
specify the exact filter...

I know!  That really surprised me as well.  The first stage in the spec (*Rec.
ITU-R BS.1770-4 5) *is clearly a shelf filter, and that could be specified
generically for any sampling rate.  Instead they give us a table of filter
coefficients for 48 kHz sampling!  They note: "Implementations at other
sampling rates will require different coefficient values, which should be
chosen to provide the same frequency response that the specified filter
provides at 48 kHz".  Unfortunately that is not possible!  (But it can be
approximated.)   We thus have to GUESS the shelf parameters (or spherical
head size and air parameters, etc., if deriving it that way).  The second
stage is a simple 2nd-order highpass filter, probably a Butterworth (the
zeros were surely mapped from analog infinity), but again we only get a
table of numbers to guess from.  I did note that Butterworth roll-off was a
bit too fast below cutoff, so maybe it's a Bessel filter.  WHY DON'T THEY
JUST TELL US?

Zooming out, given this level of extremely simple yet poorly specified
signal processing, and the crudeness of the loudness model itself (see
Zwicker, Moore, Glasberg, Baer, et al. for way better loudness modeling), I
don't take the details as anywhere near "gospel", and I consider my
guesses/approximations so far to be more than adequate.  However, I can
also see the value of matching other LUFS meters as closely as possible,
and of course there could be some other bug somewhere that's causing the
discrepancies you are seeing.  We should at least determine where the
mismatches are coming from for sure, and if there are no bugs, try to tweak
them out.

Cheers,
- Julius


On Thu, May 12, 2022 at 2:00 PM Klaus Scheuermann  wrote:

> Ok, so what I find strange is that the official specs paper does not
> specify the exact filter...
>
> I set up faustlive today with atom as an editor - pretty happy with it
> for now and -double precision works :)
>
> Good night!
> Klaus
>
> On Thu, 2022-05-12 at 13:12 -0700, Julius Smith wrote:
> > I see that the reaper loudness meter is LGPL.  Since I require MIT-
> > level license freedom in the Faust world (for my consulting work), I
> > won't look at that.
> > It sounds like we want to tweak the filter designs to give -18 LUFS
> > for the tones you shared from Reaper.
> > The main unknown parameter, as I recall, is the shelf transition
> > frequency, but one could also try to compensate the frequency-warping
> > from the bilinear transform.
> >
> > I compile Faust at the command line, by the way:
> >
> > faust2caqt -double tlufs2.dsp
> > open tlufs2.app
> >
> > - Julius
> >
> > On Thu, May 12, 2022 at 3:14 AM Stéphane Letz  wrote:
> > >
> > > > double precision is not available in faustide, right?
> > >
> > > Yes still not.
> > >
> > > > I will try and
> > > > install faustlive today.
> > >
> > > Yes. You can use « -double »  in FL «Compilation / FAUST Compiler
> > > Options »
> > >
> > > > Or would you recommend some other ide
> > > > solution? (I am on arch linux.)
> > > >
> > >
> > > Stéphane
> > >
> > >
> > >
> > > ___
> > > 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
___
Faudiostream-users mailing list
Faudiostream-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/faudiostream-users

Re: [Faudiostream-users] lufs loudness analyser

[Julius Smith]

> l make it MIT - or what would be the best suiting license for master_me

MIT would be awesome!  I personally go with the STK-4.3 license, which I
interpret as MIT plus a non-binding request to contribute useful
modifications that are distributed.

- Julius


On Thu, May 12, 2022 at 2:00 PM Klaus Scheuermann  wrote:

> Ok, so what I find strange is that the official specs paper does not
> specify the exact filter...
>
> I set up faustlive today with atom as an editor - pretty happy with it
> for now and -double precision works :)
>
> Good night!
> Klaus
>
> On Thu, 2022-05-12 at 13:12 -0700, Julius Smith wrote:
> > I see that the reaper loudness meter is LGPL.  Since I require MIT-
> > level license freedom in the Faust world (for my consulting work), I
> > won't look at that.
> > It sounds like we want to tweak the filter designs to give -18 LUFS
> > for the tones you shared from Reaper.
> > The main unknown parameter, as I recall, is the shelf transition
> > frequency, but one could also try to compensate the frequency-warping
> > from the bilinear transform.
> >
> > I compile Faust at the command line, by the way:
> >
> > faust2caqt -double tlufs2.dsp
> > open tlufs2.app
> >
> > - Julius
> >
> > On Thu, May 12, 2022 at 3:14 AM Stéphane Letz  wrote:
> > >
> > > > double precision is not available in faustide, right?
> > >
> > > Yes still not.
> > >
> > > > I will try and
> > > > install faustlive today.
> > >
> > > Yes. You can use « -double »  in FL «Compilation / FAUST Compiler
> > > Options »
> > >
> > > > Or would you recommend some other ide
> > > > solution? (I am on arch linux.)
> > > >
> > >
> > > Stéphane
> > >
> > >
> > >
> > > ___
> > > 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
___
Faudiostream-users mailing list
Faudiostream-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/faudiostream-users

Re: [Faudiostream-users] lufs loudness analyser

[Klaus Scheuermann]

Ok, so what I find strange is that the official specs paper does not
specify the exact filter...

I set up faustlive today with atom as an editor - pretty happy with it
for now and -double precision works :)

Good night!
Klaus

On Thu, 2022-05-12 at 13:12 -0700, Julius Smith wrote:
> I see that the reaper loudness meter is LGPL.  Since I require MIT-
> level license freedom in the Faust world (for my consulting work), I
> won't look at that.
> It sounds like we want to tweak the filter designs to give -18 LUFS
> for the tones you shared from Reaper.
> The main unknown parameter, as I recall, is the shelf transition
> frequency, but one could also try to compensate the frequency-warping
> from the bilinear transform.
> 
> I compile Faust at the command line, by the way:
> 
> faust2caqt -double tlufs2.dsp
> open tlufs2.app
> 
> - Julius
> 
> On Thu, May 12, 2022 at 3:14 AM Stéphane Letz  wrote:
> > 
> > > double precision is not available in faustide, right?
> > 
> > Yes still not.
> > 
> > > I will try and
> > > install faustlive today.
> > 
> > Yes. You can use « -double »  in FL «Compilation / FAUST Compiler
> > Options »
> > 
> > > Or would you recommend some other ide
> > > solution? (I am on arch linux.)
> > > 
> > 
> > Stéphane
> > 
> > 
> > 
> > ___
> > 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

Re: [Faudiostream-users] lufs loudness analyser

[Klaus Scheuermann]

Well hello licensing ;) Another topic I need to learn about. I'll make
it MIT - or what would be the best suiting license for master_me? Itwas
developed with great help from the community, so it should be open to
anyone <3

Klaus

On Thu, 2022-05-12 at 13:21 -0700, Julius Smith wrote:
> Oops, I just noticed that master_me is GPL, so I can't use that
> either.
> That's ok, I can work from my original contribution to the project if
> I ever need LUFS for someone I am helping.
> (which seems likely - we should be using LUFS instead of dBFS all
> over the place!)
> 
> - Julius
> 
> On Thu, May 12, 2022 at 1:12 PM Julius Smith 
> wrote:
> > I see that the reaper loudness meter is LGPL.  Since I require MIT-
> > level license freedom in the Faust world (for my consulting work),
> > I won't look at that.
> > It sounds like we want to tweak the filter designs to give -18 LUFS
> > for the tones you shared from Reaper.
> > The main unknown parameter, as I recall, is the shelf transition
> > frequency, but one could also try to compensate the frequency-
> > warping from the bilinear transform.
> > 
> > I compile Faust at the command line, by the way:
> > 
> > faust2caqt -double tlufs2.dsp
> > open tlufs2.app
> > 
> > - Julius
> > 
> > On Thu, May 12, 2022 at 3:14 AM Stéphane Letz 
> > wrote:
> > > 
> > > > double precision is not available in faustide, right?
> > > 
> > > Yes still not.
> > > 
> > > > I will try and
> > > > install faustlive today.
> > > 
> > > Yes. You can use « -double »  in FL «Compilation / FAUST Compiler
> > > Options »
> > > 
> > > > Or would you recommend some other ide
> > > > solution? (I am on arch linux.)
> > > > 
> > > 
> > > Stéphane
> > > 
> > > 
> > > 
> > > ___
> > > 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

Re: [Faudiostream-users] lufs loudness analyser

[Julius Smith]

Oops, I just noticed that master_me is GPL, so I can't use that either.
That's ok, I can work from my original contribution to the project if I
ever need LUFS for someone I am helping.
(which seems likely - we should be using LUFS instead of dBFS all over the
place!)

- Julius

On Thu, May 12, 2022 at 1:12 PM Julius Smith  wrote:

> I see that the reaper loudness meter is LGPL.  Since I require MIT-level
> license freedom in the Faust world (for my consulting work), I won't look
> at that.
> It sounds like we want to tweak the filter designs to give -18 LUFS for
> the tones you shared from Reaper.
> The main unknown parameter, as I recall, is the shelf transition
> frequency, but one could also try to compensate the frequency-warping from
> the bilinear transform.
>
> I compile Faust at the command line, by the way:
>
> faust2caqt -double tlufs2.dsp
> open tlufs2.app
>
> - Julius
>
> On Thu, May 12, 2022 at 3:14 AM Stéphane Letz  wrote:
> >
> > > double precision is not available in faustide, right?
> >
> > Yes still not.
> >
> > > I will try and
> > > install faustlive today.
> >
> > Yes. You can use « -double »  in FL «Compilation / FAUST Compiler
> Options »
> >
> > > Or would you recommend some other ide
> > > solution? (I am on arch linux.)
> > >
> >
> > Stéphane
> >
> >
> >
> > ___
> > 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
___
Faudiostream-users mailing list
Faudiostream-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/faudiostream-users

Re: [Faudiostream-users] lufs loudness analyser

[Julius Smith]

I see that the reaper loudness meter is LGPL.  Since I require MIT-level
license freedom in the Faust world (for my consulting work), I won't look
at that.
It sounds like we want to tweak the filter designs to give -18 LUFS for the
tones you shared from Reaper.
The main unknown parameter, as I recall, is the shelf transition frequency,
but one could also try to compensate the frequency-warping from the
bilinear transform.

I compile Faust at the command line, by the way:

faust2caqt -double tlufs2.dsp
open tlufs2.app

- Julius

On Thu, May 12, 2022 at 3:14 AM Stéphane Letz  wrote:
>
> > double precision is not available in faustide, right?
>
> Yes still not.
>
> > I will try and
> > install faustlive today.
>
> Yes. You can use « -double »  in FL «Compilation / FAUST Compiler Options
»
>
> > Or would you recommend some other ide
> > solution? (I am on arch linux.)
> >
>
> Stéphane
>
>
>
> ___
> 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

Re: [Faudiostream-users] lufs loudness analyser

[Stéphane Letz]

> double precision is not available in faustide, right?

Yes still not.

> I will try and
> install faustlive today.

Yes. You can use « -double »  in FL «Compilation / FAUST Compiler Options » 

> Or would you recommend some other ide
> solution? (I am on arch linux.)
> 

Stéphane



___
Faudiostream-users mailing list
Faudiostream-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/faudiostream-users

Re: [Faudiostream-users] lufs loudness analyser

[Klaus Scheuermann]

Thanks Julius!

On Wed, 2022-05-11 at 20:05 -0700, Julius Smith wrote:
> > 1. how does this help if we need reference sine tones from another
> > source? I did a series of test tones in Reaper, all normalised to -
> > 18lufs. Here ist the test-
> > audio: https://cloud.4ohm.de/s/c7ynWemXS9eXibH
> 
> Ok, so you're saying you want to take these Reaper-generated sine
> files as ground truth.  I was just probing the system with known
> sines, which I trust for sure.
Well, yes, probably I trust them ;) I also loaded Klangfreund lufs
meter and ebumeter. They all show the same.

> > 2. at 1000Hz and levels above -45db, the lufs readout seems
> > plausible. Below -45dbfs, the meter falls to -69lufs. I don’t
> > understand.
> 
> This is curious.  For me that behavior kicks in around -32 dBFS.  It
> goes away in double precision, so I think it has to do with
> "max(ma.EPSILON)".
> However, while EPSILON is indeed around -70 dB when interpreted as
> power, it should not suddenly take a large drop like that.  It should
> just clip.
> In any case, this is a trivial one - we can just use "faust -double"
> (and probably should anyway).
double precision is not available in faustide, right? I will try and
install faustlive today. Or would you recommend some other ide
solution? (I am on arch linux.)

> > 3. probably just some coding style, but does amp =
> > 10^(level/20); equals amp = level : ba.db2linear; ?
> 
> Yes, no difference expected.  "Finger macro" - fewer characters to
> type :-)
Yay :)

> > 4. with amp = level : ba.db2linear; meter drops to -69lufs below -
> > 40dbfs at 1000Hz…
> 
> Same glitch as in 2, right?
Yes.

> So, it sounds like the filter polishing task is to make the Faust
> implementation match Reaper, but how do we know Reaper is correct?
> Since it's open-source, why don't we just copy its filters?

Yes! Here is the code of their JSFX loudness meter:
https://pastebin.com/Pu9CVeBC

unfortunately, I don't understand JSFX language :(
Do you?

Thank you so much again for your help!
Klaus


> Cheers,
> Julius
> 
> On Wed, May 11, 2022 at 4:02 AM Klaus Scheuermann 
> wrote:
> > Hi Julius,
> > 
> > Hm, I think the averaging time should not matter with continuous
> > sine tones coming in, right?
> > (According to specs, 0.4 is the value for ‘momentary’ and 3 for
> > ’short term’.)
> > 
> > Some questions about your test-program:
> > 
> > 1. how does this help if we need reference sine tones from another
> > source? I did a series of test tones in Reaper, all normalised to -
> > 18lufs. Here ist the test-
> > audio: https://cloud.4ohm.de/s/c7ynWemXS9eXibH
> > 
> > 2. at 1000Hz and levels above -45db, the lufs readout seems
> > plausible. Below -45dbfs, the meter falls to -69lufs. I don’t
> > understand.
> > 
> > 3. probably just some coding style, but does amp =
> > 10^(level/20); equals amp = level : ba.db2linear; ?
> > 
> > 4. with amp = level : ba.db2linear; meter drops to -69lufs below -
> > 40dbfs at 1000Hz…
> > 
> > Thanks for investigating with me :)
> > 
> > Klaus
> > 
> > 
> > 
> > 
> > Klaus Scheuermann
> > kla...@posteo.de
> > +491716565511
> > @schlunk:matrix.org
> > 4ohm.de
> > trummerschlunk.de
> > 
> > 
> > 
> > > On 11. May 2022, at 04:50, Julius Smith 
> > > wrote:
> > > 
> > > Hi Klaus,
> > > 
> > > Could the averaging time be too small?  I'm worried about the
> > > line
> > > 
> > > Tg = 0.4;// 3 second window for 'short-term' measurement
> > > 
> > > The comment seems to indicate it should be "Tg = 3;", i.e., 3
> > > seconds of averaging instead of 0.4 s.
> > > 
> > > Below is an expansion of your test program that allows for more
> > > exploration.
> > > 
> > > Cheers,
> > > Julius
> > > 
> > > import("stdfaust.lib");
> > > 
> > > freq = hslider("[0] Test Sine Frequency (Hz)
> > > [unit:Hz]",1000,30,16000,1);
> > > level = hslider("[1] Test Sine Level (dBFS) [unit:dBFS]",-10,-
> > > 80,0,0.1);
> > > avg = hslider("[2] Averaging Time (s) [unit:sec]",3,0.01,10,0.1);
> > > 
> > > amp = 10^(level/20);
> > > testSignal = amp * os.osc(freq);
> > > 
> > > process = testSignal <: _,_ : lk2 : vbargraph("[3] LUFS S",-40,0)
> > > : *(1e-7);
> > > 
> > > //Tg = 0.4; // 3 second window for 'short-term' measurement
> > > Tg = avg;
> > > zi = an.ms_envelope_rect(Tg); // mean square: average power =
> > > energy/Tg = integral of squared signal / Tg
> > > kfilter = fi.highpass(1, 60) : fi.high_shelf(4, 1800);
> > > 
> > > // 2-channel
> > > lk2 = par(i,2,kfilter : zi) :> 10 * log10(max(ma.EPSILON)) : -
> > > (0.691);
> > > 
> > > 
> > > On Tue, May 10, 2022 at 7:00 AM Klaus Scheuermann
> > >  wrote:
> > > > Hi Julius,
> > > > 
> > > > this is, of course, the way to go.
> > > > 
> > > > I did some test with a series of sines, each  at -18lufs, and
> > > > found these filter settings to be quite close (except for the
> > > > 30Hz):
> > > > kfilter = fi.highpass(1,60):fi.high_shelf(4,1800);
> > > > 
> > > > Hz  lufs
> > > > 30 -16.693
> > > > 60 -18.111
> > > > 80 -18.204
> > > > 100 -18.211
> > > > 130 

Re: [Faudiostream-users] lufs loudness analyser

[Julius Smith]

> 1. how does this help if we need reference sine tones from another
source? I did a series of test tones in Reaper, all normalised to -18lufs.
Here ist the test-audio: https://cloud.4ohm.de/s/c7ynWemXS9eXibH

Ok, so you're saying you want to take these Reaper-generated sine files as
ground truth.  I was just probing the system with known sines, which I
trust for sure.

> 2. at 1000Hz and levels above -45db, the lufs readout seems plausible.
Below -45dbfs, the meter falls to -69lufs. I don’t understand.

This is curious.  For me that behavior kicks in around -32 dBFS.  It goes
away in double precision, so I think it has to do with "max(ma.EPSILON)".
However, while EPSILON is indeed around -70 dB when interpreted as power,
it should not suddenly take a large drop like that.  It should just clip.
In any case, this is a trivial one - we can just use "faust -double" (and
probably should anyway).

> 3. probably just some coding style, but does amp = 10^(level/20); equals
amp = level : ba.db2linear; ?

Yes, no difference expected.  "Finger macro" - fewer characters to type :-)

> 4. with amp = level : ba.db2linear; meter drops to -69lufs below -40dbfs
at 1000Hz…

Same glitch as in 2, right?

So, it sounds like the filter polishing task is to make the Faust
implementation match Reaper, but how do we know Reaper is correct?
Since it's open-source, why don't we just copy its filters?

Cheers,
Julius

On Wed, May 11, 2022 at 4:02 AM Klaus Scheuermann  wrote:

> Hi Julius,
>
> Hm, I think the averaging time should not matter with continuous sine
> tones coming in, right?
> (According to specs, 0.4 is the value for ‘momentary’ and 3 for ’short
> term’.)
>
> Some questions about your test-program:
>
> 1. how does this help if we need reference sine tones from another source?
> I did a series of test tones in Reaper, all normalised to -18lufs. Here ist
> the test-audio: https://cloud.4ohm.de/s/c7ynWemXS9eXibH
>
> 2. at 1000Hz and levels above -45db, the lufs readout seems plausible.
> Below -45dbfs, the meter falls to -69lufs. I don’t understand.
>
> 3. probably just some coding style, but does amp = 10^(level/20); equals
> amp = level : ba.db2linear; ?
>
> 4. with amp = level : ba.db2linear; meter drops to -69lufs below -40dbfs
> at 1000Hz…
>
> Thanks for investigating with me :)
>
> Klaus
>
>
>
>
> Klaus Scheuermann
> kla...@posteo.de
> +491716565511
> @schlunk:matrix.org
> 4ohm.de
> trummerschlunk.de
>
>
>
> On 11. May 2022, at 04:50, Julius Smith  wrote:
>
> Hi Klaus,
>
> Could the averaging time be too small?  I'm worried about the line
>
> Tg = 0.4; // 3 second window for 'short-term' measurement
>
> The comment seems to indicate it should be "Tg = 3;", i.e., 3 seconds of
> averaging instead of 0.4 s.
>
> Below is an expansion of your test program that allows for more
> exploration.
>
> Cheers,
> Julius
>
> import("stdfaust.lib");
>
> freq = hslider("[0] Test Sine Frequency (Hz) [unit:Hz]",1000,30,16000,1);
> level = hslider("[1] Test Sine Level (dBFS) [unit:dBFS]",-10,-80,0,0.1);
> avg = hslider("[2] Averaging Time (s) [unit:sec]",3,0.01,10,0.1);
>
> amp = 10^(level/20);
> testSignal = amp * os.osc(freq);
>
> process = testSignal <: _,_ : lk2 : vbargraph("[3] LUFS S",-40,0) :
> *(1e-7);
>
> //Tg = 0.4; // 3 second window for 'short-term' measurement
> Tg = avg;
> zi = an.ms_envelope_rect(Tg); // mean square: average power = energy/Tg =
> integral of squared signal / Tg
> kfilter = fi.highpass(1, 60) : fi.high_shelf(4, 1800);
>
> // 2-channel
> lk2 = par(i,2,kfilter : zi) :> 10 * log10(max(ma.EPSILON)) : -(0.691);
>
>
> On Tue, May 10, 2022 at 7:00 AM Klaus Scheuermann 
> wrote:
>
>> Hi Julius,
>>
>> this is, of course, the way to go.
>>
>> I did some test with a series of sines, each  at -18lufs, and found these
>> filter settings to be quite close (except for the 30Hz):
>> kfilter = fi.highpass(1, 60) : fi.high_shelf(4, 1800);
>>
>> Hz  lufs
>> 30 -16.693
>> 60 -18.111
>> 80 -18.204
>> 100 -18.211
>> 130 -18.177
>> 180 -18.133
>> 250 -18.113
>> 300 -18.099
>> 400 -18.099
>> 600 -18.169
>> 1000 -18.405
>> 2000 -18.241
>> 3000 -17.894
>> 4000 -17.784
>> 6000 -17.503
>> 8000 -18.083
>> 1 -18.026
>> 12000 -18.035
>> 14000 -17.784
>> 16000 -18.083
>>
>> What I don't quite understand is why the values read a little different,
>> every time I do the test with same filter settings and same sines. (I am on
>> faustide.grame.fr).
>>
>> For my application, this should work fine. Out of curiosity, why do I
>> approximate the filters? So that it works on all samplerates?
>>
>> Full test code is this:
>> import("stdfaust.lib");
>>
>> process = _,_ : lk2 : vbargraph("LUFS S",-40,0);
>>
>> Tg = 0.4; // 3 second window for 'short-term' measurement
>> zi = an.ms_envelope_rect(Tg); // mean square: average power = energy/Tg
>> = integral of squared signal / Tg
>> kfilter = fi.highpass(1, 60) : fi.high_shelf(4, 1800);
>>
>>
>> // 2-channel
>> lk2 = par(i,2,kfilter : zi) :> 10 * log10(max(ma.EPSILON)) : -(0.691);
>>
>> Thanks!!

Re: [Faudiostream-users] lufs loudness analyser

[Klaus Scheuermann]

Hi Julius,

Hm, I think the averaging time should not matter with continuous sine tones 
coming in, right?
(According to specs, 0.4 is the value for ‘momentary’ and 3 for ’short term’.)

Some questions about your test-program:

1. how does this help if we need reference sine tones from another source? I 
did a series of test tones in Reaper, all normalised to -18lufs. Here ist the 
test-audio: https://cloud.4ohm.de/s/c7ynWemXS9eXibH

2. at 1000Hz and levels above -45db, the lufs readout seems plausible. Below 
-45dbfs, the meter falls to -69lufs. I don’t understand.

3. probably just some coding style, but does amp = 10^(level/20); equals amp = 
level : ba.db2linear; ?

4. with amp = level : ba.db2linear; meter drops to -69lufs below -40dbfs at 
1000Hz…

Thanks for investigating with me :)

Klaus




Klaus Scheuermann
kla...@posteo.de
+491716565511
@schlunk:matrix.org
4ohm.de
trummerschlunk.de



> On 11. May 2022, at 04:50, Julius Smith  wrote:
> 
> Hi Klaus,
> 
> Could the averaging time be too small?  I'm worried about the line
> 
> Tg = 0.4; // 3 second window for 'short-term' measurement
> 
> The comment seems to indicate it should be "Tg = 3;", i.e., 3 seconds of 
> averaging instead of 0.4 s.
> 
> Below is an expansion of your test program that allows for more exploration.
> 
> Cheers,
> Julius
> 
> import("stdfaust.lib");
> 
> freq = hslider("[0] Test Sine Frequency (Hz) [unit:Hz]",1000,30,16000,1);
> level = hslider("[1] Test Sine Level (dBFS) [unit:dBFS]",-10,-80,0,0.1);
> avg = hslider("[2] Averaging Time (s) [unit:sec]",3,0.01,10,0.1);
> 
> amp = 10^(level/20);
> testSignal = amp * os.osc(freq);
> 
> process = testSignal <: _,_ : lk2 : vbargraph("[3] LUFS S",-40,0) : *(1e-7);
> 
> //Tg = 0.4; // 3 second window for 'short-term' measurement
> Tg = avg;
> zi = an.ms_envelope_rect(Tg); // mean square: average power = energy/Tg = 
> integral of squared signal / Tg
> kfilter = fi.highpass(1, 60) : fi.high_shelf(4, 1800);
> 
> // 2-channel
> lk2 = par(i,2,kfilter : zi) :> 10 * log10(max(ma.EPSILON)) : -(0.691);
> 
> 
> On Tue, May 10, 2022 at 7:00 AM Klaus Scheuermann  > wrote:
> Hi Julius,
> 
> this is, of course, the way to go.
> 
> I did some test with a series of sines, each  at -18lufs, and found these 
> filter settings to be quite close (except for the 30Hz):
> kfilter = fi.highpass(1, 60) : fi.high_shelf(4, 1800);
> 
> Hz  lufs
> 30-16.693
> 60-18.111
> 80-18.204
> 100   -18.211
> 130   -18.177
> 180   -18.133
> 250   -18.113
> 300   -18.099
> 400   -18.099
> 600   -18.169
> 1000  -18.405
> 2000  -18.241
> 3000  -17.894
> 4000  -17.784
> 6000  -17.503
> 8000  -18.083
> 1 -18.026
> 12000 -18.035
> 14000 -17.784
> 16000 -18.083
> 
> What I don't quite understand is why the values read a little different, 
> every time I do the test with same filter settings and same sines. (I am on 
> faustide.grame.fr ).
> 
> For my application, this should work fine. Out of curiosity, why do I 
> approximate the filters? So that it works on all samplerates?
> 
> Full test code is this:
> import("stdfaust.lib");
> 
> process = _,_ : lk2 : vbargraph("LUFS S",-40,0);
> 
> Tg = 0.4; // 3 second window for 'short-term' measurement
> zi = an.ms_envelope_rect(Tg); // mean square: average power = energy/Tg = 
> integral of squared signal / Tg
> kfilter = fi.highpass(1, 60) : fi.high_shelf(4, 1800);
> 
> 
> // 2-channel
> lk2 = par(i,2,kfilter : zi) :> 10 * log10(max(ma.EPSILON)) : -(0.691);
> 
> Thanks!!
> Klaus
> 
> 
> 
> 
> On Sun, 2022-05-08 at 13:17 -0700, Julius Smith wrote:
>> Hi Klaus,
>> 
>> To go after this, it would be useful to measure the discrepancy for
>> some number of sinusoidal frequencies across the audio band, with at
>> least one example including both single-channel and multichannel
>> input.
>> Based on the filter approximations used, I would predict a measurable
>> discrepancy around 1 kHz (guessed transition-frequency tuning), and
>> very high frequencies (due to bilinear transform frequency-warping).
>> 
>> The high-frequency discrepancy should go away with oversampling, even 2x.
>> 
>> Glad to hear noise is looking good!
>> 
>> - Julius
>> 
>> On Sat, Jul 3, 2021 at 1:08 AM Klaus Scheuermann > > 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 
>>> 
>>> Specifications (in Annex 

Re: [Faudiostream-users] lufs loudness analyser

[Julius Smith]

Hi Klaus,

Could the averaging time be too small?  I'm worried about the line

Tg = 0.4; // 3 second window for 'short-term' measurement

The comment seems to indicate it should be "Tg = 3;", i.e., 3 seconds of
averaging instead of 0.4 s.

Below is an expansion of your test program that allows for more exploration.

Cheers,
Julius

import("stdfaust.lib");

freq = hslider("[0] Test Sine Frequency (Hz) [unit:Hz]",1000,30,16000,1);
level = hslider("[1] Test Sine Level (dBFS) [unit:dBFS]",-10,-80,0,0.1);
avg = hslider("[2] Averaging Time (s) [unit:sec]",3,0.01,10,0.1);

amp = 10^(level/20);
testSignal = amp * os.osc(freq);

process = testSignal <: _,_ : lk2 : vbargraph("[3] LUFS S",-40,0) : *(1e-7);

//Tg = 0.4; // 3 second window for 'short-term' measurement
Tg = avg;
zi = an.ms_envelope_rect(Tg); // mean square: average power = energy/Tg =
integral of squared signal / Tg
kfilter = fi.highpass(1, 60) : fi.high_shelf(4, 1800);

// 2-channel
lk2 = par(i,2,kfilter : zi) :> 10 * log10(max(ma.EPSILON)) : -(0.691);


On Tue, May 10, 2022 at 7:00 AM Klaus Scheuermann  wrote:

> Hi Julius,
>
> this is, of course, the way to go.
>
> I did some test with a series of sines, each  at -18lufs, and found these
> filter settings to be quite close (except for the 30Hz):
> kfilter = fi.highpass(1, 60) : fi.high_shelf(4, 1800);
>
> Hz  lufs
> 30 -16.693
> 60 -18.111
> 80 -18.204
> 100 -18.211
> 130 -18.177
> 180 -18.133
> 250 -18.113
> 300 -18.099
> 400 -18.099
> 600 -18.169
> 1000 -18.405
> 2000 -18.241
> 3000 -17.894
> 4000 -17.784
> 6000 -17.503
> 8000 -18.083
> 1 -18.026
> 12000 -18.035
> 14000 -17.784
> 16000 -18.083
>
> What I don't quite understand is why the values read a little different,
> every time I do the test with same filter settings and same sines. (I am on
> faustide.grame.fr).
>
> For my application, this should work fine. Out of curiosity, why do I
> approximate the filters? So that it works on all samplerates?
>
> Full test code is this:
> import("stdfaust.lib");
>
> process = _,_ : lk2 : vbargraph("LUFS S",-40,0);
>
> Tg = 0.4; // 3 second window for 'short-term' measurement
> zi = an.ms_envelope_rect(Tg); // mean square: average power = energy/Tg =
> integral of squared signal / Tg
> kfilter = fi.highpass(1, 60) : fi.high_shelf(4, 1800);
>
>
> // 2-channel
> lk2 = par(i,2,kfilter : zi) :> 10 * log10(max(ma.EPSILON)) : -(0.691);
>
> Thanks!!
> Klaus
>
>
>
>
> On Sun, 2022-05-08 at 13:17 -0700, Julius Smith wrote:
>
> Hi Klaus,
>
> To go after this, it would be useful to measure the discrepancy for
> some number of sinusoidal frequencies across the audio band, with at
> least one example including both single-channel and multichannel
> input.
> Based on the filter approximations used, I would predict a measurable
> discrepancy around 1 kHz (guessed transition-frequency tuning), and
> very high frequencies (due to bilinear transform frequency-warping).
>
> The high-frequency discrepancy should go away with oversampling, even 2x.
>
> Glad to hear noise is looking good!
>
> - Julius
>
> On Sat, Jul 3, 2021 at 1:08 AM Klaus Scheuermann  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
>
> Specifications (in Annex 1):
>
> 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
>
> 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
> 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

Re: [Faudiostream-users] lufs loudness analyser

[Klaus Scheuermann]

Hi Julius,

this is, of course, the way to go.

I did some test with a series of sines, each  at -18lufs, and found
these filter settings to be quite close (except for the 30Hz):
kfilter = fi.highpass(1, 60) : fi.high_shelf(4, 1800);

Hz  lufs
30 -16.693
60 -18.111
80 -18.204
100 -18.211
130 -18.177
180 -18.133
250 -18.113
300 -18.099
400 -18.099
600 -18.169
1000 -18.405
2000 -18.241
3000 -17.894
4000 -17.784
6000 -17.503
8000 -18.083
1 -18.026
12000 -18.035
14000 -17.784
16000 -18.083

What I don't quite understand is why the values read a little
different, every time I do the test with same filter settings and same
sines. (I am on faustide.grame.fr).

For my application, this should work fine. Out of curiosity, why do I
approximate the filters? So that it works on all samplerates?

Full test code is this:
import("stdfaust.lib");

process = _,_ : lk2 : vbargraph("LUFS S",-40,0);

Tg = 0.4; // 3 second window for 'short-term' measurement
zi = an.ms_envelope_rect(Tg); // mean square: average power = energy/Tg
 = integral of squared signal / Tg
kfilter = fi.highpass(1, 60) : fi.high_shelf(4, 1800);


// 2-channel
lk2 = par(i,2,kfilter : zi) :> 10 * log10(max(ma.EPSILON)) : -(0.691);

Thanks!!
Klaus




On Sun, 2022-05-08 at 13:17 -0700, Julius Smith wrote:
> Hi Klaus,
> 
> To go after this, it would be useful to measure the discrepancy for
> some number of sinusoidal frequencies across the audio band, with at
> least one example including both single-channel and multichannel
> input.
> Based on the filter approximations used, I would predict a measurable
> discrepancy around 1 kHz (guessed transition-frequency tuning), and
> very high frequencies (due to bilinear transform frequency-warping).
> 
> The high-frequency discrepancy should go away with oversampling, even
> 2x.
> 
> Glad to hear noise is looking good!
> 
> - Julius
> 
> On Sat, Jul 3, 2021 at 1:08 AM Klaus Scheuermann 
> 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
> > 
> > Specifications (in Annex 1):
> > 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
> > 
> > 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
> > 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

Re: [Faudiostream-users] lufs loudness analyser

[Julius Smith]

Hi Klaus,

To go after this, it would be useful to measure the discrepancy for
some number of sinusoidal frequencies across the audio band, with at
least one example including both single-channel and multichannel
input.
Based on the filter approximations used, I would predict a measurable
discrepancy around 1 kHz (guessed transition-frequency tuning), and
very high frequencies (due to bilinear transform frequency-warping).

The high-frequency discrepancy should go away with oversampling, even 2x.

Glad to hear noise is looking good!

- Julius

On Sat, Jul 3, 2021 at 1:08 AM Klaus Scheuermann  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
>
> Specifications (in Annex 1):
> 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
>
> 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
> 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

Re: [Faudiostream-users] lufs loudness analyser

[Klaus Scheuermann]

Hi guys,

would you have a moment to help me one more time with this lufs meter?
It seems, my meter reads a bit higher than other lufs meters when it
comes to music or speech. But with noise it's perfect. These files read
exactly -18lufs in Reaper and Klangfreund meter:

noise at -18lufs: https://cloud.4ohm.de/s/JEE6XeSmnL4QBZR
music at -18lufs: https://cloud.4ohm.de/s/yZgiqCGaK5EqHQE

In my program, noise is fine at -18lufs, but music goes to -16.8. Is
this only because of the approximated filters? Or is it something about
the summing of the channels?

Here is my code:
import("stdfaust.lib");

process = _,_ : lk2 : vbargraph("LUFS S",-40,0);


Tg = 3; // 3 second window for 'short-term' measurement
zi = an.ms_envelope_rect(Tg); // mean square: average power = energy/Tg
 = integral of squared signal / Tg
kfilter = fi.highpass(2, 40) : fi.high_shelf(4, 1430);


// 2-channel
lk2 = par(i,2,kfilter : zi) :> 10 * log10(max(ma.EPSILON)) : -(0.691);


Here are th official specs
again: 
https://www.itu.int/dms_pubrec/itu-r/rec/bs/R-REC-BS.1770-3-201208-S!!PDF-E.pdf

Thank you in advance!
Klaus





On Wed, 2021-07-21 at 16:16 +0200, Juan Carlos Blancas wrote:
> Its working great. I like the target stuff, will look into it,
> congrats ;)
> Best,
> Juan Carlos
> 
> > El 21 jul 2021, a las 15:39, Klaus Scheuermann 
> > escribió:
> > 
> > 
> > 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 
> > > 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, likewise when increasing the target
> > > the limiter is only affecting in the left one, so maybe there is
> > > some kind of cross channel issue?.
> > > 
> > > Cheers,
> > > Juan Carlos
> > > 
> > > > El 21 jul 2021, a las 10:00, Klaus Scheuermann
> > > >  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.githubusercon
> > > > tent.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/
> > > > > 
> > > > > 
> > > > > Stéphane
> > > > > 
> > > > > 
> > > > > 
> > > > > > Le 20 juil. 2021 à 23:14, Klaus
> > > > > > Scheuermann 
> > > > > >  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 

Re: [Faudiostream-users] lufs loudness analyser

[Juan Carlos Blancas]

Its working great. I like the target stuff, will look into it, congrats ;)
Best,
Juan Carlos

> El 21 jul 2021, a las 15:39, Klaus Scheuermann  escribió:
> 
> 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 > > 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 
>> , likewise when 
>> increasing the target the limiter is only affecting in the left one 
>> , so maybe there 
>> is some kind of cross channel issue?.
>> 
>> Cheers,
>> Juan Carlos
>> 
>>> El 21 jul 2021, a las 10:00, Klaus Scheuermann >> > 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
>>>  
>>> 
>>> 
>>> 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/ 
 
 
 
 Stéphane
 
 
 
> Le 20 juil. 2021 à 23:14, Klaus Scheuermann  >
>  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 
>> 

Re: [Faudiostream-users] lufs loudness analyser

[Klaus Scheuermann]

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  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 
> , likewise when 
> increasing the target the limiter is only affecting in the left one 
> , so maybe there is 
> some kind of cross channel issue?.
> 
> Cheers,
> Juan Carlos
> 
>> El 21 jul 2021, a las 10:00, Klaus Scheuermann > > 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
>>  
>> 
>> 
>> 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/ 
>>> 
>>> 
>>> 
>>> Stéphane
>>> 
>>> 
>>> 
 Le 20 juil. 2021 à 23:14, Klaus Scheuermann 
  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 

Re: [Faudiostream-users] lufs loudness analyser

[Juan Carlos Blancas]

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 
, likewise when 
increasing the target the limiter is only affecting in the left one 
, so maybe there is 
some kind of cross channel issue?.

Cheers,
Juan Carlos

> El 21 jul 2021, a las 10:00, Klaus Scheuermann  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
> 
> 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/
>> 
>> 
>> Stéphane
>> 
>> 
>> 
>>> Le 20 juil. 2021 à 23:14, Klaus Scheuermann 
>>>  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 
> 
>  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 
> 
> 
> 
>  wrote:
> Hello.
> 
> On Tue, 

Re: [Faudiostream-users] lufs loudness analyser

[Klaus Scheuermann]

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

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/
>
> Stéphane
>
>
>> Le 20 juil. 2021 à 23:14, Klaus Scheuermann  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 
  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 
 
  wrote:
 Hello.

 On Tue, 20 Jul 2021 at 22:14, Klaus Scheuermann 
 
  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 

Re: [Faudiostream-users] lufs loudness analyser

[Stéphane Letz]

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/

Stéphane


> Le 20 juil. 2021 à 23:14, Klaus Scheuermann  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 
>>>  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 
>>> 
>>>  wrote:
>>> Hello.
>>> 
>>> On Tue, 20 Jul 2021 at 22:14, Klaus Scheuermann 
>>> 
>>>  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 
 
  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" 
 
  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 

Re: [Faudiostream-users] lufs loudness analyser

[Klaus Scheuermann]

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  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  
>> wrote:
>> Hello.
>>
>> On Tue, 20 Jul 2021 at 22:14, Klaus Scheuermann  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  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"  
>>> wrote:
>>>  «  crash at silence » ? what does that mean exactly?
>>>
>>> Thanks.
>>>
>>> Stéphane
>>>
>>>
>>> Le 20 juil. 2021 à 11:55, Klaus Scheuermann >>> 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 

Re: [Faudiostream-users] lufs loudness analyser

[Stéphane Letz]

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  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  
> wrote:
> Hello.
> 
> On Tue, 20 Jul 2021 at 22:14, Klaus Scheuermann  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  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"  
>> wrote:
>>  «  crash at silence » ? what does that mean exactly?
>> 
>> Thanks.
>> 
>> Stéphane
>> 
>> 
>> Le 20 juil. 2021 à 11:55, Klaus Scheuermann > > 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  

Re: [Faudiostream-users] lufs loudness analyser

[Julius Smith]

I was looking at an.peak_envelope(time, in)

On Tue, Jul 20, 2021 at 1:42 PM Dario Sanfilippo 
wrote:

> 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 
> wrote:
>
>> Hello.
>>
>> On Tue, 20 Jul 2021 at 22:14, Klaus Scheuermann  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 
>>> 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" 
 wrote:
>
>  «  crash at silence » ? what does that mean exactly?
>
> Thanks.
>
> Stéphane
>
>>
>> Le 20 juil. 2021 à 11:55, Klaus Scheuermann  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 * _ ) + 

Re: [Faudiostream-users] lufs loudness analyser

[Dario Sanfilippo]

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 
wrote:

> Hello.
>
> On Tue, 20 Jul 2021 at 22:14, Klaus Scheuermann  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 
>> 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" 
>>> wrote:

  «  crash at silence » ? what does that mean exactly?

 Thanks.

 Stéphane

>
> Le 20 juil. 2021 à 11:55, Klaus Scheuermann  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.

Re: [Faudiostream-users] lufs loudness analyser

[Dario Sanfilippo]

Hello.

On Tue, 20 Jul 2021 at 22:14, Klaus Scheuermann  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 
> 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" 
>> wrote:
>>>
>>>  «  crash at silence » ? what does that mean exactly?
>>>
>>> Thanks.
>>>
>>> Stéphane
>>>

 Le 20 juil. 2021 à 11:55, Klaus Scheuermann  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 

Re: [Faudiostream-users] lufs loudness analyser

[Julius Smith]

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  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" 
> wrote:
>>
>>  «  crash at silence » ? what does that mean exactly?
>>
>> Thanks.
>>
>> Stéphane
>>
>> Le 20 juil. 2021 à 11:55, Klaus Scheuermann  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 

Re: [Faudiostream-users] lufs loudness analyser

[Klaus Scheuermann]

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"  wrote:
> «  crash at silence » ? what does that mean exactly?
>
>Thanks.
>
>Stéphane
>
>> Le 20 juil. 2021 à 11:55, Klaus Scheuermann  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

Re: [Faudiostream-users] lufs loudness analyser

[Stéphane Letz]

 «  crash at silence » ? what does that mean exactly?

Thanks.

Stéphane

> Le 20 juil. 2021 à 11:55, Klaus Scheuermann  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) : 

Re: [Faudiostream-users] lufs loudness analyser

[Stéphane Letz]

Should float2fix and fix2float functions go inside the libraries? With 
appropriate explanations on when to use them?

Stéphane 

> Le 13 juil. 2021 à 06:08, Yann Orlarey  a écrit :
> 
> Hi Julius,
> 
> I didn't mention it to simplify my point, but it's absolutely right:
> 
> float2fix(n) = *(2^n) : int;
> fix2float(n) = float : /(2^n);
> rms3(n) = _ <: _, (^(2) : float2fix(16) <: _,@(n) : - : +~_ : fix2float(16) : 
> /(n) : sqrt : vbargraph("rms3", 0, 1.42)) : attach;
> 
> Cheers
> 
> Yann
> 
> 
> Le mar. 13 juil. 2021 à 03:14, Julius Smith  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  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=0=rms=aW1wb3J0KCJzdGRmYXVzdC5saWIiKTsKClc9NDQxMDsKCnJtczEobikgPSBfIDw6IF8sICheKDIpIDw6IF8sQChuKSA6IC0gOiArfl8gOiAvKG4pIDogc3FydCA6IHZiYXJncmFwaCgicm1zMSIsIDAsIDEuNDIpKSA6IGF0dGFjaDsKcm1zMihuKSA9IF8gPDogXywgKF4oMikgPDogYmEuc2xpZGluZ1N1bShuKSA6IC8obikgOiBzcXJ0IDogdmJhcmdyYXBoKCJybXMyIiwgMCwgMS40MikpIDogYXR0YWNoOwoKcHJvY2VzcyA9IGhncm91cCgiQ29tcGFyZSBSTVMiLCBvcy5vc2MoNDQwKSAqIHZzbGlkZXIoImxldmVsIiwgMCwgMCwgMiwgMC4wMDEpIDw6IHJtczEoVykscm1zMihXKSk7Cg%3D%3D
> 
> Cheers
> 
> Yann
> 
> 
> 
> Le dim. 11 juil. 2021 à 23:36, Dario Sanfilippo  
> a écrit :
> Dear Julius,
> 
> On Sun, 11 Jul 2021 at 22:26, Julius Smith  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  
> 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 

Re: [Faudiostream-users] lufs loudness analyser

[Yann Orlarey]

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  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  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=0=rms=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 
>>> 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 

Re: [Faudiostream-users] lufs loudness analyser

[Julius Smith]

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  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=0=rms=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 
>> 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 
 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

Re: [Faudiostream-users] lufs loudness analyser

[Yann Orlarey]

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=0=rms=aW1wb3J0KCJzdGRmYXVzdC5saWIiKTsKClc9NDQxMDsKCnJtczEobikgPSBfIDw6IF8sICheKDIpIDw6IF8sQChuKSA6IC0gOiArfl8gOiAvKG4pIDogc3FydCA6IHZiYXJncmFwaCgicm1zMSIsIDAsIDEuNDIpKSA6IGF0dGFjaDsKcm1zMihuKSA9IF8gPDogXywgKF4oMikgPDogYmEuc2xpZGluZ1N1bShuKSA6IC8obikgOiBzcXJ0IDogdmJhcmdyYXBoKCJybXMyIiwgMCwgMS40MikpIDogYXR0YWNoOwoKcHJvY2VzcyA9IGhncm91cCgiQ29tcGFyZSBSTVMiLCBvcy5vc2MoNDQwKSAqIHZzbGlkZXIoImxldmVsIiwgMCwgMCwgMiwgMC4wMDEpIDw6IHJtczEoVykscm1zMihXKSk7Cg%3D%3D

Cheers

Yann



Le dim. 11 juil. 2021 à 23:36, Dario Sanfilippo 
a écrit :

> Dear Julius,
>
> On Sun, 11 Jul 2021 at 22:26, Julius Smith  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 
>>> 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 
 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 

Re: [Faudiostream-users] lufs loudness analyser

[Dario Sanfilippo]

Dear Julius,

On Sun, 11 Jul 2021 at 22:26, Julius Smith  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 
>> 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 
>>> 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 
 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.  

Re: [Faudiostream-users] lufs loudness analyser

[Julius Smith]

> 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! :-).

> 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:

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.

Cheers,
Julius




On Sun, Jul 11, 2021 at 2:43 AM Dario Sanfilippo 
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  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 
>> 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 
>>> 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 
 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 
> 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.

Re: [Faudiostream-users] lufs loudness analyser

[Klaus Scheuermann]

Thank you Stéphane!


On 11.07.21 13:19, l...@grame.fr wrote:
>>
>>> Le 10 juil. 2021 à 14:47, Juan Carlos Blancas  a écrit :
>>>
>>> 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
>>
>> There is indeed a general issue across all FIR base backend,s even this 
>> simple code fails;
>>
>> import("stdfaust.lib");
>> process = ba.slidingMeanp(ma.SR, 4);
>>
>> I’m on it.
>>
>> Stéphane
> 
> Bug fixed and new version deployed on all Web tools (FaustEditor, 
> FaustPlaygound, FaustIDE.)
> 
> Yann we still need to deploy the latest 2.33.1 version on the remote 
> compilation service.
> 
> Thanks.
> 
> Stéphane 
> 
> ___
> 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

Re: [Faudiostream-users] lufs loudness analyser

[letz]

> 
>> Le 10 juil. 2021 à 14:47, Juan Carlos Blancas  a écrit :
>> 
>> 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
> 
> There is indeed a general issue across all FIR base backend,s even this 
> simple code fails;
> 
> import("stdfaust.lib");
> process = ba.slidingMeanp(ma.SR, 4);
> 
> I’m on it.
> 
> Stéphane

Bug fixed and new version deployed on all Web tools (FaustEditor, 
FaustPlaygound, FaustIDE.)

Yann we still need to deploy the latest 2.33.1 version on the remote 
compilation service.

Thanks.

Stéphane 

___
Faudiostream-users mailing list
Faudiostream-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/faudiostream-users

Re: [Faudiostream-users] lufs loudness analyser

[Klaus Scheuermann]

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.

Way to go… ;)

Cheers, Klaus



> 
> Cheers,
> Juan Carlos
> 
>> El 10 jul 2021, a las 12:17, Klaus Scheuermann  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  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
> 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, 

Re: [Faudiostream-users] lufs loudness analyser

[Julius Smith]

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 
wrote:

> On second thought, I don't see at the moment how anything can go wrong
> with this:
>
> sliding_mean(durSamples) = (+ ~ _) - @(int(durSamples)) : /(durSamples);
>
> Since there is no rounding involved, the cancellation has to be exact.  We
> just have to ensure that the implementation does not subtract integrators
> that keep going separately, i.e., there needs to be one summer in the
> implementation (and the delay line of course).  This looks ok to me (but
> I'm rushed so apologies if I overlook anything);
>
>  float fVec0[131072]; // 2^17
>
> for (int i0 = 0; (i0 < count); i0 = (i0 + 1)) {
>   fRec0[0] = (float(input0[i0]) + fRec0[1]);
>   fVec0[(IOTA & 131071)] = float(input1[i0]);
>   output0[i0] = FAUSTFLOAT((fConst1 * (fRec0[0] - fVec0[((IOTA - iConst0)
> & 131071)])));
>   fRec0[1] = fRec0[0];
>   IOTA = (IOTA + 1);
> }
>
> On Sat, Jul 10, 2021 at 11:24 AM Julius Smith 
> 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 
>> 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 
>>> 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);

 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 
> 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
>> 

Re: [Faudiostream-users] lufs loudness analyser

[Dario Sanfilippo]

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  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 
> 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 
>> 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 
>>> 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 
 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);
>
> 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 
>> 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 

Re: [Faudiostream-users] lufs loudness analyser

[Julius Smith]

On second thought, I don't see at the moment how anything can go wrong with
this:

sliding_mean(durSamples) = (+ ~ _) - @(int(durSamples)) : /(durSamples);

Since there is no rounding involved, the cancellation has to be exact.  We
just have to ensure that the implementation does not subtract integrators
that keep going separately, i.e., there needs to be one summer in the
implementation (and the delay line of course).  This looks ok to me (but
I'm rushed so apologies if I overlook anything);

 float fVec0[131072]; // 2^17

for (int i0 = 0; (i0 < count); i0 = (i0 + 1)) {
  fRec0[0] = (float(input0[i0]) + fRec0[1]);
  fVec0[(IOTA & 131071)] = float(input1[i0]);
  output0[i0] = FAUSTFLOAT((fConst1 * (fRec0[0] - fVec0[((IOTA - iConst0) &
131071)])));
  fRec0[1] = fRec0[0];
  IOTA = (IOTA + 1);
}

On Sat, Jul 10, 2021 at 11:24 AM Julius Smith 
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 
> 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 
>> 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);
>>>
>>> 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 
 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
> 

Re: [Faudiostream-users] lufs loudness analyser

[Julius Smith]

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 
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 
> 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);
>>
>> 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 
>>> 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 
> wrote:
>
>> I get the zero but not the 

Re: [Faudiostream-users] lufs loudness analyser

[Julius Smith]

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 
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);
>
> 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 
>> 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 
 wrote:

> I get the zero but not the other:
>
> octave:2> format long
> octave:3> faustout(115200,:)
> ans =
>
>0  -2.73874849000e-02
> 5.55585793000e-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?
>>
>> 

Re: [Faudiostream-users] lufs loudness analyser

[Julius Smith]

> 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);

process = sliding_mean(durSamples);

On Sat, Jul 10, 2021 at 1:12 AM Dario Sanfilippo 
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  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 
>>> wrote:
>>>
 I get the zero but not the other:

 octave:2> format long
 octave:3> faustout(115200,:)
 ans =

0  -2.73874849000e-02   5.55585793000e-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 
> 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 

Re: [Faudiostream-users] lufs loudness analyser

[Juan Carlos Blancas]

> El 10 jul 2021, a las 15:31, Klaus Scheuermann  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 > > 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  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  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;  

Re: [Faudiostream-users] lufs loudness analyser

[Klaus Scheuermann]

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.

Way to go… ;)

Cheers, Klaus



> On 10. Jul 2021, at 14:47, Juan Carlos Blancas  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  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  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
> 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 

Re: [Faudiostream-users] lufs loudness analyser

[Stéphane Letz]

> Le 10 juil. 2021 à 14:47, Juan Carlos Blancas  a écrit :
> 
> 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

There is indeed a general issue across all FIR base backend,s even this simple 
code fails;

import("stdfaust.lib");
process = ba.slidingMeanp(ma.SR, 4);

I’m on it.

Stéphane 

___
Faudiostream-users mailing list
Faudiostream-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/faudiostream-users

Re: [Faudiostream-users] lufs loudness analyser

[Juan Carlos Blancas]

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  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  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
 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(.99) <: _, _@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
   

Re: [Faudiostream-users] lufs loudness analyser

[Klaus Scheuermann]

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  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
>>> 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(.99) <: _, _@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 >>> 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.
>>>
>>>  

Re: [Faudiostream-users] lufs loudness analyser

[Dario Sanfilippo]

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  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  wrote:
>>
>>> I get the zero but not the other:
>>>
>>> octave:2> format long
>>> octave:3> faustout(115200,:)
>>> ans =
>>>
>>>0  -2.73874849000e-02   5.55585793000e-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 
 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 
> 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 

Re: [Faudiostream-users] lufs loudness analyser

[Julius Smith]

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 
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  wrote:
>
>> I get the zero but not the other:
>>
>> octave:2> format long
>> octave:3> faustout(115200,:)
>> ans =
>>
>>0  -2.73874849000e-02   5.55585793000e-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 
>>> 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 
 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(.99) <: _, _@int(max(0,n)) :> -;
>> slidingMean(n) = slidingSum(n)/rint(n);
>> zi_leaky(x) = slidingMean(Tg*ma.SR, x * x);
>> lp1p(cf, 

Re: [Faudiostream-users] lufs loudness analyser

[Dario Sanfilippo]

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  wrote:

> I get the zero but not the other:
>
> octave:2> format long
> octave:3> faustout(115200,:)
> ans =
>
>0  -2.73874849000e-02   5.55585793000e-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  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 
>>> 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(.99) <: _, _@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 
> 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

Re: [Faudiostream-users] lufs loudness analyser

[Julius Smith]

I get the zero but not the other:

octave:2> format long
octave:3> faustout(115200,:)
ans =

   0  -2.73874849000e-02   5.55585793000e-05


On Fri, Jul 9, 2021 at 1:03 PM Dario Sanfilippo 
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  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 
>> 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(.99) <: _, _@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 
 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(.99) <: _, _@int(max(0,n)) :> -;
>> slidingMean(n) = slidingSum(n)/rint(n);
>> zi_leaky(x) = slidingMean(Tg*ma.SR, x * x);
>> lp1p(cf, x) = 

Re: [Faudiostream-users] lufs loudness analyser

[Dario Sanfilippo]

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  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 
> 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(.99) <: _, _@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 
>>> 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(.99) <: _, _@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

Re: [Faudiostream-users] lufs loudness analyser

[Julius Smith]

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  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(.99) <: _, _@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  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(.99) <: _, _@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 
 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 

Re: [Faudiostream-users] lufs loudness analyser

[Dario Sanfilippo]

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(.99) <: _, _@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  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(.99) <: _, _@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  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.99)
>>> ... 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  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 à 

Re: [Faudiostream-users] lufs loudness analyser

[Juan Carlos Blancas]

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  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
>> 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(.99) <: _, _@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 >> 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.99) ... etc.
>> 
>>- Julius
>> 
>>On Wed, Jul 7, 2021 at 

Re: [Faudiostream-users] lufs loudness analyser

[Klaus Scheuermann]

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
> 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(.99) <: _, _@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  > 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.99) ... etc.
> 
> - Julius
> 
> On Wed, Jul 7, 2021 at 12:32 PM Dario Sanfilippo
> 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 
> 
> 
> On Wed, 7 Jul 2021 at 19:25, Stéphane Letz  > 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
> mailto:julius.sm...@gmail.com>>
> a écrit :
>   

Re: [Faudiostream-users] lufs loudness analyser

[Julius Smith]

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 
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(.99) <: _, _@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  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.99)
>> ... 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  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  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 
 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 : 

Re: [Faudiostream-users] lufs loudness analyser

[Dario Sanfilippo]

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(.99) <: _, _@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  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.99) ...
> 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  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  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 
>>> 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 >> > > > wrote:
>>> > >
>>> > > Cheers Julius,
>>> > >
>>> > >
>>> > >
>>> > > At least I understood the 'attach' 

Re: [Faudiostream-users] lufs loudness analyser

[Julius Smith]

> 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.99) ...
etc.

- Julius

On Wed, Jul 7, 2021 at 12:32 PM Dario Sanfilippo 
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  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  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 
>> 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 > > > > 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 

Re: [Faudiostream-users] lufs loudness analyser

[Julius Smith]

faust2caqt on the Mac

On Wed, Jul 7, 2021 at 2:38 PM Stéphane Letz  wrote:

> Using which architecture?
>
> Thanks.
>
> Stéphane
>
> > Le 7 juil. 2021 à 23:34, Julius Smith  a écrit :
> >
> > Hmmm, this test points to a hbargraph gating behavior in its display
> only, although I did not run it for a long time:
> >
> > import("stdfaust.lib");
> > Tg = 0.4;
> > zi = an.ms_envelope_rect(Tg);
> > //gain = hslider("Gain [unit:dB]",-10,-70,0,0.1) : ba.db2linear;
> > gain = 0.01; // -40 dB - ok in Octave (I get -44.744 dB)
> > sig = no.noise * gain;
> > level = zi : ba.linear2db : *(0.5);
> > //process = level, attach(sig, (sig : level : hbargraph("test",-70,0)));
> > process = sig : level <: _, hbargraph("test",-70,0);
> >
> > On Wed, Jul 7, 2021 at 12:50 PM Juan Carlos Blancas 
> wrote:
> > Hi Klaus,
> >
> > Same here, it seems there is something with ms and rms_envelope.
> >
> > Best,
> > Juan Carlos
> >
> > import("stdfaust.lib");
> >
> > rms(n) = _ : square : mean(n) : sqrt;
> > square(x) = x * x;
> > mean(n) = float2fix : integrate(n) : fix2float : /(n);
> > integrate(n,x) = x - x@n : +~_;
> > float2fix(x) = int(x*(1<<20));
> > fix2float(x) = float(x)/(1<<20);
> >
> > Tg = 0.4;
> > zi  = an.ms_envelope_rect(Tg);
> > ziR = an.rms_envelope_rect(Tg);
> >
> > process = no.noise*1.737 *
> ba.db2linear(hslider("[0]g[unit:dB]",-20,-95,-10,0.1)) <:
> > attach(_, rms(ma.SR*Tg) : ba.linear2db : hbargraph("[1]rms",-95,0)),
> > attach(_, sqrt(zi) : ba.linear2db :
> hbargraph("[2]sqrt(ms_envelope_rect)",-95,0)),
> > attach(_, ziR : ba.linear2db : hbargraph("[3]rms_envelope_rect",-95,0));
> >
> >
> > > El 7 jul 2021, a las 9:59, Klaus Scheuermann 
> escribió:
> > >
> > > 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  > >> > 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) = 

Re: [Faudiostream-users] lufs loudness analyser

[Stéphane Letz]

Using which architecture?

Thanks.

Stéphane 

> Le 7 juil. 2021 à 23:34, Julius Smith  a écrit :
> 
> Hmmm, this test points to a hbargraph gating behavior in its display only, 
> although I did not run it for a long time:
> 
> import("stdfaust.lib");
> Tg = 0.4;
> zi = an.ms_envelope_rect(Tg);
> //gain = hslider("Gain [unit:dB]",-10,-70,0,0.1) : ba.db2linear;
> gain = 0.01; // -40 dB - ok in Octave (I get -44.744 dB)
> sig = no.noise * gain;
> level = zi : ba.linear2db : *(0.5);
> //process = level, attach(sig, (sig : level : hbargraph("test",-70,0)));
> process = sig : level <: _, hbargraph("test",-70,0);
> 
> On Wed, Jul 7, 2021 at 12:50 PM Juan Carlos Blancas  wrote:
> Hi Klaus, 
> 
> Same here, it seems there is something with ms and rms_envelope.
> 
> Best,
> Juan Carlos
> 
> import("stdfaust.lib");
> 
> rms(n) = _ : square : mean(n) : sqrt;
> square(x) = x * x;
> mean(n) = float2fix : integrate(n) : fix2float : /(n); 
> integrate(n,x) = x - x@n : +~_;
> float2fix(x) = int(x*(1<<20));  
> fix2float(x) = float(x)/(1<<20);
> 
> Tg = 0.4;
> zi  = an.ms_envelope_rect(Tg);
> ziR = an.rms_envelope_rect(Tg);
> 
> process = no.noise*1.737 * 
> ba.db2linear(hslider("[0]g[unit:dB]",-20,-95,-10,0.1)) <:
> attach(_, rms(ma.SR*Tg) : ba.linear2db : hbargraph("[1]rms",-95,0)),
> attach(_, sqrt(zi) : ba.linear2db : 
> hbargraph("[2]sqrt(ms_envelope_rect)",-95,0)),
> attach(_, ziR : ba.linear2db : hbargraph("[3]rms_envelope_rect",-95,0));
> 
> 
> > El 7 jul 2021, a las 9:59, Klaus Scheuermann  escribió:
> > 
> > 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  >> > 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 :
> 

Re: [Faudiostream-users] lufs loudness analyser

[Julius Smith]

Hmmm, this test points to a hbargraph gating behavior in its display only,
although I did not run it for a long time:

import("stdfaust.lib");
Tg = 0.4;
zi = an.ms_envelope_rect(Tg);
//gain = hslider("Gain [unit:dB]",-10,-70,0,0.1) : ba.db2linear;
gain = 0.01; // -40 dB - ok in Octave (I get -44.744 dB)
sig = no.noise * gain;
level = zi : ba.linear2db : *(0.5);
//process = level, attach(sig, (sig : level : hbargraph("test",-70,0)));
process = sig : level <: _, hbargraph("test",-70,0);

On Wed, Jul 7, 2021 at 12:50 PM Juan Carlos Blancas 
wrote:

> Hi Klaus,
>
> Same here, it seems there is something with ms and rms_envelope.
>
> Best,
> Juan Carlos
>
> import("stdfaust.lib");
>
> rms(n) = _ : square : mean(n) : sqrt;
> square(x) = x * x;
> mean(n) = float2fix : integrate(n) : fix2float : /(n);
> integrate(n,x) = x - x@n : +~_;
> float2fix(x) = int(x*(1<<20));
> fix2float(x) = float(x)/(1<<20);
>
> Tg = 0.4;
> zi  = an.ms_envelope_rect(Tg);
> ziR = an.rms_envelope_rect(Tg);
>
> process = no.noise*1.737 *
> ba.db2linear(hslider("[0]g[unit:dB]",-20,-95,-10,0.1)) <:
> attach(_, rms(ma.SR*Tg) : ba.linear2db : hbargraph("[1]rms",-95,0)),
> attach(_, sqrt(zi) : ba.linear2db :
> hbargraph("[2]sqrt(ms_envelope_rect)",-95,0)),
> attach(_, ziR : ba.linear2db : hbargraph("[3]rms_envelope_rect",-95,0));
>
>
> > El 7 jul 2021, a las 9:59, Klaus Scheuermann 
> escribió:
> >
> > 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  >> > 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  >>
> 

Re: [Faudiostream-users] lufs loudness analyser

[Juan Carlos Blancas]

Hi Klaus, 

Same here, it seems there is something with ms and rms_envelope.

Best,
Juan Carlos

import("stdfaust.lib");

rms(n) = _ : square : mean(n) : sqrt;
square(x) = x * x;
mean(n) = float2fix : integrate(n) : fix2float : /(n); 
integrate(n,x) = x - x@n : +~_;
float2fix(x) = int(x*(1<<20));  
fix2float(x) = float(x)/(1<<20);

Tg = 0.4;
zi  = an.ms_envelope_rect(Tg);
ziR = an.rms_envelope_rect(Tg);

process = no.noise*1.737 * 
ba.db2linear(hslider("[0]g[unit:dB]",-20,-95,-10,0.1)) <:
attach(_, rms(ma.SR*Tg) : ba.linear2db : hbargraph("[1]rms",-95,0)),
attach(_, sqrt(zi) : ba.linear2db : 
hbargraph("[2]sqrt(ms_envelope_rect)",-95,0)),
attach(_, ziR : ba.linear2db : hbargraph("[3]rms_envelope_rect",-95,0));


> El 7 jul 2021, a las 9:59, Klaus Scheuermann  escribió:
> 
> 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 > > 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 >
>>> >> 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 

Re: [Faudiostream-users] lufs loudness analyser

[Dario Sanfilippo]

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  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  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 
> 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  > > > 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, 

Re: [Faudiostream-users] lufs loudness analyser

[Stéphane Letz]

« 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  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  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  > > 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  > 
> > > >> 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
> > 

Re: [Faudiostream-users] lufs loudness analyser

[Julius Smith]

By the way, the "*(0.5)" is because the mean-square envelope has no square
root, so it's in power units.
We should add something like this to basics.lib:
power2db(g) = 10.0*log10(g);

On Wed, Jul 7, 2021 at 9:31 AM Julius Smith  wrote:

> 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 
> 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 > > > 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
>> > 
>> > > >> 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 

Re: [Faudiostream-users] lufs loudness analyser

[Julius Smith]

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  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  > > 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  > 
> > > >> 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
> > 

Re: [Faudiostream-users] lufs loudness analyser

[Klaus Scheuermann]

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  > 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  
> > >> 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 

Re: [Faudiostream-users] lufs loudness analyser

[Stéphane Letz]

> 
> What does the '!' do?
> 

Never too late to have a look at the Faust syntax documentation ((-;, see 
https://faustdoc.grame.fr/manual/syntax/#cut-primitive for the ‘!’ symbol.

Stéphane 

___
Faudiostream-users mailing list
Faudiostream-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/faudiostream-users

Re: [Faudiostream-users] lufs loudness analyser

[Julius Smith]

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  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  > > 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 

Re: [Faudiostream-users] lufs loudness analyser

[Klaus Scheuermann]

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  > 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)
> 

Re: [Faudiostream-users] lufs loudness analyser

[Julius Smith]

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  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  > > wrote:
> >
> > Hello everyone :)
> >
> > Would someone be up for helping me implement an LUFS loudness
> analyser
> > in faust?
> >
> > Or has someone done it already?
> >
> >   

Re: [Faudiostream-users] lufs loudness analyser

[Klaus Scheuermann]

> 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  > 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 
> 
> Specifications (in Annex 1):
> 
> 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
> 
> 
> 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
> 
> https://lists.sourceforge.net/lists/listinfo/faudiostream-users
> 

Re: [Faudiostream-users] lufs loudness analyser

[Klaus Scheuermann]

Thank you very much, Julius!
I will take some time to fully understand and then get back to you :)
Awesome.
Klaus


On 04.07.21 04:49, Julius Smith wrote:
> Hi Klaus,
> 
> I can never resist these things!   Faust makes it too enjoyable :-)
> 
> 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  > 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 
> 
> Specifications (in Annex 1):
> 
> 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
> 
> 
> 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
> 
> 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

Re: [Faudiostream-users] lufs loudness analyser

[Julius Smith]

Hi Klaus,

I can never resist these things!   Faust makes it too enjoyable :-)

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  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
>
> Specifications (in Annex 1):
>
> 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
>
> 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
> 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