Re: [Faudiostream-users] fause2sndfile

[Julius Smith]

What do you get when you say
pkg-config --cflags --static --libs sndfile
?


On Wed, May 22, 2024 at 3:17 PM Bob Bobsled  wrote:

> fedora 39 using
>
> libsndfile .x86_64  1.1.0-9.fc39
> libsndfile-devel.x86_64 1.1.0-9.fc39
>
> bob
>
> On Tue, May 21, 2024 at 4:51 PM David Braun 
> wrote:
>
>> Maybe updating libsndfile could help? Before you do that, what version
>> are you using right now?
>>
>> On Tue, May 21, 2024 at 7:57 PM Bob Bobsled 
>> wrote:
>>
>>> Hi,
>>> I've made a new build of Faust on Fedora39, but having several issues.
>>>
>>> One is EXTERNAL_MPEG_LIBS
>>>
>>> import("stdfaust.lib");
>>> process = no.noise <: _,_;
>>>
>>> faust2sndfile mynoise.dsp
>>>
>>> see: /usr/bin/ld: cannot find @EXTERNAL_MPEG_LIBS@
>>>
>>> I'm wondering what is missing?
>>>
>>> Thank you,
>>> bob
>>> ___
>>> 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
>


-- 
"Anything that can be automated should optionally be"
https://x.com/javilopen/status/1779086252148494580
___
Faudiostream-users mailing list
Faudiostream-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/faudiostream-users

Re: [Faudiostream-users] debug help needed

[Julius Smith]

Hi Autumn,

Yes, resonbp is very simple and not protected against Q changes that can
blow up its dynamic range.  To guard against this you can apply smoothing
(si.smooth()) to the Q and frequency parameters, and keep them within
reasonable limits.

The next level up would be to replace tf2 in its implementation with
something like tf2snp which is formulated to have much less variation in
dynamic range when the parameters change quickly.

Cheers,
Julius

On Thu, Dec 28, 2023 at 8:00 AM Autumn Cheney via Faudiostream-users <
faudiostream-users@lists.sourceforge.net> wrote:

> as before, i'm working on a vocoder. i added some features since my last
> thread, and they're what this is about
>
> here's my program so far:
>
> import("stdfaust.lib");
>
> select4(s) = *(s==0),*(s==1),*(s==2),*(s==3):>_;
> clip(x,a,b) = min(max(x,a),b);
>
> n = 16;
>
> time(x) = hgroup("[0]time controls",x);
>
> attack = time(vslider("[0]attack[style:knob][unit:ms]",50,0,2000,0.1));
> release = time(vslider("[1]release[style:knob][unit:ms]",50,0,2000,0.1));
>
> op(x) = hgroup("[1]operator controls",x);
>
> car(x) = op(hgroup("[0]carrier controls",x));
> mod(x) = op(hgroup("[0]modulator controls",x));
>
>
> mod_order = mod(nentry("[0]modulator
> order[style:menu{'-12db':0;'-24db':1;'-36db':2;'-48db':3}}]",0,0,3,1));
> mod_bw = mod(vslider("[1]modulator bw[style:knob]",0.5,0.1,2,0.001));
>
> car_order = car(nentry("[0]carrier
> order[style:menu{'-12db':0;'-24db':1;'-36db':2;'-48db':3}}]",0,0,3,1));
> car_bw = car(vslider("[1]carrier bw[style:knob]",0.5,0.1,2,0.001));
>
> fx(x) = vgroup("[2]effects",x);
> self_mod = fx(checkbox("[0]self-modulate"));
> form_shift = fx(hslider("[1]formant shift[unit:%]",1,0.5,3,0.01));
> range = fx(hslider("[1]range",1,0.01,1,0.01));
>
>
> misc(x) = hgroup("[3]misc controls",x);
> out_gain = misc(hslider("output gain[unit:db]",0,-48,48,0.01));
>
>
> bp(freq,q,gain) = fi.resonbp(freq,q,gain/q);
> multi_bp(freq,q,gain,order) =
> _<:bp(freq,q,gain),(bp(freq,q,gain):bp(freq,q,gain)),(bp(freq,q,gain):bp(freq,q,gain):bp(freq,q,gain)),(bp(freq,q,gain):bp(freq,q,gain):bp(freq,q,gain):bp(freq,q,gain)):>select4(order):_*((order)+1);
>
> voc_band(band_num,bands_num,shift,bw_ratio,order,bg,x) = x :
> multi_bp(band_freq, band_q, bg, order) : _ with {
> band_freq = (25*pow(2,(band_num+1)*(9/bands_num)))*shift;
> bw = (band_freq - 25*pow(2,(band_num)*(9/bands_num)))*bw_ratio;
> band_q = band_freq/bw;
> };
>
> voc(bands_num,att,rel,form_shift,range,mod_bw,mod_order,car_bw,car_order,carrier,modulator)
> = carrier <: par(i,bands_num,voc_band(i,bands_num,range,mod_bw,mod_order,1)
> : an.amp_follower_ar(att,rel) : _,modulator :
> voc_band(i,bands_num,form_shift*range,car_bw,car_order)) :> _;
>
> x = _,_ <: !,_,_,!;
>
> process =
> _,_,_,_<:(_,x,_),((_<:_,_),(_<:_,_),!,!):(par(i,4,_*(1-self_mod)),par(i,
> 4,_*(self_mod))):>par(i,2,voc(n,attack/1000,release/1000,form_shift,range,mod_bw,mod_order,car_bw,car_order)):par(i,2,_*ba.db2linear(out_gain));
>
> when i run the program and adjust the "formant shift" and "range" sliders
> with audio input and the "self-modulate" checkbox enabled, at certain
> values a very loud signal is produced. it seems to depend on the value of
> either of the bandwidth parameters
>
> i think it might have to do with the resonbp q taking some value it
> shouldn't, but i don't know how to fix it
>
> incidentally, the "range" slider is meant to scale down the frequencies of
> both the modulator and carrier bands. and the "formant shift" scales up or
> down the frequencies of the carrier band only
>
> thanks for any help in advance
>
> a
> ___
> Faudiostream-users mailing list
> Faudiostream-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/faudiostream-users
>


-- 
"Anything that can be automated should optionally be"
___
Faudiostream-users mailing list
Faudiostream-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/faudiostream-users

Re: [Faudiostream-users] [PATCH] minor optimizations for ba.time/period/pulse

[Julius Smith]

I can imagine pulse-wave LFOs that need correct timing over some long time
period but don't mind length-jitter on individual pulses

On Sun, Nov 26, 2023 at 1:52 PM Dario Sanfilippo 
wrote:

> On Sun, 26 Nov 2023 at 19:40, Oleg Nesterov  wrote:
>
>> On 11/26, Julius Smith wrote:
>> >
>> > Sure, that sounds like efficient new expanded capabilities to me.
>> > I am curious to know what the driving application was for that one?
>>
>> I have no idea ;)
>>
>> But at the same time I have no idea what people do with ba.pulse(p) (which
>> truncates 'p' to int), I know almost nothing about the audio processing
>> and
>> absolutely nothing about the audio synthesis.
>>
>
> I often use it to get the magnitude response plot of filters while
> changing params, so in that case it doesn't matter much if the period is
> truncated. I have a pulse function that I use to trigger grains in a
> granulator and, for that, I check the first diff of a phasor for float
> periods.
>
> I know that using the phasor is more expensive but I like that negative
> periods give you the anti-pulse function. :-)
>
> Ciao,
> Dario
>
>
>> All I can say is that if I send the output from "process = pulsef(P)" to
>> the
>> soundcard it does not sound nice, but I can certainly hear the difference
>> between P == 441.0 (100Hz with SR=44100) and P == 441.9 or even P ==
>> 441.5.
>> While ba.pulse() simply truncates 441.* to the integer == 441.
>>
>> Oleg.
>>
>>

-- 
"Anything that can be automated should optionally be"
___
Faudiostream-users mailing list
Faudiostream-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/faudiostream-users

Re: [Faudiostream-users] [PATCH] minor optimizations for ba.time/period/pulse

[Julius Smith]

Sure, that sounds like efficient new expanded capabilities to me.
I am curious to know what the driving application was for that one?
It leads to the whole bandlimited pulse-train story...

On Sun, Nov 26, 2023 at 8:41 AM Oleg Nesterov  wrote:

> On 11/25, Julius Smith wrote:
> >
> > Hey, perfection is often a minor step forward!
>
> ;)
>
> > I would simply say that there is no difference for constant p, but in the
> > time-varying case there is a new one-sample delay preventing bit-for-bit
> > compatibility.
>
> OK, thanks. I'll try to do something more meaningful and possibly change
> period/pulse "while at it".   Again, I am shy to spam
> github.com/grame-cncm
> with such a trivial change.
>
> For example, do you think the new
>
> pulsef(period) = tick ~ -(1) : !,_ with {
> tick(acc) = select2(pulse, acc, acc+period), pulse
> with { pulse = acc <= 0; };
> };
>
> makes sense?
>
> Like ba.pulse() but "period" can be float. So pulsef(2.5) outputs
>
> 1 0  1 0 0  1 0  1 0 0 ...
>
> iow, ba.time / (pulsef(P) : +~_) "converges" to P.
>
> At the same time, if P is integer it does not uses floating point,
> and (according to my naive testing) it is 14% faster than ba.pulse
> because it doesn't use the division.
>
> Oleg.
>
>

-- 
"Anything that can be automated should optionally be"
___
Faudiostream-users mailing list
Faudiostream-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/faudiostream-users

Re: [Faudiostream-users] [PATCH] minor optimizations for ba.time/period/pulse

[Julius Smith]

Hey, perfection is often a minor step forward!

I would simply say that there is no difference for constant p, but in the
time-varying case there is a new one-sample delay preventing bit-for-bit
compatibility.

On Sat, Nov 25, 2023 at 12:18 PM Oleg Nesterov  wrote:

> Hi Julius,
>
> On 11/25, Julius Smith wrote:
> >
> > I see that I am missing out by not being on Discord!
>
> I think that all the technical questions/discussions should be moved
> to the faudiostream mailing lists, in this case I would be happy to
> forget about discord ;)
>
> > I like the changes but see that the ones depending on p are not exactly
> > equivalent when p is time-varying.
>
> Yes, and I even tried to document this in the changelog.
>
> I _think_ this can't make a real harm because (I think) it is hardly
> possible to predict what does period/pulse do if 'p' changes even at
> control rate.
>
> But since both you and Dario have some concerns (thank you both!) -
> lets forget this change.
>
> > In general I vote for elegance and optimality over exact equivalence,
> > although such changes should be called out in the release notes.
>
> Well... Again, these changes are so trivial and minor... Plus I
> simply do not know how to document the change in behaviour. So lets
> forget it.
>
> Thank you!
>
> Oleg.
>
>

-- 
"Anything that can be automated should optionally be"
___
Faudiostream-users mailing list
Faudiostream-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/faudiostream-users

Re: [Faudiostream-users] [PATCH] minor optimizations for ba.time/period/pulse

[Julius Smith]

Hi All,

I see that I am missing out by not being on Discord!

I like the changes but see that the ones depending on p are not exactly
equivalent when p is time-varying.
In general I vote for elegance and optimality over exact equivalence,
although such changes should be called out in the release notes.
(See the JUCE distribution for excellent practices in their
file BREAKING_CHANGES.md.)

Cheers,
Julius

On Sat, Nov 25, 2023 at 8:27 AM Oleg Nesterov  wrote:

> On 11/25, Dario Sanfilippo wrote:
> >
> > Possibly not a big deal, but the reason why ba.pulse checks for the
> > derivative is that ba.period is likely to wrap around and end up at value
> > different than zero when you lower the period, which can result in missed
> > pulses.
>
> Yes, as I mentioned below the changes in period/pulse are not 100%
> compatible.
> And I won't argue if you think that "I don't think this can break
> something"
> is not true.
>
> Thanks for looking at this!
>
> Oleg.
>
> > See this example:
> >
> > import("stdfaust.lib");
> > period(p) = %(int(p)) ~ +(1) : mem;
> > pulse2(p) = period(p) : \(x).(x <= x');
> > pulse(p) = period(p) == 0;
> > process = 100 - (10 @ 90) - (10 @ 170) - (10 @ 240) <: period ,
> pulse*100 ,
> > pulse2*100;
> >
> > Dr Dario Sanfilippo
> > http://dariosanfilippo.com
> >
> >
> > On Sat, 25 Nov 2023 at 16:23, Oleg Nesterov  wrote:
> >
> > > Stephane,
> > >
> > > I am shy to disturb https://github.com/grame-cncm/faustlibraries with
> > > such a trivial/random change(s), but I'd like to "finish" the recent
> > > discussion on discord. Note that even ba.time is obviously suboptimal.
> > > I can make a PR if you think this makes any sense.
> > >
> > > - ba.time: eliminate -(1)
> > >
> > >   before:
> > > iRec0[0] = iRec0[1] + 1;
> > > output0[i0] = FAUSTFLOAT(iRec0[0] + -1);
> > > iRec0[1] = iRec0[0];
> > >   after:
> > > iRec0[0] = iRec0[1] + 1;
> > > output0[i0] = FAUSTFLOAT(iRec0[1]);
> > > iRec0[1] = iRec0[0];
> > >
> > > - ba.period: eliminate the delay line created by 1'
> > >   with p == 10
> > >
> > >   before:
> > > iVec0[0] = 1;
> > > iRec0[0] = (iVec0[1] + iRec0[1]) % 10;
> > > output0[i0] = FAUSTFLOAT(iRec0[0]);
> > > iVec0[1] = iVec0[0];
> > > iRec0[1] = iRec0[0];
> > >   after:
> > > iRec0[0] = (iRec0[1] + 1) % 10;
> > > output0[i0] = FAUSTFLOAT(iRec0[1]);
> > > iRec0[1] = iRec0[0];
> > >
> > >   this change is not 100% compatible when p modulates,
> > >   but I don't think this can break something.
> > >
> > > - ba.pulse: simplify the condition, obvious.
> > > ---
> > >  basics.lib | 6 +++---
> > >  1 file changed, 3 insertions(+), 3 deletions(-)
> > >
> > > diff --git a/basics.lib b/basics.lib
> > > index 6c1fc87..ed3e9c5 100644
> > > --- a/basics.lib
> > > +++ b/basics.lib
> > > @@ -448,7 +448,7 @@ sweep = %(int(*:max(1)))~+(1);
> > >  // time : _
> > >  // ```
> > >  //
> > > -time = (+(1)~_) - 1;
> > > +time = +(1)~_ : mem;
> > >
> > >
> > >  //---`(ba.)ramp`--
> > > @@ -525,7 +525,7 @@ tempo(t) = (60*ma.SR)/t;
> > >  // * `p`: period as a number of samples
> > >  //
> > >  // NOTE: may be this should go in oscillators.lib
> > > -period(p) = %(int(p))~+(1');
> > > +period(p) = %(int(p)) ~ +(1) : mem;
> > >
> > >
> > >  //---`(ba.)pulse`--
> > > @@ -542,7 +542,7 @@ period(p) = %(int(p))~+(1');
> > >  // * `p`: period as a number of samples
> > >  //
> > >  // NOTE: may be this should go in oscillators.lib
> > > -pulse(p) = period(p) : \(x).(x <= x');
> > > +pulse(p) = period(p) == 0;
> > >
> > >
> > >  //---`(ba.)pulsen`--
> > > --
> > > 2.25.1.362.g51ebf55
> > >
> > >
> > >
> > >
> > > ___
> > > 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
>


-- 
"Anything that can be automated should optionally be"
___
Faudiostream-users mailing list
Faudiostream-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/faudiostream-users

Re: [Faudiostream-users] simple method to add harmonics to any quad oscillator

[Julius Smith]

Hi Oleg,

That all looks good to me - cool new operator!

Ideas for xxx:
  sidebands
  trigexpand
  trig_harmonics

We were really looking for this kind of thing back in the 70s!

Cheers,
- Julius



On Tue, Nov 14, 2023 at 10:53 AM Oleg Nesterov  wrote:

> On 08/21, Oleg Nesterov wrote:
> >
> > On 08/20, Julius Smith wrote:
> > >
> > > Pretty fun!  This looks closely related Andy Moorer's technique:
> > >
> > > @ARTICLE{MoorerDSF75,
> > > AUTHOR = "James A. Moorer",
> > > TITLE = "The Synthesis of Complex Audio Spectra by Means of
> > > Discrete Summation Formulae",
> > > JOURNAL = JAES,
> > > VOLUME = 24,
> > > PAGES = {717--727},
> > > MONTH = dec,
> > > NOTE = "Also available as CCRMA Report no.
> > > \htmladdnormallink{STAN-M-5}{
> https://ccrma.stanford.edu/STANM/stanms/stanm5/
> > > }",
> > > YEAR = 1975
> > > }
> >
> > Thanks! At first glance I don't think this is very closely related
> > but interesting.
>
> So yes, this is another thing, I'll try to make another PR, I already
> have the code. Let's finish this discussion first.
>
> > > I vote in favor of the addition provided its well documented in its
> > > comments -> MarkDown extraction.
>
> OK. Please see the (same) code with the docs below.
>
> Is the documentation good enough for PR?
>
> And of course, how should I name xxx and yyy ? ;)
>
> Oleg.
>
>
>
> //-`(os.)xxx`--
> // adds harmonics to quad oscillator.
> //
> //  Usage
> //
> // ```
> //cos(x),sin(x) : xxx(vs) : _,_
> // ```
> //
> // Where:
> //
> // * `vs` : list of amplitudes
> //
> //  Example test program
> //
> // ```
> //cos(x),sin(x) : xxx((10,20,30))
> // ```
> //
> // outputs
> //
> //10*cos(x) + 20*cos(2*x) + 30*cos(3*x),
> //10*sin(x) + 20*sin(2*x) + 30*sin(3*x);
> //
> // ```
> //process = os.quadosc(F) : xxx((10,20,30))
> // ```
> //
> // is (modulo floating point issues) the same as
> //
> //c = os.quadosc : _,!;
> //s = os.quadosc : !,_;
> //process =
> //10*c(F) + 20*c(2*F) + 30*c(F),
> //10*s(F) + 20*s(2*F) + 30*s(F);
> //
> // but much more efficient.
> //
> //  Implementation Notes
> //
> // This is based on the trivial trigonometric identities:
> //
> //cos((n + 1) x) = 2 cos(x) cos(n x) - cos((n - 1) x)
> //sin((n + 1) x) = 2 cos(x) sin(n x) - sin((n - 1) x)
> //
> // note that the calculation of the cosine/sine parts do not depend
> // on each other, so if you only need the sine part you can do
> //
> //process = os.quadosc(F) : xxx(vs) : !,_;
> //
> // and compiler will discard the half of the calculations.
>
> //-
> xxx(vs, c0,s0)
> = c0*vn(0),s0*vn(0), 1,c0, 0,s0
> : seq(n, outputs(vs)-1, add(vn(n+1)))
> : _,_, !,!, !,!
> with {
> // ba.take(n+1, vs)
> vn(n) = vs : route(outputs(vs),1, n+1,1);
>
> add(vn, co,so, cn_2,cn_1, sn_2,sn_1) =
> co+cn*vn, so+sn*vn, cn_1,cn, sn_1,sn
> with {
> cn = 2*c0*cn_1 - cn_2;
> sn = 2*c0*sn_1 - sn_2;
> };
> };
>
>
> //-`(os.)yyy`--
> // creates the list of complex harmonics from quad oscillator.
> //
> // Similar to `xxx` but doesn't sum the harmonics, so it is more
> // generic but less convenient for immediate usage.
> //
> //  Usage
> //
> // ```
> //cos(x),sin(x) : yyy(N) : si.bus(2*N)
> // ```
> //
> // Where:
> //
> // * `N` : number of harmonics, compile time constant > 1
> //
> //  Example test program
> //
> // ```
> //cos(x),sin(x) : yyy(3)
> // ```
> //
> // outputs
> //
> //cos(x),sin(x),  cos(2*x),sin(2*x),  cos(3*x),sin(3*x);
> //
> // ```
> //process = os.quadosc(F) : yyy(3)
> // ```
> //
> // is (modulo floating point issues) the same as
> //
> //process = os.quadosc(F), os.quadosc(2*F), os.quadosc(3*F);
> //
> // but much more efficient.
>
> //-
> yyy(N, c0,s0)
> = c0,s0, 1,c0, 0,s0
> : seq(n, N-1, si.bus(2*(n+1)), add)
> : si.bus(2*N), !,!, !,!
> with {
> add(cn_2,cn_1, sn_2,sn_1) =
> cn,sn, cn_1,cn, sn_1,sn
> with {
> cn = 2*c0*cn_1 - cn_2;
> sn = 2*c0*sn_1 - sn_2;
> };
> };
>
>

-- 
"Anything that can be automated should optionally be"
___
Faudiostream-users mailing list
Faudiostream-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/faudiostream-users

Re: [Faudiostream-users] faust2cagtk fails on -osc

[Julius Smith]

Hi Henrik,

I'm on Mac OS Ventura Version 13.5.2 and faust2caqt works fine for me.
My qt5 was installed by MacPorts.

Julius

On Thu, Sep 21, 2023 at 5:35 AM Henrik Frisk  wrote:
>
> Hi,
>
> I can't seem to get faust to compile with -osc enabled. I'm getting the
following response:
>
> ld: library 'OSCFaust' not found
> clang: error: linker command failed with exit code 1 (use -v to see
invocation)
>
> Reading this thread I have looked for and removed all other libOSCfaust
files on my system.
>
> This is on 2.68.1 installed with brew on MacOS 13.5.2
>
> (BTW after upgrading to Ventura I can't compile to caqt anymore).
>
> Tried the online compiler but the resulting .app would not load at all.
On faustlive osc does appear to be working 2.54.9.
>
> Henrik
> ___
> Faudiostream-users mailing list
> Faudiostream-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/faudiostream-users



--
"Anything that can be automated should optionally be"
___
Faudiostream-users mailing list
Faudiostream-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/faudiostream-users

Re: [Faudiostream-users] simple method to add harmonics to any quad oscillator

[Julius Smith]

Pretty fun!  This looks closely related Andy Moorer's technique:

@ARTICLE{MoorerDSF75,
AUTHOR = "James A. Moorer",
TITLE = "The Synthesis of Complex Audio Spectra by Means of
Discrete Summation Formulae",
JOURNAL = JAES,
VOLUME = 24,
PAGES = {717--727},
MONTH = dec,
NOTE = "Also available as CCRMA Report no.
\htmladdnormallink{STAN-M-5}{https://ccrma.stanford.edu/STANM/stanms/stanm5/
}",
YEAR = 1975
}

I think there's even a patent.

I vote in favor of the addition provided its well documented in its
comments -> MarkDown extraction.

Cheers,
Julius

On Sun, Aug 20, 2023 at 3:55 PM Oleg Nesterov  wrote:

> Hello,
>
> When I was playing with fb_fcomb(), I accidentally noticed this
> trigonometric identity (thanks to maxima):
>
> cos(x)*sin(n*x) = (sin((n+1)*x)+sin((n-1)*x))/2
>
> and it gave me idea to write the following:
>
> harmonics(vs, c0,s0)
> = c0*vn(0),s0*vn(0), 1,c0, 0,s0
> : seq(n, outputs(vs)-1, add(vn(n+1)))
> : _,_, !,!, !,!
> with {
> vn(n) = ba.take(n+1, vs);
>
> add(vn, co,so, cn_2,cn_1, sn_2,sn_1) =
> co+cn*vn, so+sn*vn, cn_1,cn, sn_1,sn
> with {
> cn = 2*c0*cn_1 - cn_2;
> sn = 2*c0*sn_1 - sn_2;
> };
> };
>
> What does it do. For example, for any x
>
> cos(x), sin(x) : harmonics((10,20,30))
>
> outputs
>
> 10*cos(x) + 20*cos(2*x) + 30*cos(3*x),
> 10*sin(x) + 20*sin(2*x) + 30*sin(3*x);
>
> (of course, modulo floating point issues)
>
> IOW,
>
> qo(f) = os.oscrq(f);// or any other complex oscillator
> process = qo(f) : harmonics((10,20,30));
>
> acts as
>
> // pseuodo code, x * qo(...) won't compile
> process = 10*qo(f) + 20*qo(2*f) + 30*qo(3*f);
>
> but it is more simple/cheap.
>
>
> ---
> Note that it does not use the
>
> [ c0  -s0 ]
> [ s0   c0 ]
>
> rotation matrix, and this means that
>
> - we save one multiplication in the calculation of each harmonic
>
> - more importantly, the calculations of cn and sn do not depend
>   on each other.
>
>   So if you only need the "sines" part you can do
>
> qo : harmonics(volumes_list) : !,_;
>
>   and compiler will discard the half of the calculations.
>
>
> ---
> Questions:
>
> - does it make sense to add this function to oscillators.lib ?
>
> - is it a known method? I am just curious.
>
>
> ---
> Just in case... perhaps the more "generic" version makes more sense:
>
> harmonics_parallel(N, c0,s0)
> = c0,s0, 1,c0, 0,s0
> : seq(n, N-1, (si.bus(2*(n+1)),add))
> : si.bus(2*N), !,!, !,!
> with {
> add(cn_2,cn_1, sn_2,sn_1) =
> cn,sn, cn_1,cn, sn_1,sn
> with {
> cn = 2*c0*cn_1 - cn_2;
> sn = 2*c0*sn_1 - sn_2;
> };
> };
>
> so that
>
> qo(f) : harmonics_parallel(3);
>
> outputs
>
> qo(f), qo(2*f), qo(3*f);
>
> Oleg.
>
>

-- 
"Anything that can be automated should optionally be"
___
Faudiostream-users mailing list
Faudiostream-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/faudiostream-users

Re: [Faudiostream-users] Q: fb_comb/fb_fcomb implementation

[Julius Smith]

Nice!  I like the generalization of delay interpolation while keeping
backward compatibility. I would only suggest a more foreground name for
fb_xxx, such as fb_comb_common, suggesting that it's a function shared by
the other feedback-comb variations, and that it's a "helper" function not
normally called by itself (no mem protection, e.g.).  Then I would also add

fb_f4acomb(maxdel) = fb_comb_common(de.fdelay4a(maxdel)) : mem;

plus perhaps others, as people need them.
(I still follow the "define it when you really need it" rule myself.)

Cheers,
Julius

On Fri, Aug 18, 2023 at 2:13 AM Oleg Nesterov  wrote:

> Hi Julius,
>
> On 08/17, Julius Smith wrote:
> >
> > Hi Oleg,
> >
> > This looks good to me. I believe I wrote the original fb_comb in
> > filter.lib, but I don't remember the extra output delay at all. If I did
> > it, my wild guess is that I was working from some old CCRMA documentation
> > for unit generators on the Samson Box that had the extra delay due to its
> > hardware constraints.  I do recall aiming to reproduce the main
> > reverberators in use at CCRMA back in the day.  I can also imagine it's
> to
> > ensure that the forward delay is at least one so that one can throw
> > feedback around fb_comb.   That seems reasonable for users who might get
> > into trouble otherwise.
>
> Thanks! I was afraid I missed some subtleties in this simple code ;)
>
> > While I am happy to adopt any equivalent rewrite, maybe it is too obvious
> > to mention that we should keep the extra delay (assuming it was
> introduced
> > long ago), simply to not break anything that depends on it.
>
> Sure, agreed.
>
> but again, even if we keep the extra delay we can rewrite fb_comb() as
>
> fb_comb(maxdel,N,b0,aN) = + ~ -aN * de.delay(maxdel,N-1) : *(b0) :
> mem;
>
> to make it simpler, generate a better code, and avoid the extra fRec[2]
> delay line. Same for fb_fcomb().
>
> > We could use a
> > new name for your leaner version.
>
> Well... not sure the new helper makes sense, but may be something like
>
> fb_xxx(dop,N,b0,aN) = + ~ -aN * dop(N-1) : *(b0);
>
> Then we can rewrite fb_comb/fb_fcomb as
>
> fb_comb(maxdel) = fb_xxx(de.delay(maxdel)) : mem;
> fb_fcomb(maxdel) = fb_xxx(de.fdelay(maxdel)) : mem;
>
> and I actually did this to use
>
> fb_xxx(de.fdelay4a(maxdel))
>
> because delay/fdelay didn't work well for me.
>
> Oleg.
>
>

-- 
"Anything that can be automated should optionally be"
___
Faudiostream-users mailing list
Faudiostream-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/faudiostream-users

Re: [Faudiostream-users] Q: fb_comb/fb_fcomb implementation

[Julius Smith]

Hi Oleg,

This looks good to me.  I believe I wrote the original fb_comb in
filter.lib, but I don't remember the extra output delay at all. If I did
it, my wild guess is that I was working from some old CCRMA documentation
for unit generators on the Samson Box that had the extra delay due to its
hardware constraints.  I do recall aiming to reproduce the main
reverberators in use at CCRMA back in the day.  I can also imagine it's to
ensure that the forward delay is at least one so that one can throw
feedback around fb_comb.   That seems reasonable for users who might get
into trouble otherwise.

While I am happy to adopt any equivalent rewrite, maybe it is too obvious
to mention that we should keep the extra delay (assuming it was introduced
long ago), simply to not break anything that depends on it.  We could use a
new name for your leaner version.

Cheers,
Julius

On Thu, Aug 17, 2023 at 12:39 PM Oleg Nesterov  wrote:

> Hello,
>
> This is not a bug-report or something like this, just I am curios.
> Yesterday I was playing with fi.fb_fcomb() and I'm a bit puzzled.
> Let's talk about fb_comb() first, they both have the same pattern.
> Two questions:
>
> -
> Why does it have ": mem" at the end? This makes sense sometimes but
>
> - its purpose is not documented.
>
> - the comment refers to ~jos/paspFeedback_Comb_Filters.html
>   but with this "mem" the difference equation doesn't match
>   that of mentioned in the link above.
>
> - user can easily add ": mem" himself if needed.
>
> -
> But the main question is that the part before ": mem"
>
> (+ <: de.delay(maxdel,N-1),_) ~ *(-aN) : !,*(b0)
>
> looks suboptimal and overcomplicated to me. I mean,
>
> + ~ -aN * de.delay(maxdel,N-1) : *(b0);
> or
> *(-aN) + *(b0) ~ de.delay(maxdel,N-1);
>
> should do the same but
>
> - look more simple/understandable
>
> - do not create the extra delay line
>
> -
> Let's compare the generated code just in case.
>
> f1(maxdel,N,b0,aN) = (+ <: de.delay(maxdel,N-1),_) ~ *(-aN) :
> !,*(b0);
> f2(maxdel,N,b0,aN) = + ~ -aN * de.delay(maxdel,N-1) : *(b0);
>
> Current implementation:
>
> process = f1(10,10, .3, .7);
>
> compiles to
>
> float fVec0[10];
> float fRec0[2];
> int fSampleRate;
>
> void compute(int count, FAUSTFLOAT** inputs, FAUSTFLOAT** outputs)
> {
> FAUSTFLOAT* input0 = inputs[0];
> FAUSTFLOAT* output0 = outputs[0];
> for (int i0 = 0; i0 < count; i0 = i0 + 1) {
> float fTemp0 = float(input0[i0]) - 0.7f * fRec0[1];
> fVec0[0] = fTemp0;
> fRec0[0] = fVec0[9];
> float fRec1 = fTemp0;
> output0[i0] = FAUSTFLOAT(0.3f * fRec1);
> for (int j0 = 9; j0 > 0; j0 = j0 - 1) {
> fVec0[j0] = fVec0[j0 - 1];
> }
> fRec0[1] = fRec0[0];
> }
> }
>
> while
>
> process = f2(10,10, .3, .7);
>
> compiles to
>
> float fRec0[11];
> int fSampleRate;
>
> void compute(int count, FAUSTFLOAT** inputs, FAUSTFLOAT** outputs)
> {
> FAUSTFLOAT* input0 = inputs[0];
> FAUSTFLOAT* output0 = outputs[0];
> for (int i0 = 0; i0 < count; i0 = i0 + 1) {
> fRec0[0] = float(input0[i0]) - 0.7f * fRec0[10];
> output0[i0] = FAUSTFLOAT(0.3f * fRec0[0]);
> for (int j0 = 10; j0 > 0; j0 = j0 - 1) {
> fRec0[j0] = fRec0[j0 - 1];
> }
> }
> }
>
> and to me f2() certainly looks more readable than f1().
>
> Thanks,
>
> Oleg.
>
>

-- 
"Anything that can be automated should optionally be"
___
Faudiostream-users mailing list
Faudiostream-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/faudiostream-users

Re: [Faudiostream-users] Problems with faust2caqt

[Julius Smith]

Hi All,

I am using the latest faust2caqt on the latest Mac OS with no trouble.
However, I happen to have ncurses installed via MacPorts.  You should be
able to make faust2caqt use the brew version, as you have, but it's
probably easier to "port install ncurses" to make it happy as is.  I am
using both brew and MacPorts and it seems to work out fine, although there
is significant duplication here and there.

Cheers,
Julius



On Tue, Mar 21, 2023 at 7:39 AM Henrik Frisk  wrote:

>
>
> Den tis 21 mars 2023 kl 15:09 skrev Stéphane Letz :
>
>>
>>
>> > Le 21 mars 2023 à 14:57, Henrik Frisk  a écrit :
>> >
>> > Hi,
>> >
>> > I have recently changed computer from Linux (where faust have always
>> run like a charm) to macos and I've run into some problems. Having
>> downloaded the latest 2.54.9 as a dmg and installed it. Having tested
>> several fasut2* (fasut2caqt for example) yields:
>> >
>> > dyld[38924]: Library not loaded: '/opt/local/lib/libncurses.6.dylib'
>> >
>> > ncurses is installed and the particular library is in
>> /opt/homebrew/opt/ncurses/lib/ (installed via brew). Regardless how I try I
>> can't get the scrript to find it. I have tried
>> >
>> >  export PATH="/opt/homebrew/opt/ncurses/bin:$PATH"'
>> >   export LDFLAGS="-L/opt/homebrew/opt/ncurses/lib"
>> >   export CPPFLAGS="-I/opt/homebrew/opt/ncurses/include"
>> >   export PKG_CONFIG_PATH="/opt/homebrew/opt/ncurses/lib/pkgconfig"
>> >
>> > I have also tried to reinstall ncurses.
>>
>> Hi Henrik,
>>
>> Yes, this is a known problem: compiled binaries are not correctly
>> self-contained. David Braun is working on improving the situation using
>> GitHub actions. You can possibly test the precompiled 2.58.11 version here:
>> https://github.com/DBraun/faust/actions/runs/4458934421
>
>
> Ok, will try later!
>
>>
>> > Installing Faust through homebrew gets rid of the above problem but
>> instead, for faust2caqt, it gives the error
>> >
>> > /opt/homebrew/Cellar/qt@5/5.15.8_2/mkspecs/features/mac/default_post.prf:284:
>> Variable QMAKE_XCODE_DEVELOPER_PATH is not defined
>> >
>> > I suspect this all has to do with my limited knowledge about how macos
>> deals ith dependencies, but any help would be appreciated!
>> >
>> > /Henrik
>> >
>>
>> QT is currently not working on my machine ((-; . Hoping others (like
>> Julius maybe?) can help here.
>>
>
> I'm hoping for Julius too!
>
> /h
> ___
> Faudiostream-users mailing list
> Faudiostream-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/faudiostream-users
>


-- 
"Anything that can be automated should be"
___
Faudiostream-users mailing list
Faudiostream-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/faudiostream-users

Re: [Faudiostream-users] [OT] Discord blues

[Julius Smith]

I just created a "Test Discussion" on GitHub Discussions under the Faust
project, but I've received no email notification. I'm enabled for all
activity on the Faust project.  I also entered a test reply.  Does
something need to be enabled that isn't?  Or maybe I just don't get
notifications about what I do.

-- 
"Anything that can be automated should be"
___
Faudiostream-users mailing list
Faudiostream-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/faudiostream-users

Re: [Faudiostream-users] [OT] Discord blues

[Julius Smith]

I was avoiding Discord as well because they messed up my account in a way
that could not be fixed without creating a new email address (which is
something _I_ refuse to do).  I finally got around it by coming in on the
Mac app instead of a browser.  Apparently their browser support is pretty
broken.

I vote for email!  The only downside I see is the accumulating indented
copies of prior emails in the thread.   However, if all clients can
organize threads by subject like gmail does, we can stop including those in
our replies.

- Julius

On Wed, Mar 15, 2023 at 4:15 PM Christopher Arndt 
wrote:

> Am 15.03.23 um 18:05 schrieb Marc Lavallée via Faudiostream-users:
> > Hoping I could still join he party, I sent a message to Discord,
> > asking how I could get in. I came to the conclusion that it won't
> > happen, and it's for the best. I'm not asking the Faust community to
> > choose some other messaging platform, so have fun and stay safe.
>
> Discord is an illness that needs to purged.
>
> Modern chat platforms are ill suited for serious technical discussions
> in any case, in my opinion, because they make it hard to focus the
> attention on a specific topic.
>
> Anyway, if you must use one, at least use one that doesn't make it
> mandatory to give a foreign company my personally identifiable
> information and collects data as business.
>
> Too many communities are willingly, but unnecessarily colluding with
> this s*t and excluding users. There are enough free and decentralized
> options.
>
>
> Chris
>
>
>
> ___
> Faudiostream-users mailing list
> Faudiostream-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/faudiostream-users
>


-- 
"Anything that can be automated should be"
___
Faudiostream-users mailing list
Faudiostream-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/faudiostream-users

Re: [Faudiostream-users] Triangle LFO with controllable phase?

[Julius Smith]

I think writing the triangle-wave from scratch as Dario did is the best way
to go when possible.  Using a delay-line to add phase delay is more
general, and makes sense when you can't rewrite the oscillator, but then
you're probably going to want interpolated delay, such as fdelay1 or
better, and that's more expensive in cases such as this where the delay can
easily be included in the original synthesis formulation.

Separately, it's great to be fixing compilation issues that arise as
Stéphane is doing!

Cheers,
- Julius


On Sun, Feb 26, 2023 at 7:17 AM Christopher Arndt 
wrote:

> On Sat, Feb 25, 2023 at 4:05 PM Dario Sanfilippo
> mailto:sanfilippo.da...@gmail.com>> wrote:
> >
> > Here is a non-delay-based alternative (tested very briefly, but it
> > seems to work):
> >
> > On Sun, 26 Feb 2023 at 00:28, Julius Smith  > <mailto:julius.sm...@gmail.com>> wrote:
> > Here is my updated test program (no scope needed - I used
> > faust2caqt):
>
> Great, I'll test those tonight.
>
> Many thanks!
>
> Chris
>
>
> ___
> Faudiostream-users mailing list
> Faudiostream-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/faudiostream-users
>


-- 
"Anything that can be automated should be"
___
Faudiostream-users mailing list
Faudiostream-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/faudiostream-users

Re: [Faudiostream-users] Triangle LFO with controllable phase?

[Julius Smith]

I encountered that too and reported it to Stephane.  faust2caqt had no
problem.  Looking forward to hearing what that's about!

On Sat, Feb 25, 2023 at 4:05 PM Dario Sanfilippo 
wrote:

> Just so you know, Julius' code gives me this assert on the IDE:
>
> ASSERT : please report this message and the failing DSP file to Faust
> developers (file: wasm_code_container.hh, line: 60, version: 2.54.11,
> options: -lang wasm-ib -cn
> a08c5ceec105cc33e58fe2dfaaa8d2f0a80eaf39e4a593811bb636d3de7a14d3 -es 1 -mcd
> 16 -single -ftz 0 )
>
> Here is a non-delay-based alternative (tested very briefly, but it seems
> to work):
>
>  import("stdfaust.lib");
>
> PI = ma.PI;
> TWOPI = 2.0 * ma.PI;
>
> phasor(freq, phase) = ma.frac((loop ~ _) + phase / TWOPI)
> with {
> loop(y) = ma.frac(freq / ma.SR + y);
> };
>
> tri(ph) = abs(ma.frac(ph - .25) * 4.0 - 2.0) - 1.0;
> ph0 = hslider("ph0", 0, -PI, PI, .001);
> ph1 = hslider("ph1", -PI / 2.0, -PI, PI, .001);
> f = hslider("freq[scale:log]", 1000, 20, 20480, .001);
>
> // Oscillation by phase-mod
> // process = os.oscp(0, os.phasor(TWOPI, 1000)) ,
> // sin(TWOPI * phasor(0, os.phasor(TWOPI, 1000))) ,
> // tri(phasor(0, os.phasor(TWOPI, 1000)));
>
> process = os.oscp(f, ph0) ,
> os.oscp(f, ph1) ,
> sin(phasor(f, ph0) * TWOPI) ,
> sin(phasor(f, ph1) * TWOPI) ,
> tri(phasor(f, ph0)) ,
> tri(phasor(f, ph1));
>
> Dr Dario Sanfilippo
> http://dariosanfilippo.com
>
>
> On Sun, 26 Feb 2023 at 00:28, Julius Smith  wrote:
>
>> Ok, I see it.  The implementation of os.lf_sawpos_phase is impulse-based:
>>
>> lf_sawpos_phase(freq,phase) = phasor_imp(freq, (1-1'), phase);
>>
>> This means it is only sampled at time zero.  For continuous phase
>> control, you want something delay based, e.g.,
>>
>> lf_triangle_phase (freq, phase) = os.lf_triangle(freq) @ (phase *
>> ma.SR/freq);
>>
>> Here is my updated test program (no scope needed - I used faust2caqt):
>>
>> import("stdfaust.lib");
>>
>> lf_triangle_phase(freq, phase) = os.lf_triangle(freq) @ (phase *
>> ma.SR/freq);
>> lfo_freq = hslider("[1] Freq", 0.5, 0.001, 50, 0.01);
>> lfo1 = lf_triangle_phase(lfo_freq, 0);
>> lfo_phase = hslider("[2] Phase", 180, 0, 360, 1) / 360;
>> lfo2 = lf_triangle_phase(lfo_freq, lfo_phase);
>> process =  lfo1, lfo2 : hbargraph("[3] 0",-1,1), hbargraph("[4]
>> Phase",-1,1);
>>
>> On Sat, Feb 25, 2023 at 2:03 PM Christopher Arndt 
>> wrote:
>>
>>> Am 24.02.23 um 21:50 schrieb Julius Smith:
>>> > Hmmm, it looks to me like it should be working.
>>> > I adapted your test program for use with faust2plot, and it's working
>>> > for me:
>>>
>>> Yes, it works, if the phase is set initially. But what I want is to
>>> change the phase of one LFO at run-time with a parameter and that
>>> doesn't seem to work.
>>>
>>> Here are two images, which demonstrate this, I hope:
>>>
>>> 1) your code (lfophase.dsp) compiled with faust2jack and its output send
>>> into a stereo oscilloscope. the two LFOs have different phase
>>>
>>> https://0x20.eu/nc/s/kWSwRE2oHD4rStt/preview
>>>
>>> 2) The code from my original post (lfophase2.dsp) compiled with
>>> faust2jaqt again with its output into the scope. I have set the phase
>>> two 91 after staring the program, but the output as seen in the scope
>>> never changes and the two LFOs are still at the same phase.
>>>
>>> https://0x20.eu/nc/s/Y47eaLK8DGZZTbk/preview
>>>
>>>
>>> Chris
>>>
>>>
>>>
>>> ___
>>> Faudiostream-users mailing list
>>> Faudiostream-users@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/faudiostream-users
>>>
>>
>>
>> --
>> "Anything that can be automated should be"
>> ___
>> Faudiostream-users mailing list
>> Faudiostream-users@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/faudiostream-users
>>
>

-- 
"Anything that can be automated should be"
___
Faudiostream-users mailing list
Faudiostream-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/faudiostream-users

Re: [Faudiostream-users] Triangle LFO with controllable phase?

[Julius Smith]

Ok, I see it.  The implementation of os.lf_sawpos_phase is impulse-based:

lf_sawpos_phase(freq,phase) = phasor_imp(freq, (1-1'), phase);

This means it is only sampled at time zero.  For continuous phase control,
you want something delay based, e.g.,

lf_triangle_phase (freq, phase) = os.lf_triangle(freq) @ (phase *
ma.SR/freq);

Here is my updated test program (no scope needed - I used faust2caqt):

import("stdfaust.lib");

lf_triangle_phase(freq, phase) = os.lf_triangle(freq) @ (phase *
ma.SR/freq);
lfo_freq = hslider("[1] Freq", 0.5, 0.001, 50, 0.01);
lfo1 = lf_triangle_phase(lfo_freq, 0);
lfo_phase = hslider("[2] Phase", 180, 0, 360, 1) / 360;
lfo2 = lf_triangle_phase(lfo_freq, lfo_phase);
process =  lfo1, lfo2 : hbargraph("[3] 0",-1,1), hbargraph("[4]
Phase",-1,1);

On Sat, Feb 25, 2023 at 2:03 PM Christopher Arndt 
wrote:

> Am 24.02.23 um 21:50 schrieb Julius Smith:
> > Hmmm, it looks to me like it should be working.
> > I adapted your test program for use with faust2plot, and it's working
> > for me:
>
> Yes, it works, if the phase is set initially. But what I want is to
> change the phase of one LFO at run-time with a parameter and that
> doesn't seem to work.
>
> Here are two images, which demonstrate this, I hope:
>
> 1) your code (lfophase.dsp) compiled with faust2jack and its output send
> into a stereo oscilloscope. the two LFOs have different phase
>
> https://0x20.eu/nc/s/kWSwRE2oHD4rStt/preview
>
> 2) The code from my original post (lfophase2.dsp) compiled with
> faust2jaqt again with its output into the scope. I have set the phase
> two 91 after staring the program, but the output as seen in the scope
> never changes and the two LFOs are still at the same phase.
>
> https://0x20.eu/nc/s/Y47eaLK8DGZZTbk/preview
>
>
> Chris
>
>
>
> ___
> Faudiostream-users mailing list
> Faudiostream-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/faudiostream-users
>


-- 
"Anything that can be automated should be"
___
Faudiostream-users mailing list
Faudiostream-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/faudiostream-users

Re: [Faudiostream-users] Triangle LFO with controllable phase?

[Julius Smith]

Hmmm, it looks to me like it should be working.
I adapted your test program for use with faust2plot, and it's working for
me:

import("stdfaust.lib");

saw1_phase(freq, phase) = 2.0 * os.lf_sawpos_phase(freq, phase) - 1.0;
lf_trianglepos_phase(freq, phase) = 1.0 - abs(saw1_phase(freq, phase));
lf_triangle_phase(freq, phase) = 2.0 * lf_trianglepos_phase(freq, phase)
   - 1.0;

//lfo_freq = hslider("Freq", 30, 0.001, 50, 0.01);
lfo_freq = ma.SR/16;

//lfo1 = os.lf_triangle(lfo_freq);
lfo1 = lf_triangle_phase(lfo_freq,0);

//lfo_phase = hslider("Phase", 180, 0, 360, 1) / 360;
lfo_phase = 8.0/16.0;
lfo2 = lf_triangle_phase(lfo_freq, lfo_phase);

process =  lfo1 * 0.2, lfo2 * 0.2;

On Fri, Feb 24, 2023 at 9:34 AM Christopher Arndt 
wrote:

> Hi all,
>
> I want to modulate two delays with two LFOs, which have a phase offset.
>
> Using os.oscp works, but the library does not contain a triangle osc
> with phase control. So tried to make one by copy-pasting from the
> oscillator.lib:
>
> import("stdfaust.lib");
>
> saw1_phase(freq, phase) = 2.0 * os.lf_sawpos_phase(freq, phase) - 1.0;
> lf_trianglepos_phase(freq, phase) = 1.0 - abs(saw1_phase(freq, phase));
> lf_triangle_phase(freq, phase) = 2.0 * lf_trianglepos_phase(freq, phase)
>- 1.0;
>
> However, when I try to use this with a parameter controlling the phase
> like this:
>
> lfo_freq = hslider("Freq", 30, 0.001, 50, 0.01);
> lfo_phase = hslider("Phase", 0, 0, 360, 1) / 360;
> lfo1 = os.lf_triangle(lfo_freq);
> lfo2 = lf_triangle_phase(lfo_freq, lfo_phase);
> process =  lfo1 * 0.2, lfo2 * 0.2;
>
> the lfo_phase param does have any effect, the phase of both LFOs is
> always the same.
>
> What am I missing?
>
> Chris
>
>
> ___
> Faudiostream-users mailing list
> Faudiostream-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/faudiostream-users
>


-- 
"Anything that can be automated should be"
___
Faudiostream-users mailing list
Faudiostream-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/faudiostream-users

Re: [Faudiostream-users] chebyshev approximation in faust

[Julius Smith]

Thanks for the interesting examples.

Shouldn't we fix ba.tabulate().cub to be _exact_ (to working precision)
when the desired function is cubic or less?


On Sun, Nov 27, 2022 at 12:45 PM Oleg Nesterov  wrote:

> On 11/27, Oleg Nesterov wrote:
> >
> > On 11/25, Julius Smith wrote:
> > >
> > > I would expect ba.tabulate() to be unbeatable when the function being
> > > sampled is actually linear, quadratic, or cubic,
> >
> > Well ;) If the function is cubic then chebtab() will win even with NX=1.
> > Ignoring the floating point issues, chebtab() will be simply equal to
> > the approximated function. If the function is "nearly cubic", chebtab()
> > should likely win anyway, I guess, but this depends.
>
> Let me provide a couple of stupid test-cases just in case ;)
>
> CK = 1;
> FX(x) = x^3 - 2*x^2 - 100* x - 1;
> X0 = 0;
> X1 = 10;
> NX = 50;
> CD = 3;
>
> // Both ch() and tb() create rdtable of size=200 and both use cubic
> // polynomial, so this comparison is more or less fair.
> ch(x) = chebtab(CK, FX, NX, CD,X0,X1, x);
> tb(x) = ba.tabulate(CK, FX, NX*(CD+1), X0,X1, x).cub;
>
> maxerr = abs : max ~ _;
>
> line(n, x0,x1) = x0 + (ba.time%n)/n * (x1-x0);
> process = line(5, X0,X1) <: FX-tb,FX-ch : par(i,2,maxerr);
>
> compiled with -a plot.cpp
>
> $ /tmp/c-plot -n 5  | tail -1
> 0.600803971 5.68434189e-13
>
> e-13 is just the floating point errors. The close result if I change ch(x)
> to use NX=1.
>
> Lets add some "noise" to FX,
>
> FX(x) = x^3 - 2*x^2 - 100* x - 1 + sin(x); // sin(x) is small
> compared to poly
>
> Now,
>
> $ /tmp/c-plot -n 5  | tail -1
> 0.59773165  5.20619665e-07
>
> OK, lets recall that ba.tabulate() doesn't play well near X0, X1, lets help
> tabulate() to be more accurate:
>
> // ensure that ba.tabulate() always have at least 4 valid points
> offs = 4 * (X1-X0) / (NX*(CD+1));
> process = line(5, X0+offs,X1-offs) <: FX-tb,FX-ch :
> par(i,2,maxerr);
>
> now ba.tabulate() works MUCH better but chebtab() still wins:
>
> $ /tmp/c-plot -n 5  | tail -1
> 1.42467743e-05  5.20622848e-07
>
> Oleg.
>
>

-- 
"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] chebyshev approximation in faust

[Julius Smith]

I would expect ba.tabulate() to be unbeatable when the function being
sampled is actually linear, quadratic, or cubic, and chebtab to win for
functions having large-magnitude series-expansion coefficients beyond the
cubic term.

- Julius

On Fri, Nov 25, 2022 at 3:46 PM Oleg Nesterov  wrote:

> Damn ;)
>
> Julius, Stéphan, I am sorry forthe extra noise but
>
> On 11/25, Oleg Nesterov wrote:
> >
> > Yesterday I played with ba.tabulate() and I think we can have a better
> > helper
>
> When I re-read my email it looks as if I state that chebtab() is always
> better than ba.tabulate().
>
> Of course it is not! This depends on FX,NX,CD. Sorry if it was not clear.
>
> Oleg.
>
>

-- 
"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] chebyshev approximation in faust

[Julius Smith]

Excellent!
+1
Thanks very much!
- Julius


On Fri, Nov 25, 2022 at 12:48 PM Oleg Nesterov  wrote:

> Hello,
>
> Yesterday I played with ba.tabulate() and I think we can have a better
> helper which approximates an unary function using chebyshev polynomials
> more accurately:
>
> chebtab(CK, FX, NX,CD, X0,X1, x) = y with {
> ck(0) = _;
> ck(1) = max(0) : min(NX-1);
>
> NC =  CD + 1;
> DX = (X1 - X0) / NX;
> nx = (x  - X0) / DX : int : ck(CK);
> xc(n) = X0 + DX * (n + 1/2);
> ch(i) = chtab(NC * nx + i);
>
> y = (x - xc(nx)) * 2/DX <: sum(i,NC, ch(i) *
> ma.chebychev(i));
>
> mapfx(nx, x) = FX(xc(nx) + DX/2 * x);
>
> gench(nx, nc) = (1+(nc!=0))/NC * sum(k,NC,
> mapfx(nx, cos(ma.PI*(k+1/2)/NC)) *
> cos(ma.PI*nc*(k+1/2)/NC));
>
> chtab = rdtable(NX*NC, (ba.time <: int(/(NC)), %(NC) :
> gench));
> };
>
> Usage:
>
> _ : chebtab(CK, FX, NX,CD, X0,X1) : _
>
> Where
> CK: force the index in [X0, X1] range
>
> FX: unary function
>
> NX: number of segments
> CD: degree of the chebyshev polynomials
>
> X0: range minimal value
> X1: range maximal value
>
> chebtab() splits the interval [X0,X1] into NX segments, and for each
> segment
> it calculates CD+1 coefficients for ma.chebychev(0) .. ma.chebychev(CD).
> IOW,
> it uses rdtable as 2-dimensional array [NX][CD+1], so its size is NX *
> (CD+1).
>
> Lets compare chebtab() with ba.tabulate().cub, test-case:
>
> CK = 0;
> FX = sin;
> NX = 50;
> CD = 3;
> X0 = 0;
> X1 = ma.PI;
>
> // Both ch() and tb() create rdtable of size = 200, both use
> // cubic polynomials, so this comparison is more or less fair.
> ch(x) = chebtab(CK, FX, NX, CD,X0,X1, x);
> tb(x) = ba.tabulate(CK, FX, NX*(CD+1), X0,X1, x).cub;
>
> maxerr = abs : max ~ _;
> line(n, x0,x1) = x0 + (ba.time%n)/n * (x1-x0);
> process = line(5, X0,X1) <: FX-tb,FX-ch : par(i,2,maxerr);
>
> Now,
>
> $ cheb-plot -n 5 | tail -1
>
> 0.00349552557   5.07155429e-09
>
> as you can see chebtab() is much more accurate. And according to my quick
> testing it is even a little bit faster but I won't insist on that.
>
> Just in case... tabulate().cub can be improved, it.interpolate_cubic() is
> simply wrong near X0 or X1, but chebtab() will be more accurate anyway.
>
> Do you think it can live in basics.lib ?
>
> Oleg.
>
>

-- 
"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] Name conflit generating DSP for Juce audioProcessor

[Julius Smith]

Hi Simon,

Here is my usage (from a tcsh script):

set faustCompiler = "/usr/local/bin/faust"
set faustOptions = "-scn $parentClass -a $archfile -cn $outputName -inpl
-uim -i"
...
$faustCompiler $faustOptions $dspfile -o $dest/$outputFile

I think the most important option for you is -cn, but I'm not sure since
you don't show your naming conflicts (others are possible).
I agree --namespace has problems and I don't use it myself.

- Julius

On Mon, Nov 7, 2022 at 3:49 AM Simon Hill  wrote:

> Hello,
>
> I’m following the « Faust for the confined » tutorial (
> https://faustdoc.grame.fr/workshops/2020-04-10-faust-juce/) to integrate
> faust dsp into a Juce application using «  faust -i -a faustMinimal.h
> FaustEffect.dsp -o Effect/Source/FaustEffect.h »
> I’m able to integrate the example echo effect in my app, but when I try to
> integrate other effects I run into naming conflicts.
> Searching the compiler manual, I see there is a «  --namespace  »
> option, which sound like it would solve my problem.
> However this only adds a namespace around all the generated code,
> including the includes, which prevents compilation.
>
> The solution I found is adding a namespace by hand around every class in
> FaustEffect.h, but I don’t really understand everything in this file and
> would prefer not to change it by hand for each effect that I will need.
>
> So here is my question : *Is this the proper approach to integrate
> multiple separate effects inside a Juce application ?*
>
> Thank you
>
> Simon
>
> ___
> 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] New Python examples using Faust, JAX, and the Box API

[Julius Smith]

Yes, kudos!

I can't wait to try optimizing some Faust models using gradient descent!

In principle, this solves the training problem for
/examples/filtering/DNN.dsp, right?

Cheers,
- Julius

On Thu, Oct 20, 2022 at 11:16 AM Stéphane Letz  wrote:
>
> Hi David,
>
> Thanks for this awesome contribution !  Hopefully opening an entirely new 
> world in the Machine Learning domain for the Faust ecosystem!
>
> Cheers,
>
> Stéphane
>
> > Le 20 oct. 2022 à 12:48, David Braun  a écrit :
> >
> > Faust now supports the machine learning framework JAX as a backend. 
> > DawDreamer is a python module where you can conveniently convert Faust code 
> > to JAX. DawDreamer has two new Colabs demonstrating this Faust to JAX 
> > pipeline:
> >   • Faust to JAX: Optimize parameters using gradient descent.
> >   • Faust to QDax: Optimize with Quality-Diversity algorithms.
> > There's an additional notebook covering the Box API in Python. You can 
> > access the intermediate representation of Faust, programmatically compose 
> > boxes, then render audio with DawDreamer, or transpile to a target language 
> > (C++, JAX, Rust, etc.).
> >
> > More information in the tweet: 
> > https://twitter.com/DoItRealTime/status/1583042473227452416
> >
> > Please check out the Colabs, and feel free to contact me.
> >
> > Best,
> >
> > David
> > ___
> > Faudiostream-users mailing list
> > Faudiostream-users@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/faudiostream-users
>
>
>
> ___
> Faudiostream-users mailing list
> Faudiostream-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/faudiostream-users



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


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

Re: [Faudiostream-users] pm.modeFilter producing extremely loud signal

[Julius Smith]

Hi Florian,

I see that pm.modeFilter uses fi.tf2, which is not designed to accept such
fast coefficient modulations.
I would try replacing that with fi.tf2np, which is more expensive, but
better behaved under extreme modulation.

Cheers,
- Julius


On Tue, Aug 30, 2022 at 11:43 AM Ly Sigk  wrote:

> Dear Faust community,
>
> I am currently doing some experiments with pm.modeFilter and am
> running into some issues that I can't find a solution for.
>
> When "pinging" pm.modeFilter with a simple trigger while modulating
> its frequency, I occasionally get extremely loud, clipping signals.
> Here is a code example that produces this behaviour:
>
> // WARNING - VERY LOUD SIGNAL
> import("stdfaust.lib");
> trig = ba.pulsen(1, ma.SR / 4);
> freq = no.noise : ba.sAndH(trig) * 12 : abs : rint * 200;
> process = trig : pm.modeFilter(freq, 0.6, 0.1) <: _, _;
>
> In this case I am using a sample-and-hold to get one of the first 12
> harmonics of the base frequency (200 hz).
>
> Interestingly, the issue does not occur when instead using a fixed
> filter frequency or modulating it randomly without constraint to the
> harmonics. Could switching between the harmonics be the cause of the
> issue, maybe by causing some unwanted additional resonance that gets
> out of control?
>
> I'd be happy for any hints on how to get the filter working as expected.
>
> Best,
> Florian
>
>
> ___
> 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]

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

[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

[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

[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

[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

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

[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] multiply two signals with a third

[Julius Smith]

How about:

process(x,y,z) = x*z, y*z;

On Sat, Feb 26, 2022 at 9:33 AM David Braun 
wrote:

> I would prefer using a parameterized function which enables some
> re-usability. Check out how each of these works in the IDE.
> import("stdfaust.lib");
> myMultiply(gain, sig1, sig2) = sig1*gain, sig2*gain;
> //process = _, _, _ : myMultiply;
> //process = os.osc(440), os.osc(880) : sp.stereoize(_*.1);
> process = os.osc(440), os.osc(880) : myMultiply(0.1);
>
> On Sat, Feb 26, 2022 at 8:40 AM Meng Qi  wrote:
>
>> _,_,_ <: _,!,_,!,_,_ : _*_,_*_ : _,_;
>>
>> Regards,
>> /M.Q. 
>> http://www.mengqimusic.com
>>
>>
>> Klaus Scheuermann  于2022年2月26日周六 23:57写道：
>>
>>> Hi All,
>>>
>>> stuck again ;) How do I multiply two signals each with a third one and
>>> output the two signals?
>>>
>>> _,_,_ : ??? : _,_
>>>
>>> Thanks, 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
>>
> ___
> 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] [Faudiostream-devel] Open Science Award for Open Source Research Software for Faust

[Julius Smith]

Congratulations!!!

Richly deserved indeed!

- Julius

On Sat, Feb 5, 2022 at 8:43 AM Yann Orlarey  wrote:

> Great birthday present for the 20th anniversary of the FAUST language!
> Developed by Grame since 2002, supported by a whole community of users and
> contributors, FAUST is one of the four winners of the Open Science Award
> for Open Source Research Software (documentation category) awarded at the
> Open Science European Conference (OSEC).
>
>
> https://www.ouvrirlascience.fr/remise-des-prix-science-ouverte-du-logiciel-libre-de-la-recherche/
>
> D. Fober, S. Letz, R. Michon, Y. Orlarey
>
>
> *Yann Orlarey*
> Directeur scientifique/Scientific director
>
>
> orla...@grame.fr  T : +33 (0) 4 72 07 37 00
> GRAME - Centre national de création musicale
> 11 cours de Verdun Gensoul | 69002 Lyon
> www.grame.fr | facebook  | instagram
>  | twitter
> 
> ___
> Faudiostream-devel mailing list
> faudiostream-de...@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/faudiostream-devel
>


-- 
"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] Median filter

[Julius Smith]

You should be able to subtract median3 from medianFilter(3) in Faust and
get 0 as the optimized output - Julius

On Sun, Jan 9, 2022 at 1:49 AM Dario Sanfilippo 
wrote:

> Hello, Julius and Alik.
>
> I'm new to median filters but we should be able to use the recently added
> sorting algorithm for arbitrary window lenghts; does the following look
> correct to you?
>
> import("stdfaust.lib");
> windowLen = 11; // it should be odd for symmetry
> medianFilter(L, x) = (x <: par(i, L, @(i))) : ro.bubbleSort(L) :
> ba.selectn(L, int(L / 2));
> process = no.noise <: _ , medianFilter(windowLen);
>
> Ciao,
> Dr Dario Sanfilippo
> http://dariosanfilippo.com
>
>
> On Sun, 9 Jan 2022 at 10:28, Julius Smith  wrote:
>
>> Hi Alik,
>>
>> This came up for me at some point:
>>
>> // Test order 3 median smoother:
>>
>> median3(a,b,c) = select3(s,b,a,c)
>> with {
>>   cf(a,b) = 2*(a>   s=abs(cf(a,b)+2*cf(b,c)+3*cf(c,a))/2;
>> };
>>
>> process = median3(1,2,3), median3(1,3,2), median3(2,1,3), median3(2,3,1),
>> median3(3,1,2), median3(3,2,1); // 2
>>
>> Cheers,
>> Julius
>>
>> On Sun, Jan 9, 2022 at 12:51 AM Alik Rustamoff 
>> wrote:
>>
>>> What is the way to make a median filter in faust?
>>>
>>> ___
>>> 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] Median filter

[Julius Smith]

Hi Alik,

This came up for me at some point:

// Test order 3 median smoother:

median3(a,b,c) = select3(s,b,a,c)
with {
  cf(a,b) = 2*(a
wrote:

> What is the way to make a median filter in faust?
>
> ___
> 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] master_me as LV2 on a streaming server

[Julius Smith]

Ah, I only looked at osx and windows-64.  If Linux is enough, then you
should be good to go.
I expect that choosing lv2-64bits on linux uses faust2lv2 under the hood,
but let's wait for Stéphane or someone to confirm.
- Julius

On Wed, Nov 10, 2021 at 1:42 AM Klaus Scheuermann  wrote:

> I do :)
>
> platform linux
> lv2-64bits
>
> Thanks!
> On 10.11.21 10:36, Julius Smith wrote:
>
> I think yes because I don't see an lv2 choice at faustide.
>
> On Wed, Nov 10, 2021 at 1:29 AM Klaus Scheuermann 
> wrote:
>
>> Hey Julius,
>>
>> it was created on faustide.grame.fr
>>
>> Would faust2lv2 do something different?
>>
>> Thanks, Klaus
>>
>>
>> On 10.11.21 10:25, Julius Smith wrote:
>>
>> Hi Klaus,
>>
>> How was master_me_voc.so created?  As far as I know, only
>> compiler options and perhaps something in an architecture file could cause
>> AVX2 to appear.
>>
>> Also why not use faust2lv2 to get lv2 already?
>>
>> Cheers,
>> - Julius
>>
>> On Wed, Nov 10, 2021 at 12:16 AM Klaus Scheuermann 
>> wrote:
>>
>>> Hello everyone,
>>>
>>> my plugin master_me_voc has beed further developed for speech-heavy
>>> content and is ready to be used on a Chaos Computer Club streaming server.
>>> It needs to be integrated as LV2 into an ffmpeg chain.
>>> https://github.com/trummerschlunk/master_me/blob/master/master_me_voc.dsp
>>>
>>> Which does cause some errors - your ongoing help is very much
>>> appreciated :)
>>>
>>> The plugin is compiled on faustide as LV2 and runs directly on the
>>> server which replies:
>>>
>>> ffmpeg -hide_banner -i 997Hz.wav -af
>>>  
>>> 'ladspa=file=/home/voc/.ladspa/master_me_voc.so:p=master_me_voc:c=c0=0|c1=-16|c2=0.095|c3=55|c4=55|c5=-50|c6=-22|c7=-4|c8=2|c9=150|c10=500|c11=2000|c12=6000|c13=2|c14=0'
>>>  test.mp3
>>>
>>>  zsh: illegal hardware instruction  ffmpeg -hide_banner -i 997Hz.wav -af  
>>> test.mp3
>>>
>>> (this was a test with LV1 but LV2 is desired in the end)
>>>
>>> So one guy from the streaming team debugged and came across an
>>> AVX2-dependency that the server's cpu does not support. Also he wrote that
>>> it does not seem to be needed.
>>>
>>> Any ideas on that?
>>>
>>> Sorry about the blurry descriptions. If it's easier, I would like to
>>> include two CCC guys. If I cc them, will they stay in the topic's
>>> recipients?
>>>
>>> Cheers,
>>>
>>> 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
>>
>>
>
> --
> "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] master_me as LV2 on a streaming server

[Julius Smith]

I think yes because I don't see an lv2 choice at faustide.

On Wed, Nov 10, 2021 at 1:29 AM Klaus Scheuermann  wrote:

> Hey Julius,
>
> it was created on faustide.grame.fr
>
> Would faust2lv2 do something different?
>
> Thanks, Klaus
>
>
> On 10.11.21 10:25, Julius Smith wrote:
>
> Hi Klaus,
>
> How was master_me_voc.so created?  As far as I know, only compiler options
> and perhaps something in an architecture file could cause AVX2 to appear.
>
> Also why not use faust2lv2 to get lv2 already?
>
> Cheers,
> - Julius
>
> On Wed, Nov 10, 2021 at 12:16 AM Klaus Scheuermann 
> wrote:
>
>> Hello everyone,
>>
>> my plugin master_me_voc has beed further developed for speech-heavy
>> content and is ready to be used on a Chaos Computer Club streaming server.
>> It needs to be integrated as LV2 into an ffmpeg chain.
>> https://github.com/trummerschlunk/master_me/blob/master/master_me_voc.dsp
>>
>> Which does cause some errors - your ongoing help is very much appreciated
>> :)
>>
>> The plugin is compiled on faustide as LV2 and runs directly on the server
>> which replies:
>>
>> ffmpeg -hide_banner -i 997Hz.wav -af
>>  
>> 'ladspa=file=/home/voc/.ladspa/master_me_voc.so:p=master_me_voc:c=c0=0|c1=-16|c2=0.095|c3=55|c4=55|c5=-50|c6=-22|c7=-4|c8=2|c9=150|c10=500|c11=2000|c12=6000|c13=2|c14=0'
>>  test.mp3
>>
>>  zsh: illegal hardware instruction  ffmpeg -hide_banner -i 997Hz.wav -af  
>> test.mp3
>>
>> (this was a test with LV1 but LV2 is desired in the end)
>>
>> So one guy from the streaming team debugged and came across an
>> AVX2-dependency that the server's cpu does not support. Also he wrote that
>> it does not seem to be needed.
>>
>> Any ideas on that?
>>
>> Sorry about the blurry descriptions. If it's easier, I would like to
>> include two CCC guys. If I cc them, will they stay in the topic's
>> recipients?
>>
>> Cheers,
>>
>> 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
>
>

-- 
"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] master_me as LV2 on a streaming server

[Julius Smith]

Hi Klaus,

How was master_me_voc.so created?  As far as I know, only compiler options
and perhaps something in an architecture file could cause AVX2 to appear.

Also why not use faust2lv2 to get lv2 already?

Cheers,
- Julius

On Wed, Nov 10, 2021 at 12:16 AM Klaus Scheuermann  wrote:

> Hello everyone,
>
> my plugin master_me_voc has beed further developed for speech-heavy
> content and is ready to be used on a Chaos Computer Club streaming server.
> It needs to be integrated as LV2 into an ffmpeg chain.
> https://github.com/trummerschlunk/master_me/blob/master/master_me_voc.dsp
>
> Which does cause some errors - your ongoing help is very much appreciated
> :)
>
> The plugin is compiled on faustide as LV2 and runs directly on the server
> which replies:
>
> ffmpeg -hide_banner -i 997Hz.wav -af
>  
> 'ladspa=file=/home/voc/.ladspa/master_me_voc.so:p=master_me_voc:c=c0=0|c1=-16|c2=0.095|c3=55|c4=55|c5=-50|c6=-22|c7=-4|c8=2|c9=150|c10=500|c11=2000|c12=6000|c13=2|c14=0'
>  test.mp3
>
>  zsh: illegal hardware instruction  ffmpeg -hide_banner -i 997Hz.wav -af  
> test.mp3
>
> (this was a test with LV1 but LV2 is desired in the end)
>
> So one guy from the streaming team debugged and came across an
> AVX2-dependency that the server's cpu does not support. Also he wrote that
> it does not seem to be needed.
>
> Any ideas on that?
>
> Sorry about the blurry descriptions. If it's easier, I would like to
> include two CCC guys. If I cc them, will they stay in the topic's
> recipients?
>
> Cheers,
>
> 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] Faust freeverb

[Julius Smith]

Hi Joachim,

Could your input be mono?  To check, change the last line of freeverb.dsp to

process = _ <: freeverb;

Cheers,
Julius

On Wed, Nov 3, 2021 at 2:25 AM Joachim Schneider 
wrote:

> Hello folks,
>
> I compiled the faust freeverb (
> https://github.com/grame-cncm/faust/blob/master-dev/benchmark/freeverb.dsp)
> into a pure data external on linux mint. It seems, the lower the wet level,
> the more it only outputs on the right stereo channel. If wet is set to
> zero, the left channel is completely mute. Any ideas? Thanks in advance! 
>
> BlueMail for Android  herunterladen
> ___
> 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] Would like separate .h and .cpp output rather than monolith

[Julius Smith]

Thanks!
I also got an email notice for this one, due to being "mentioned", but it's
not obvious to me how.


On Tue, Oct 12, 2021 at 8:55 PM Scott Tooby  wrote:

> Hi Julius,
>
> Steven K. and I have continued our conversation in the Faust Slack
> #general channel here...
> https://faustaudio.slack.com/archives/C0ZA8T51Q/p1634077830285800
>
> Cheers,
> Scott
>
> On Tue, Oct 12, 2021 at 3:19 PM Julius Smith 
> wrote:
>
>> Hi All,
>>
>> If the Slack discussion has begun, I could not find it - please let
>> me know if I need to keep looking for it
>>
>> Normally this sort of problem is solved by the JUCE Module system, which
>> as far as I can tell does require separate .h and .cpp files.
>> The .cpp files get fused into a nice library for linking, and the JUCE
>> module interfaces are all declared in a single #include
>> "../JuceLibraryCode/JuceHeader.h" line which in turn includes the .h files
>> for the modules selected for the project.  I've not tried to combine Faust
>> modules into JUCE modules yet, but surely that will happen eventually.
>>
>> If this is discussed further on Slack, someone please tell me!
>>
>> Thanks,
>> Julius
>>
>>
>> On Mon, Oct 11, 2021 at 9:46 PM Stéphane Letz  wrote:
>>
>>> Can we possibly continue the discussion on Faust Slack :
>>> https://join.slack.com/t/faustaudio/shared_invite/zt-a624szlz-fL4v2DTR~ZGlI7wARryT7g
>>> ?
>>>
>>> Thanks.
>>>
>>> Stéphane
>>>
>>> > Le 11 oct. 2021 à 23:07, Steven Kraninger  a
>>> écrit :
>>> >
>>> > Stéphane,
>>> >
>>> > The problem I have not yet solved is more complicated than I can put
>>> in an email but essentially:
>>> >
>>> > I have some "preset manager" type source files that I am trying to
>>> adapt based upon the Plugin Magic GUI code that is currently (mostly)
>>> working with the current faust2juce.
>>> >
>>> > The preset manager consists of 4 files, PresetComp.cpp, PresetComp.h,
>>> PresetManager.cpp, PresetManager.h.  both the PresetManager and the
>>> PresetComp classes need access to the AudioProcessor object (with
>>> associated AudioParameters), and currently do so by including a
>>> "AudioProcessor.h" file. I began to go about separating out a .h file for
>>> the AudioProcessor, but it proved to be difficult as there is quite a bit
>>> of object inter-connection.
>>> >
>>> > The current faust compiler and architecture files are brilliant, but
>>> it would be easier (for me) to understand and modify if there was more
>>> "directory/application structure" to the resulting output.
>>> >
>>> > Thanks
>>> > Steven Kraninger
>>> >
>>> > On Mon, Oct 11, 2021 at 3:52 PM Stéphane Letz  wrote:
>>> > What is the concrete problem you are facing ?
>>> >
>>> > Thanks.
>>> >
>>> > Stéphane
>>> >
>>> > > Le 11 oct. 2021 à 21:59, Scott Tooby  a
>>> écrit :
>>> > >
>>> > > Yes, +1. I'm interested in this too to make it easier to integrate
>>> FAUST generated C++ code into JUCE or other C++ codebases. Similarly, I've
>>> noticed only a single .cpp file is generated when exporting FAUST code to
>>> pure C++ source code (not the JUCE option), so in this case too it would be
>>> handy if a separate .h file was exported alongside the .cpp file. But if
>>> there is already a way to do this via the export process I'd appreciate
>>> being pointed in the right direction.
>>> > >
>>> > > Thank you,
>>> > > Scott Tooby
>>> > >
>>> > > On Mon, Oct 11, 2021 at 12:38 PM Steven Kraninger <
>>> skranin...@gmail.com> wrote:
>>> > > All,
>>> > >
>>> > > The current faust2juce script generates a single
>>> FaustPluginProcessor.cpp file.  I would like to have separate .h and .cpp
>>> files rather than copying them all inline into one .cpp file. I feel this
>>> would make it a bit easier to modify the program and add new features after
>>> generating it (in particular for the saving of plugin presets and
>>> modification of the UI).
>>> > > Is there any way to do this?
>>> > >
>>> > > Thanks
>>> > > Steven Kraninger
>>> > >
>>&

Re: [Faudiostream-users] Would like separate .h and .cpp output rather than monolith

[Julius Smith]

Hi All,

If the Slack discussion has begun, I could not find it - please let me know
if I need to keep looking for it

Normally this sort of problem is solved by the JUCE Module system, which as
far as I can tell does require separate .h and .cpp files.
The .cpp files get fused into a nice library for linking, and the JUCE
module interfaces are all declared in a single #include
"../JuceLibraryCode/JuceHeader.h" line which in turn includes the .h files
for the modules selected for the project.  I've not tried to combine Faust
modules into JUCE modules yet, but surely that will happen eventually.

If this is discussed further on Slack, someone please tell me!

Thanks,
Julius


On Mon, Oct 11, 2021 at 9:46 PM Stéphane Letz  wrote:

> Can we possibly continue the discussion on Faust Slack :
> https://join.slack.com/t/faustaudio/shared_invite/zt-a624szlz-fL4v2DTR~ZGlI7wARryT7g
> ?
>
> Thanks.
>
> Stéphane
>
> > Le 11 oct. 2021 à 23:07, Steven Kraninger  a
> écrit :
> >
> > Stéphane,
> >
> > The problem I have not yet solved is more complicated than I can put in
> an email but essentially:
> >
> > I have some "preset manager" type source files that I am trying to adapt
> based upon the Plugin Magic GUI code that is currently (mostly) working
> with the current faust2juce.
> >
> > The preset manager consists of 4 files, PresetComp.cpp, PresetComp.h,
> PresetManager.cpp, PresetManager.h.  both the PresetManager and the
> PresetComp classes need access to the AudioProcessor object (with
> associated AudioParameters), and currently do so by including a
> "AudioProcessor.h" file. I began to go about separating out a .h file for
> the AudioProcessor, but it proved to be difficult as there is quite a bit
> of object inter-connection.
> >
> > The current faust compiler and architecture files are brilliant, but it
> would be easier (for me) to understand and modify if there was more
> "directory/application structure" to the resulting output.
> >
> > Thanks
> > Steven Kraninger
> >
> > On Mon, Oct 11, 2021 at 3:52 PM Stéphane Letz  wrote:
> > What is the concrete problem you are facing ?
> >
> > Thanks.
> >
> > Stéphane
> >
> > > Le 11 oct. 2021 à 21:59, Scott Tooby  a écrit :
> > >
> > > Yes, +1. I'm interested in this too to make it easier to integrate
> FAUST generated C++ code into JUCE or other C++ codebases. Similarly, I've
> noticed only a single .cpp file is generated when exporting FAUST code to
> pure C++ source code (not the JUCE option), so in this case too it would be
> handy if a separate .h file was exported alongside the .cpp file. But if
> there is already a way to do this via the export process I'd appreciate
> being pointed in the right direction.
> > >
> > > Thank you,
> > > Scott Tooby
> > >
> > > On Mon, Oct 11, 2021 at 12:38 PM Steven Kraninger <
> skranin...@gmail.com> wrote:
> > > All,
> > >
> > > The current faust2juce script generates a single
> FaustPluginProcessor.cpp file.  I would like to have separate .h and .cpp
> files rather than copying them all inline into one .cpp file. I feel this
> would make it a bit easier to modify the program and add new features after
> generating it (in particular for the saving of plugin presets and
> modification of the UI).
> > > Is there any way to do this?
> > >
> > > Thanks
> > > Steven Kraninger
> > >
> > > ___
> > > Faudiostream-users mailing list
> > > Faudiostream-users@lists.sourceforge.net
> > > https://lists.sourceforge.net/lists/listinfo/faudiostream-users
> > > ___
> > > Faudiostream-users mailing list
> > > Faudiostream-users@lists.sourceforge.net
> > > https://lists.sourceforge.net/lists/listinfo/faudiostream-users
> >
>
>
>
> ___
> Faudiostream-users mailing list
> Faudiostream-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/faudiostream-users
>


-- 
"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] JUCE code generation question

[Julius Smith]

I believe the only difference between a struct and a class in C++ is that
class members are private by default.  So, "class foo { public: ... " is
equivalent to "struct foo { ...", if I understand correctly.   However, I'm
only "intermediate" at C++, so someone please correct me if I'm wrong or
incomplete.

- Julius


On Thu, Sep 30, 2021 at 5:47 PM Steven Kraninger 
wrote:

> Hi,
>
> Kind of a technical question, but I am wondering why a "struct" was used
> instead of a class to compose the juce::AudioParameterFloat and the
> uiOwnedItem?
>
> In the following code:
>
> struct FaustPlugInAudioParameterFloat : public juce::AudioParameterFloat,
> public uiOwnedItem {
> FaustPlugInAudioParameterFloat(GUI* gui, FAUSTFLOAT* zone, const
> std::string& path, const std::string& label, FAUSTFLOAT init, FAUSTFLOAT
> min, FAUSTFLOAT max, FAUSTFLOAT step)
> :juce::AudioParameterFloat(path, label, float(min), float(max),
> float(init)), uiOwnedItem(gui, zone)
> {}
>
> I would like to modify this a bit to accept a "skew" factor that could be
> passed into the juce "range" object (part of the AudioParameterFloat).
> Currently the min, max, and step are being passed as the  start, end, and
> interval.
>
> It seems like a class could have other initializers that could be called
> when creating a new FaustPluginAudioParameterFloat (not sure of the struct
> syntax)?
>
> Thanks
> Steven Kraninger
> ___
> 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] variable saw

[Julius Smith]

Does it suffice to cross-fade among waveforms?
This is done in virtual_analog_oscillator_demo()
in demos.lib

- Julius

On Fri, Sep 17, 2021 at 8:40 AM Stéphane Letz  wrote:

> Look at : https://faustlibraries.grame.fr/libs/oscillators/
>
> Stéphane
>
> > Le 14 sept. 2021 à 19:28, Roger Pibernat  a
> écrit :
> >
> > Hi,
> >
> > just starting with Faust, with quite a few years of SuperCollider behind
> my back but no math background whatsoever.
> >
> > Is there such a thing as a variable saw wave oscillator in Faust?  I'd
> like to be able to modulate between saw <> triangle <> ramp.  I cannot find
> it in the docs.
> >
> > I thought I could maybe feed an en.ar() into a phasor, but it doesn't
> seem to work (because an envelope is not a table?).
> >
> > How could it be done?
> >
> > cheers!
> >
> > Roger
> >
> > ___
> > Faudiostream-users mailing list
> > Faudiostream-users@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/faudiostream-users
>
>
>
> ___
> Faudiostream-users mailing list
> Faudiostream-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/faudiostream-users
>


-- 
"Anybody who knows all about nothing knows everything" -- Leonard Susskind
___
Faudiostream-users mailing list
Faudiostream-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/faudiostream-users

Re: [Faudiostream-users] Parallel operators

[Julius Smith]

Hi All,

ro.interleave() is one of those functions I have to look up every time
because I can never remember which argument order I need.  To address this,
I finally "documented it" for myself so I will never need to look it up
again.  (Documenting things is a great way to burn them into memory.)  Here
is what I wrote in case it's helpful for anyone else:

// demo_interleave.dsp

import("stdfaust.lib"); // $FAUSTLIBS/routes.lib:140

// A bank of parallel signals in Faust may be interpreted as a vector.
// In a matrix, each column is a vector.  A matrix of signals in Faust
// is thus a bank of columns, or successive columns laid out
// vertically.  For example, an M-by-N matrix appears as M signals
// (the first column), followed below by another M signals (the next
// column), and so on, for a total of N columns, or M*N signals.

// Matrix transposition is efficiently accomplished in Faust using the
// ro.interleave(M,N) function, whose input is MxN and output is NxM.
// It could have been called matrix_transpose().

// Example: Transpose a 10x2 input matrix to yield a 2x10 output matrix

nRowsIn = 10;
nColsIn = 2;
process = ro.interleave(nRowsIn,nColsIn);

// (View it using faust2firefox or the Faust IDE at
https://faustide.grame.fr/)


On Mon, Sep 13, 2021 at 1:43 AM Yann Orlarey  wrote:

> Hi Lucian,
>
> A useful function, in this type of routing, is `ro.interleave(N,M)`. It
> has the advantage of requiring less work for the compiler, especially when
> N or M is large.
>
>
> import("stdfaust.lib");
>
> N = 10;
> process = ro.interleave(N,2) : par(i,N,*);
>
>
>
> https://faustide.grame.fr/?autorun=0=0=nbinop=aW1wb3J0KCJzdGRmYXVzdC5saWIiKTsKCk4gPSAxMDsKcHJvY2VzcyA9IHJvLmludGVybGVhdmUoTiwyKSA6IHBhcihpLE4sKik7Cgo%3D
>
> Yann
>
> Le mar. 7 sept. 2021 à 15:30, Lucian Boca  a écrit :
>
>> Haha awesome, thanks James!
>>
>> I was just putting together a similar implementation based on your
>> previous email, ended up with:
>>
>> ```
>> bop(f, items) = par(i, N, f(ba.selector(i, N, items))) with { N =
>> ba.count(items); };
>> ```
>>
>> Super useful, thanks again!
>>
>> On Tue, Sep 7, 2021 at 2:26 PM James Mckernon 
>> wrote:
>>
>>> On 9/7/21, James Mckernon  wrote:
>>> > I haven't time to work out the details now.
>>>
>>> Why do I lie like this? I couldn't resist trying it. I think this
>>> should be you what you want.
>>>
>>> ba = library("basics.lib");
>>> bop(op, list) = par(i, ba.count(list), op(ba.take(i + 1,list)));
>>> process = (1,2,3,4) : bop(*, (2,3,4,5));
>>>
>> ___
>> Faudiostream-users mailing list
>> Faudiostream-users@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/faudiostream-users
>>
> ___
> Faudiostream-users mailing list
> Faudiostream-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/faudiostream-users
>


-- 
"Anybody who knows all about nothing knows everything" -- Leonard Susskind
___
Faudiostream-users mailing list
Faudiostream-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/faudiostream-users

Re: [Faudiostream-users] audio correlation meter

[Julius Smith]

And of course I mean "cross-correlation coefficient"

On Sun, Aug 8, 2021 at 3:22 PM Julius Smith  wrote:

> Hi Klaus,
>
> I am late to this (just read some of the thread with interest), and I have
> a question: what do you mean by "1 > corr(t,l,r) > 0" ?  It appears to be
> "parsed" left to right, so that the 2nd ">" only sees "1>0" most (all?) of
> the time, which is always true (1) of course (so no "else" activated).
> Maybe you want something like "abs(corr(t,l,r)) > 0.95" ?  (i.e., 95%
> correlation deemed to be "panned mono").  I'm taking the absolute value
> because I assume you don't care if the left channel is merely the negative
> of the right (unless that's an accepted cheezy "stereoizer" of sorts).
>
> FYI, this is what we call a time-domain "normalized cross-correlation" or
> "correlation coefficient" measurement (official buzzwords)
>
> Cheers,
> Julius
>
>
> On Sun, Aug 8, 2021 at 10:07 AM Klaus Scheuermann 
> wrote:
>
>> Dear Dario,
>>
>> cool, your corr function gives me the desired results. At least when
>> feeding it to a meter.
>>
>> Here is my test audio which contains vocals in mono-mid, mono-left,
>> mono-right, mono-half-left, mono-half-right, stereo:
>> https://cloud.4ohm.de/s/y9oZzqFGyrZT5ej
>> For mono-mid, mono-half-left, mono-half-right it shows 1.
>> For mono-left, mono-right it shows 0.
>> For stereo it shows values between 0 and 1.
>>
>> I would like to detect mono signals that are not exactly in the middle
>> and put them there. Stereo signals should be unchanged.
>>
>> My code is here, but for some reason it does not work correctly.
>> Especially when corr shows 0, ba.if does not go to the else-path.
>>
>> import("stdfaust.lib");
>> avg(t, x) = fi.pole(p, (1 - p) * x) // 1-pole lowpass as average
>> with {
>> p = exp-2.0 * ma.PI) / t) / ma.SR));
>> };
>> var(t, x) = avg(t, (x - avg(t, x)) ^ 2); // variance
>> sd(t, x) = sqrt(var(t, x)); // standard deviation
>> cov(t, x1, x2) = avg(t, (x1 - avg(t, x1)) * (x2 - avg(t, x2))); //
>> covariance
>> corr(t, x1, x2) = cov(t, x1, x2) / (sd(t, x1) * sd(t, x2)) : _ ; //
>> correlation
>> t = 0.5; // averaging period in seconds
>> correlate_meter(x,y) = x,y <: x , attach(y, (corr(t) : hbargraph("corr",-
>> 1,1))) : _,_;
>> correlate_correct(t,l,r) = ba.if(1 > corr(t,l,r) > 0 , l, (l+r)) , ba.if(
>> 1 > corr(t,l,r) > 0 , r, (l+r));
>> process = _,_ : correlate_meter : correlate_correct(t);
>>
>> Am I doing the ba.if wrong?
>>
>> Thank s very much,
>> Klaus
>>
>>
>> On 04.08.21 18:25, Dario Sanfilippo wrote:
>>
>> I had implemented a few statistics function a while back, kindly taken
>> from Wikipedia, and they seem to produce the expected values mentioned on
>> the webpage. I hope that these can be useful.
>>
>> Ciao,
>> Dr Dario Sanfilippo
>> http://dariosanfilippo.com
>>
>> import("stdfaust.lib");
>> avg(t, x) = fi.pole(p, (1 - p) * x) // 1-pole lowpass as average
>> with {
>> p = exp-2.0 * ma.PI) / t) / ma.SR));
>> };
>> var(t, x) = avg(t, (x - avg(t, x)) ^ 2); // variance
>> sd(t, x) = sqrt(var(t, x)); // standard deviation
>> cov(t, x1, x2) = avg(t, (x1 - avg(t, x1)) * (x2 - avg(t, x2))); //
>> covariance
>> corr(t, x1, x2) = cov(t, x1, x2) / (sd(t, x1) * sd(t, x2)); // correlation
>> ph0 = os.phasor(2.0 * ma.PI, 200);
>> red = sin(ph0) + .35 * sin(ph0 * 3.0) + .91 * sin(ph0 * 5.0);
>> blue = sin(ph0) + .5 * sin(ph0 * 3.0) - .5 * sin(ph0 * 5.0);
>> red1 = sin(ph0) + sin(ph0 * 3.0);
>> blue1 = sin(ph0) - sin(ph0 * 3.0) / 3.0;
>> t = 1.0; // averaging period in seconds
>> process = (red , blue : corr(t)) , (red1 , blue1 : corr(t));
>>
>>
>>
>> On Wed, 4 Aug 2021 at 16:52, Klaus Scheuermann  wrote:
>>
>>> Thanks Giuseppe,
>>>
>>> I checked it out, but somehow it still does not give me the desired
>>> result...
>>> I did some more research and found this, which indicates that it can be
>>> done with arctan more easily.
>>>
>>> The way this is done on phase (correlation) meters in audio equipment is
>>> rather simple:
>>>
>>> Phase = arctan(L/R)
>>>
>>> With phase of 45 or 225 = 1, and phase of 135 and 315 (-45) is -1.
>>>
>>> Essentially, the Y Axis is the L, and the X axis is the R. The phase is
>>> simply the polar a

Re: [Faudiostream-users] audio correlation meter

[Julius Smith]

Hi Klaus,

I am late to this (just read some of the thread with interest), and I have
a question: what do you mean by "1 > corr(t,l,r) > 0" ?  It appears to be
"parsed" left to right, so that the 2nd ">" only sees "1>0" most (all?) of
the time, which is always true (1) of course (so no "else" activated).
Maybe you want something like "abs(corr(t,l,r)) > 0.95" ?  (i.e., 95%
correlation deemed to be "panned mono").  I'm taking the absolute value
because I assume you don't care if the left channel is merely the negative
of the right (unless that's an accepted cheezy "stereoizer" of sorts).

FYI, this is what we call a time-domain "normalized cross-correlation" or
"correlation coefficient" measurement (official buzzwords)

Cheers,
Julius


On Sun, Aug 8, 2021 at 10:07 AM Klaus Scheuermann  wrote:

> Dear Dario,
>
> cool, your corr function gives me the desired results. At least when
> feeding it to a meter.
>
> Here is my test audio which contains vocals in mono-mid, mono-left,
> mono-right, mono-half-left, mono-half-right, stereo:
> https://cloud.4ohm.de/s/y9oZzqFGyrZT5ej
> For mono-mid, mono-half-left, mono-half-right it shows 1.
> For mono-left, mono-right it shows 0.
> For stereo it shows values between 0 and 1.
>
> I would like to detect mono signals that are not exactly in the middle and
> put them there. Stereo signals should be unchanged.
>
> My code is here, but for some reason it does not work correctly.
> Especially when corr shows 0, ba.if does not go to the else-path.
>
> import("stdfaust.lib");
> avg(t, x) = fi.pole(p, (1 - p) * x) // 1-pole lowpass as average
> with {
> p = exp-2.0 * ma.PI) / t) / ma.SR));
> };
> var(t, x) = avg(t, (x - avg(t, x)) ^ 2); // variance
> sd(t, x) = sqrt(var(t, x)); // standard deviation
> cov(t, x1, x2) = avg(t, (x1 - avg(t, x1)) * (x2 - avg(t, x2))); //
> covariance
> corr(t, x1, x2) = cov(t, x1, x2) / (sd(t, x1) * sd(t, x2)) : _ ; //
> correlation
> t = 0.5; // averaging period in seconds
> correlate_meter(x,y) = x,y <: x , attach(y, (corr(t) : hbargraph("corr",-1
> ,1))) : _,_;
> correlate_correct(t,l,r) = ba.if(1 > corr(t,l,r) > 0 , l, (l+r)) , ba.if(1
> > corr(t,l,r) > 0 , r, (l+r));
> process = _,_ : correlate_meter : correlate_correct(t);
>
> Am I doing the ba.if wrong?
>
> Thank s very much,
> Klaus
>
>
> On 04.08.21 18:25, Dario Sanfilippo wrote:
>
> I had implemented a few statistics function a while back, kindly taken
> from Wikipedia, and they seem to produce the expected values mentioned on
> the webpage. I hope that these can be useful.
>
> Ciao,
> Dr Dario Sanfilippo
> http://dariosanfilippo.com
>
> import("stdfaust.lib");
> avg(t, x) = fi.pole(p, (1 - p) * x) // 1-pole lowpass as average
> with {
> p = exp-2.0 * ma.PI) / t) / ma.SR));
> };
> var(t, x) = avg(t, (x - avg(t, x)) ^ 2); // variance
> sd(t, x) = sqrt(var(t, x)); // standard deviation
> cov(t, x1, x2) = avg(t, (x1 - avg(t, x1)) * (x2 - avg(t, x2))); //
> covariance
> corr(t, x1, x2) = cov(t, x1, x2) / (sd(t, x1) * sd(t, x2)); // correlation
> ph0 = os.phasor(2.0 * ma.PI, 200);
> red = sin(ph0) + .35 * sin(ph0 * 3.0) + .91 * sin(ph0 * 5.0);
> blue = sin(ph0) + .5 * sin(ph0 * 3.0) - .5 * sin(ph0 * 5.0);
> red1 = sin(ph0) + sin(ph0 * 3.0);
> blue1 = sin(ph0) - sin(ph0 * 3.0) / 3.0;
> t = 1.0; // averaging period in seconds
> process = (red , blue : corr(t)) , (red1 , blue1 : corr(t));
>
>
>
> On Wed, 4 Aug 2021 at 16:52, Klaus Scheuermann  wrote:
>
>> Thanks Giuseppe,
>>
>> I checked it out, but somehow it still does not give me the desired
>> result...
>> I did some more research and found this, which indicates that it can be
>> done with arctan more easily.
>>
>> The way this is done on phase (correlation) meters in audio equipment is
>> rather simple:
>>
>> Phase = arctan(L/R)
>>
>> With phase of 45 or 225 = 1, and phase of 135 and 315 (-45) is -1.
>>
>> Essentially, the Y Axis is the L, and the X axis is the R. The phase is
>> simply the polar angle of the vector between the two.
>>
>> This type of meters will show 1 if the signal is mono, and -1 if the left
>> and right are perfectly phase inverted.
>>
>> Notice however, that phase meters of this type also account for the
>> magnitude in the polar coordinates. So:
>>
>> Magnitude = (L^2 + R^2)^1/2
>>
>> Thus the actual meter display is a normalised version of:
>>
>> Correlation = Phase * Magnitude
>>
>> I'm not sure that satisfies your requirements, but this answers the
>> question in the subject.
>>
>> So I transfered this to faust, but it still behaves weired...
>> import("stdfaust.lib");
>> phase(l,r) = (l/r) : aa.arctan;
>> magnitude(l,r) = (l^2 + r^2)^1/2;
>> correlate(l,r) = phase(l,r) * magnitude(l,r);
>> correlate_meter(x,y) = x,y <: x , attach(y, (correlate : hbargraph("corr"
>> ,-1,1))) : _,_;
>> process = _,_ : correlate_meter: _,_;
>>
>> Any ideas?
>>
>> Klaus
>>
>> On 03.08.21 14:48, Giuseppe Silvi wrote:
>>
>> Hi Klaus,
>> The filters are necessary to obtain a -1 +1 range, I think.
>>
>> import("stdfaust.lib");
>>

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 t

Re: [Faudiostream-users] lufs loudness analyser

[Julius Smith]

great help from the list (thanks!) I could implement (momentary) 
>>>>>>> lufs metering in my project:
>>>>>>> https://github.com/trummerschlunk/master_me
>>>>>>>
>>>>>>> also thinking about how to do the -70 dB gate and most important the 
>>>>>>> integrated loudness.
>>>>>>>>
>>>>>>> Did you give this a thought? I am - once again - a bit lost here.
>>>>>>> The specs say: 
>>>>>>> (https://www.itu.int/dms_pubrec/itu-r/rec/bs/R-REC-BS.1770-3-201208-S!!PDF-E.pdf)
>>>>>>>
>>>>>>> gating of 400 ms blocks (overlapping by 75%), where two thresholds are 
>>>>>>> used:
>>>>>>> – the first at –70 LKFS;
>>>>>>> – the  second  at  –10  dB  relative  to  the  level  measured  after  
>>>>>>> application  of  the  first  threshold.
>>>>>>>
>>>>>>> I guess, the gating can be done with a sliding window too, right? Or is 
>>>>>>> it done in the same window we use for measurement?
>>>>>>>
>>>>>>> How do I gate a variable in two stages?
>>>>>>>
>>>>>>> Thanks, Klaus
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On 10.07.21 18:15, Juan Carlos Blancas wrote:
>>>>>>>
>>>>>>>>
>>>>>>>> El 10 jul 2021, a las 15:31, Klaus Scheuermann  
>>>>>>>> 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  

Re: [Faudiostream-users] attach to stereo signal

[Julius Smith]

Hmmm, it looks like the attach is introducing a new instance of x.
Maybe something like this will work:

process(x,y) = x,y <: x, attach(y, (Lk2 : vbargraph("LUFS",-90,0))) : _,_;

On Tue, Jul 13, 2021 at 6:14 AM Klaus Scheuermann  wrote:

> Hi Julius,
>
> but this makes two (or n) meters, right?
>
> I would like to attach the lufs meter (which only has one hbargraph) to
> a stereo signal and leave the stereo signal untouched.
>
> Here is the working code for the stereo lufs meter, but it ends up
> having 3 channels. If I terminate the last channel with (_,_,!) , the
> meter is optimized out too. What I need is a function Lufs_Meter_Stereo
> that does nothing to the stereo sound, but only adds one meter (and
> preferably takes no arguments): _,_ : Lufs_Meter_Stereo : _,_
>
> 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
>
> //envelope via lp by dario
> 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);
>
> // 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_lp : 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);
> // stereo
> Lk2 = Lk(0),Lk(2) :> 10 * log10 : -(0.691);
>
> process(x,y) = x,y <: (_,_), attach(x, (Lk2 : vbargraph("LUFS",-90,0)))
> : _,_,_ ;
>
>
>
>
>
> On 12.07.21 03:08, Julius Smith wrote:
> > Hi Klaus,
> >
> > I sympathize!  Been there!
> >
> > There are various examples in demos.lib.   This seems to be right, but
> > let me know if not:
> >
> > import("stdfaust.lib");
> >
> > level_meter(chan) = abs : max(ma.EPSILON) : 20*log10 :
> > hbargraph("Channel %chan [unit:dB]",-70,10);
> > meter_lk(N) = si.bus(N) <: ro.interleave(N,N) :
> > par(i,N,attach(level_meter(i+1)));
> >
> > // Test:
> > sig(i) = 0.1 * no.noise;
> > process = sig(1),sig(2) : meter_lk(2) : _,_;
> >
> > Where would be a good place for this in the Faust libraries or examples?
> >
> > Cheers,
> > Julius
> >
> >
> > On Sun, Jul 11, 2021 at 10:23 AM Klaus Scheuermann  > <mailto:kla...@posteo.de>> wrote:
> >
> > Guys, I am biting my teeth out here, although it is probably super
> > simple... (making a new thread, as the lufs-loudness-meter is getting
> > quite full...)
> >
> > I have a function Lk2 which has 2 inputs and one output. The output
> does
> > not matter to me, but it contains a vbargraph meter.
> >
> > How do I make a function meter_lk2 that has 2 inputs, 2 outputs and
> no
> > arguments, that attaches Lk2 to it only for metering, passing through
> > the inputs to the outputs?
> >
> > process = _,_ : meter_lk2 : _,_;
> >
> > meter_lk2 = ???
> >
> > (mono is easy, but stereo is killing me.)
> >
> > Thanks,
> > Klaus
> >
> >
> > ___
> > Faudiostream-users mailing list
> > Faudiostream-users@lists.sourceforge.net
> > <mailto:Faudiostream-users@lists.sourceforge.net>
> > https://lists.sourceforge.net/lists/listinfo/faudiostream-users
> > <https://lists.sourceforge.net/lists/listinfo/faudiostream-users>
> >
> >
> >
> > --
> > "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]

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

Re: [Faudiostream-users] attach to stereo signal

[Julius Smith]

I obviously forgot the lowpass after the abs in level_meter(chan)

On Sun, Jul 11, 2021 at 6:08 PM Julius Smith  wrote:

> Hi Klaus,
>
> I sympathize!  Been there!
>
> There are various examples in demos.lib.   This seems to be right, but let
> me know if not:
>
> import("stdfaust.lib");
>
> level_meter(chan) = abs : max(ma.EPSILON) : 20*log10 : hbargraph("Channel
> %chan [unit:dB]",-70,10);
> meter_lk(N) = si.bus(N) <: ro.interleave(N,N) :
> par(i,N,attach(level_meter(i+1)));
>
> // Test:
> sig(i) = 0.1 * no.noise;
> process = sig(1),sig(2) : meter_lk(2) : _,_;
>
> Where would be a good place for this in the Faust libraries or examples?
>
> Cheers,
> Julius
>
>
> On Sun, Jul 11, 2021 at 10:23 AM Klaus Scheuermann 
> wrote:
>
>> Guys, I am biting my teeth out here, although it is probably super
>> simple... (making a new thread, as the lufs-loudness-meter is getting
>> quite full...)
>>
>> I have a function Lk2 which has 2 inputs and one output. The output does
>> not matter to me, but it contains a vbargraph meter.
>>
>> How do I make a function meter_lk2 that has 2 inputs, 2 outputs and no
>> arguments, that attaches Lk2 to it only for metering, passing through
>> the inputs to the outputs?
>>
>> process = _,_ : meter_lk2 : _,_;
>>
>> meter_lk2 = ???
>>
>> (mono is easy, but stereo is killing me.)
>>
>> Thanks,
>> 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
>


-- 
"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] attach to stereo signal

[Julius Smith]

Hi Klaus,

I sympathize!  Been there!

There are various examples in demos.lib.   This seems to be right, but let
me know if not:

import("stdfaust.lib");

level_meter(chan) = abs : max(ma.EPSILON) : 20*log10 : hbargraph("Channel
%chan [unit:dB]",-70,10);
meter_lk(N) = si.bus(N) <: ro.interleave(N,N) :
par(i,N,attach(level_meter(i+1)));

// Test:
sig(i) = 0.1 * no.noise;
process = sig(1),sig(2) : meter_lk(2) : _,_;

Where would be a good place for this in the Faust libraries or examples?

Cheers,
Julius


On Sun, Jul 11, 2021 at 10:23 AM Klaus Scheuermann  wrote:

> Guys, I am biting my teeth out here, although it is probably super
> simple... (making a new thread, as the lufs-loudness-meter is getting
> quite full...)
>
> I have a function Lk2 which has 2 inputs and one output. The output does
> not matter to me, but it contains a vbargraph meter.
>
> How do I make a function meter_lk2 that has 2 inputs, 2 outputs and no
> arguments, that attaches Lk2 to it only for metering, passing through
> the inputs to the outputs?
>
> process = _,_ : meter_lk2 : _,_;
>
> meter_lk2 = ???
>
> (mono is easy, but stereo is killing me.)
>
> Thanks,
> 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]

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

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

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, 

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

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

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

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

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; 

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 

Re: [Faudiostream-users] Virtual analog and filter discretization

[Julius Smith]

Yes, Dirk Roosenburg's new wdmodels.lib in faustlibraries should be tried
and compared as well!
I have no direct experience with it but look forward to checking it out.
All of my WDFs are in direct C++ at this point.

fi.tf4 sounds good to me, but we have fi.iir for the general case, as well
as fi.iir_lat1/lat2/kl/nl.

Interesting that you need double precision.  Not sure what you mean by
"fold the constants".

Glad to hear it's working!

Cheers,
- Julius

On Fri, Jul 9, 2021 at 8:34 AM Jean Pierre Cimalando 
wrote:

> Hi Julius,
>
> Le 08/07/2021 à 20:13, Julius Smith a écrit :
> > It sounds like there is a bug.  The bilinear transform preserves
> > stability
>
> That was indeed a bug. I redid the formulas on a clearer mind, and as it
> turns out, the model is working well now.
>
> The transforms (fi).tf4 and up might make some useful additions for
> filters.lib.
>
> It's also notable that it works only under double precision.
> I wonder if that may be because faust also uses single precision to fold
> the constants, when the -double option is not given.
>
> > Nowadays, I would digitize an analog circuit using Jatin Chowdhury's
> > latest code, e.g.,
>
> WDF has all my attention, no doubt it will get consideration in future
> projects, which are more elaborate that chains of filters.
> Kudos to Dirk Roosenburg also for suberb work.
>
> Best -JPC
>


-- 
"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] Virtual analog and filter discretization

[Julius Smith]

Greetings,

It sounds like there is a bug.  The bilinear transform preserves stability,
but it can get into trouble with "delay-free loops" when there is feedback
around what is transformed.

Nowadays, I would digitize an analog circuit using Jatin Chowdhury's latest
code, e.g.,

https://github.com/jatinchowdhury18/KlonCentaur.git
https://github.com/jatinchowdhury18/wdf-bakeoff

(It's still using bilinear transforms, but element by element, for the most
part, resolving delay-free loops using Wave Digital Filter ideas)

On Thu, Jul 8, 2021 at 6:13 AM Jean Pierre Cimalando via Faudiostream-users
 wrote:

> Hello,
>
> recently I implemented and published a music plugin with faust [1],
> which implements the digital model of a bass tone circuit.
>
> A problem encountered during this process is the discretization of the
> EQ section, located on the bottom part of the schematic [2], running
> from C25 to C20 not included.
>
> This circuit describes as a low-frequency peak filter (+ or - gain),
> combined with a high-frequency shelf, parameterized by a pair of coupled
> knobs labelled as bass and treble.
>
> I have produced a program for computing the expression for the analog
> transfer function [3], and applying the bilinear transform.
> While the analog transfer function matches the SPICE results, I observed
> the digital filter does not meet the criterion for stability (that is,
> poles inside the unit circle).
>
> There is faust source code [4], the unstable EQ is replaced with an
> adhoc substitute having a relatively matching transfer function.
>
> Any hints on producing a more valid discretization of this system?
> Thank you very much
>
> [1] https://github.com/jpcima/Bass21
> [2] https://blog-imgs-91-origin.fc2.com/d/r/u/drugscore/02_49_4SABDsch.png
> [3] https://git.io/JcQi5
> [4] https://git.io/JcQPy
>
>
> ___
> 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 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.

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 > > > <mailto:kla...@posteo.de>> wrote:
>> > >
>> > > Cheers Julius,
>> > >
>> > >
>> > >
>> > > At least I understood the 'attach' primitive now ;) Thanks.
>> > >
>> > >
>> > >
>> > >     This does not show any meter here...
>> > > process(x,y) = x,y <: (_,_), attach(x, (Lk2 :
>> vbargraph("LUFS",-90,0)))
>> > > : _,_,!;
>> > >
>> > > But this does for some reason (although the output is 3-channel
>> then):
>> > > process(x,y) = x,y <: (_,_), attach(x, (Lk2 :
>> vbargraph("LUFS",-90,0)))
>> > > : _,_,_;
>> > >
>> &

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  > >> <mailto:kla...@posteo.de>> wrote:
> > >>
> > >>Cheers Julius,
> > >>
> > >>
> > >>
> > >>At least I understood the 'attach' primitive now ;) Thanks.
> > >>
> > >>
> > >>
> > >>This does not show any meter here...
> > >>process(x,y) = x,y <: (_,_), attach(x, (Lk2 :
> vbargraph("LUFS",-90,0)))
> > >>: _,_,!;
> > >>
> > >>But this does for some reason (although the output is 3-channel
> then):
> > >>process(x,y) = x,y <: (_,_), attach(x, (Lk2 :
> vbargraph("LUFS",-90,0)))
> > >>: _,_,_;
> > >>
> > >>What does the '!' do?
> > >>
> > >>
> > >>
> > >>I still don't quite get the gating topic. In my understanding, the
> meter
> > >>should hold the current value if the input signal drops below a
> > >>threshold. In your version, the meter drops to -infinity when very
> low
> > >>volume content is played.
> > >>
> > >>Which pa

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  >> <mailto:kla...@posteo.de>> wrote:
> >>
> >>Cheers Julius,
> >>
> >>
> >>
> >>At least I understood the 'attach' primitive now ;) Thanks.
> >>
> >>
> >>
> >>This does not show any meter here...
> >>process(x,y) = x,y <: (_,_), attach(x, (Lk2 :
> vbargraph("LUFS",-90,0)))
> >>: _,_,!;
> >>
> >>But this does for some reason (although the output is 3-channel
> then):
> >>process(x,y) = x,y <: (_,_), attach(x, (Lk2 :
> vbargraph("LUFS",-90,0)))
> >>: _,_,_;
> >>
> >>What does the '!' do?
> >>
> >>
> >>
> >>I still don't quite get the gating topic. In my understanding, the
> meter
> >>should hold the current value if the input signal drops below a
> >>threshold. In your version, the meter drops to -infinity when very
> low
> >>volume content is played.
> >>
> >>Which part of your code does the gating?
> >>
> >>Many thanks,
> >>Klaus
> >>
> >>
> >>
> >>On 05.07.21 18:06, Julius Smith wrote:
> >>> Hi Klaus,
> >>>
> >>> Yes, I agree the filters are close enough.  I bet that the shelf is
> >>> exactly correct if we determined the exact transition frequency, and
> >>> that the Butterworth highpass is close enough to the
> >>Bessel-or-whatever
> >>> that is inexplicably not specified as a filter type, leaving it
> >>> sample-rate dependent.  I would bet large odds that the differences
> >>> cannot be reliably detected in listening tests.
> >>>
> >>> Yes, I just looked again, and there are "

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 > > <mailto:kla...@posteo.de>> wrote:
>> >
>> > Cheers Julius,
>> >
>> >
>> >
>> > At least I understood the 'attach' primitive now ;) Thanks.
>> >
>> >
>> >
>> > This does not show any meter here...
>> > process(x,y) = x,y <: (_,_), attach(x, (Lk2 :
>> vbargraph("LUFS",-90,0)))
>> > : _,_,!;
>> >
>> > But this does for some reason (although the output is 3-channel
>> then):
>> > process(x,y) = x,y <: (_,_), attach(x, (Lk2 :
>> vbargraph("LUFS",-90,0)))
>> > : _,_,_;
>> >
>> > What does the '!' do?
>> >
>> >
>> >
>> > I still don't quite get the gating topic. In my understanding, the
>> meter
>> > should hold the current value if the input signal drops below a
>> > threshold. In your version, the meter drops to -infinity when very
>> low
>> > volume content is played.
>> >
>> > Which part of your code does the gating?
>> >
>> > Many thanks,
>> > Klaus
>> >
>> >
>> >
>> > On 05.07.21 18:06, Julius Smith wrote:
>> > > Hi Klaus,
>> > >
>> > > Yes, I agree the filters are close enough.  I bet that the shelf
>> is
>> > > exactly correct if we determined the exact transition frequency,
>> and
>> > > that the Butterworth highpass is close enough to the
>> > Bessel-or-whatever
>> > > that is inexplicably not specified as a filter type, leaving it
>> > > sample-rate dependent.  I would bet large odds that the
>> differences
>> > > cannot be reliably detected in listening tests.
>> > >
>> > > Yes, I just looked again, and there are "gating blocks" defined,
>> > each Tg
>> > > = 0.4 sec long, so that only ungated blocks are averaged to form a
>> > > longer term level-estimate.  What I wrote gives a "sliding gating
>> > > block", which can be lowpass filtered further, and/or gated, etc.
>>
>> > > Instead of a gate, I would simply replace 0 by ma.EPSILON so that
>> the
>> > > log always works (good for avoiding denormals as well).
>> > >
>> > > I believe stereo is supposed to be handled like this:
>> > >
>> > > Lk2 = _,0,_,0,0 : L

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  > <mailto:kla...@posteo.de>> wrote:
> >
> > Cheers Julius,
> >
> >
> >
> > At least I understood the 'attach' primitive now ;) Thanks.
> >
> >
> >
> > This does not show any meter here...
> > process(x,y) = x,y <: (_,_), attach(x, (Lk2 :
> vbargraph("LUFS",-90,0)))
> > : _,_,!;
> >
> > But this does for some reason (although the output is 3-channel
> then):
> > process(x,y) = x,y <: (_,_), attach(x, (Lk2 :
> vbargraph("LUFS",-90,0)))
> > : _,_,_;
> >
> > What does the '!' do?
> >
> >
> >
> > I still don't quite get the gating topic. In my understanding, the
> meter
> > should hold the current value if the input signal drops below a
> > threshold. In your version, the meter drops to -infinity when very
> low
> > volume content is played.
> >
> > Which part of your code does the gating?
> >
> > Many thanks,
> > Klaus
> >
> >
> >
> > On 05.07.21 18:06, Julius Smith wrote:
> > > Hi Klaus,
> > >
> > > Yes, I agree the filters are close enough.  I bet that the shelf is
> > > exactly correct if we determined the exact transition frequency,
> and
> > > that the Butterworth highpass is close enough to the
> > Bessel-or-whatever
> > > that is inexplicably not specified as a filter type, leaving it
> > > sample-rate dependent.  I would bet large odds that the differences
> > > cannot be reliably detected in listening tests.
> > >
> > > Yes, I just looked again, and there are "gating blocks" defined,
> > each Tg
> > > = 0.4 sec long, so that only ungated blocks are averaged to form a
> > > longer term level-estimate.  What I wrote gives a "sliding gating
> > > block", which can be lowpass filtered further, and/or gated, etc.
> > > Instead of a gate, I would simply replace 0 by ma.EPSILON so that
> the
> > > log always works (good for avoiding denormals as well).
> > >
> > > I believe stereo is supposed to be handled like this:
> > >
> > > Lk2 = _,0,_,0,0 : Lk5;
> > > process(x,y) = Lk2(x,y);
> > >
> > > or
> > >
> > > Lk2 = Lk(0),Lk(2) :> 10 * log10 : -(0.691);
> > >
> > > but since the center channel is processed identically to left
> > and right,
> > > your solution also works.
> > >
> > > Bypassing is normal Faust, e.g.,
> > >
> > > process(x,y) = x,y <: (_,_), attach(x, (Lk2 :
> > vbargraph("LUFS",-90,0)))
> > > : _,_,!;
> > >
> > > Cheers,
> > > Julius
> > >
> > >
> > > On Mon, Jul 5, 2021 at 1:56 AM Klaus Scheu

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  > <mailto:kla...@posteo.de>> wrote:
> >
> >
> > > I can never resist these things!   Faust makes it too enjoyable :-)
> >
> > Glad you can't ;)
> >
> > I understood you approximate the filters with standard faust filters.
> > That is probably close enough for me :)
> >
> > I also get the part with the sliding window envelope. If I wanted to
> > make the meter follow slowlier, I would just widen the window with
> Tg.
> >
> > The 'gating' part I don't understand for lack of mathematical
> knowledge,
> > but I suppose it is meant differently. When the input signal falls
> below
> > the gate threshold, the meter should stay at the current value, not
> drop
> > to -infinity, right? This is so 'silent' parts are not taken into
> > account.
> >
> > If I wanted to make a stereo version it would be something like
> > this, right?
> >
> > Lk2 = par(i,2, Lk(i)) :> 10 * log10 : -(0.691);
> > process = _,_ : Lk2 : vbargraph("LUFS",-90,0);
> >
> > Probably very easy, but how do I attach this to a stereo signal
> (passing
> > through the stereo signal)?
> >
> > Thanks again!
> > Klaus
> >
> >
> >
> > >
> > > I made a pass, but there is a small scaling error.  I think it can
> be
> > > fixed by reducing boostFreqHz until the sine_test is nailed.
> > > The highpass is close (and not a source of the scale error), but
> I'm
> > > using Butterworth instead of whatever they used.
> > > I glossed over the discussion of "gating" in the spec, and may have
> > > missed something important 

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

[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

Re: [Faudiostream-users] Which all-pass block to use for spring reverb "chirps"?

[Julius Smith]

Ah, they DO have an entry in demos.lib, great!
(My failed search was for "Parker")

On Thu, Jun 10, 2021 at 4:20 AM Julius Smith  wrote:

> > BTW : Julian Parker reverbs have been recently added in reverbs.lib
>
> Cool!  I look forward to hearing the JPverb and Greyhole Reverbs.
>
> It would be great if contributions on this level got an entry in demos.lib
>
> - Julius
>
> On Thu, Jun 10, 2021 at 2:00 AM Stéphane Letz  wrote:
>
>> BTW : Julian Parker reverbs have been recently added in reverbs.lib
>>
>> https://github.com/grame-cncm/faustlibraries/blob/master/reverbs.lib#L541
>>
>> https://github.com/grame-cncm/faustlibraries/blob/master/reverbs.lib#L573
>>
>> https://github.com/grame-cncm/faustlibraries/blob/master/reverbs.lib#L597
>>
>> Stéphane
>>
>> > Le 9 juin 2021 à 18:14, Gary Worsham  a écrit :
>> >
>> > Thanks Julius!
>> >
>> > I also found a Faust definition of a stretched all pass in this reverb
>> published by Julian Parker in 2013.  What's funny is that the stretched
>> allpass is defined but not used.  I'll be giving it a whirl before too long.
>> >
>> >
>> https://github.com/supercollider/sc3-plugins/blob/main/source/DEINDUGens/faust_src/JPverbRaw.dsp
>> >
>> > By the way I made a VST and Windows standalone app from Julian's code:
>> >
>> > https://github.com/HolyCityAudio/Plugins/tree/main/ParkerReverb
>> >
>> > Thanks,
>> >
>> > GW
>> >
>> > On Wed, Jun 9, 2021 at 5:12 AM Julius Smith 
>> wrote:
>> > > I think that most likely, Faust does not include a library function
>> which is a "stretched" allpass and a fixed delay line with an interpolating
>> allpass on the end doesn't quite give the same thing... does it?
>> >
>> > I think it does if you use an allpass-interpolating delay line, e.g.,
>> >
>> > allpass_comb_stretched(maxN,N,aN,strf) = (+ <:
>> de.fdelay1a(maxN,N-1+strf),*(aN)) ~ *(-aN) : mem,_ : +;
>> >
>> > (compare to allpass_comb in filters.lib)
>> >
>> > Cheers,
>> > Julius
>> >
>> > On Thu, Jun 3, 2021 at 11:29 PM Julius Smith 
>> wrote:
>> > Hi Gary,
>> >
>> > I had to google "stretched allpass filters" and found this:
>> >
>> >
>> https://dsp.stackexchange.com/questions/46221/real-time-implementation-of-cascaded-all-pass-filters-from-given-transfer-functi
>> >
>> > They appear to be a special case of what I normally would call "nested
>> allpass filters".  In any case, Faust can certainly do this as well, and
>> it's a great opportunity for a recursive definition using pattern
>> matching.  Take a look at allpassnt() in filters.lib for an example.  (The
>> two-multiply lattice filter is a nested allpass.)
>> >
>> > Due to negative free time, I will keep a star on this in gmail and
>> circle back when I can, as I am definitely interested in this project.
>> Quick urgent questions always welcome, however.
>> >
>> > Cheers,
>> > Julius
>> >
>> >
>> > On Tue, Jun 1, 2021 at 7:22 AM Gary Worsham 
>> wrote:
>> > Hi Julius,
>> >
>> > I made a brave attempt to read these articles.  I only ever got as far
>> as EE263 and that was more than 40 years ago!  Anyway, a few questions
>> regarding direct form biquad allpasses vs. "stretched" allpass blocks as
>> proposed by Julian Parker.
>> >
>> > I think that most likely, Faust does not include a library function
>> which is a "stretched" allpass and a fixed delay line with an interpolating
>> allpass on the end doesn't quite give the same thing... does it?
>> > I could probably take the Faust library definition of an interpolating
>> allpass and add the stretching internally.
>> > Only the stretched allpass blocks give that "imaging" effect where the
>> phase delay maximum is repeated up the spectrum, resulting in the need to
>> low pass filter to just keep the lowest one.   However, now that I think of
>> it with another cup of coffee, even a single all-pass is going to have that
>> phase delay peak, meaning that above that transition frequency, the chirp
>> would go from high to low, while below it, it would go low to high.  So you
>> still want to low pass filter the result so you only get the upward going
>> part of the chirp.
>> > Looks like calculating the coefficients for these filters requires
>> Matlab and Newton's 

Re: [Faudiostream-users] Which all-pass block to use for spring reverb "chirps"?

[Julius Smith]

> BTW : Julian Parker reverbs have been recently added in reverbs.lib

Cool!  I look forward to hearing the JPverb and Greyhole Reverbs.

It would be great if contributions on this level got an entry in demos.lib

- Julius

On Thu, Jun 10, 2021 at 2:00 AM Stéphane Letz  wrote:

> BTW : Julian Parker reverbs have been recently added in reverbs.lib
>
> https://github.com/grame-cncm/faustlibraries/blob/master/reverbs.lib#L541
>
> https://github.com/grame-cncm/faustlibraries/blob/master/reverbs.lib#L573
>
> https://github.com/grame-cncm/faustlibraries/blob/master/reverbs.lib#L597
>
> Stéphane
>
> > Le 9 juin 2021 à 18:14, Gary Worsham  a écrit :
> >
> > Thanks Julius!
> >
> > I also found a Faust definition of a stretched all pass in this reverb
> published by Julian Parker in 2013.  What's funny is that the stretched
> allpass is defined but not used.  I'll be giving it a whirl before too long.
> >
> >
> https://github.com/supercollider/sc3-plugins/blob/main/source/DEINDUGens/faust_src/JPverbRaw.dsp
> >
> > By the way I made a VST and Windows standalone app from Julian's code:
> >
> > https://github.com/HolyCityAudio/Plugins/tree/main/ParkerReverb
> >
> > Thanks,
> >
> > GW
> >
> > On Wed, Jun 9, 2021 at 5:12 AM Julius Smith 
> wrote:
> > > I think that most likely, Faust does not include a library function
> which is a "stretched" allpass and a fixed delay line with an interpolating
> allpass on the end doesn't quite give the same thing... does it?
> >
> > I think it does if you use an allpass-interpolating delay line, e.g.,
> >
> > allpass_comb_stretched(maxN,N,aN,strf) = (+ <:
> de.fdelay1a(maxN,N-1+strf),*(aN)) ~ *(-aN) : mem,_ : +;
> >
> > (compare to allpass_comb in filters.lib)
> >
> > Cheers,
> > Julius
> >
> > On Thu, Jun 3, 2021 at 11:29 PM Julius Smith 
> wrote:
> > Hi Gary,
> >
> > I had to google "stretched allpass filters" and found this:
> >
> >
> https://dsp.stackexchange.com/questions/46221/real-time-implementation-of-cascaded-all-pass-filters-from-given-transfer-functi
> >
> > They appear to be a special case of what I normally would call "nested
> allpass filters".  In any case, Faust can certainly do this as well, and
> it's a great opportunity for a recursive definition using pattern
> matching.  Take a look at allpassnt() in filters.lib for an example.  (The
> two-multiply lattice filter is a nested allpass.)
> >
> > Due to negative free time, I will keep a star on this in gmail and
> circle back when I can, as I am definitely interested in this project.
> Quick urgent questions always welcome, however.
> >
> > Cheers,
> > Julius
> >
> >
> > On Tue, Jun 1, 2021 at 7:22 AM Gary Worsham 
> wrote:
> > Hi Julius,
> >
> > I made a brave attempt to read these articles.  I only ever got as far
> as EE263 and that was more than 40 years ago!  Anyway, a few questions
> regarding direct form biquad allpasses vs. "stretched" allpass blocks as
> proposed by Julian Parker.
> >
> > I think that most likely, Faust does not include a library function
> which is a "stretched" allpass and a fixed delay line with an interpolating
> allpass on the end doesn't quite give the same thing... does it?
> > I could probably take the Faust library definition of an interpolating
> allpass and add the stretching internally.
> > Only the stretched allpass blocks give that "imaging" effect where the
> phase delay maximum is repeated up the spectrum, resulting in the need to
> low pass filter to just keep the lowest one.   However, now that I think of
> it with another cup of coffee, even a single all-pass is going to have that
> phase delay peak, meaning that above that transition frequency, the chirp
> would go from high to low, while below it, it would go low to high.  So you
> still want to low pass filter the result so you only get the upward going
> part of the chirp.
> > Looks like calculating the coefficients for these filters requires
> Matlab and Newton's method?  eeek!  That doesn't sound like something that
> would be too easy to modulate in real time.
> >
> > Let me give a little more background on my actual goal here.  A few
> years ago I got pretty good at the Spin FV-1 and tried to drum up some
> consulting business among guitar amp manufacturers.  One of the amp
> builders I talked to said "hey can you do that "Vinnie Bell" sound as
> evidenced on the Ferrante and Teicher version of "Midnight Cowboy" and
> "Airport Love Theme""?  If nothing e

Re: [Faudiostream-users] Which all-pass block to use for spring reverb "chirps"?

[Julius Smith]

I'm actually not yet familiar enough with it to say.  If it has a strong
use case, and we know the best reference to include in the comments, then I
am in favor of adding it to filters.lib right after allpass_fcomb
(Schroeder allpass with delay interpolation).

Cheers,
Julius

On Thu, Jun 10, 2021 at 1:57 AM Stéphane Letz  wrote:

> Should we add allpass_comb_stretched somewhere in the librairies ? What
> you think Julius ?
>
> Stéphane
>
> > Le 9 juin 2021 à 18:14, Gary Worsham  a écrit :
> >
> > Thanks Julius!
> >
> > I also found a Faust definition of a stretched all pass in this reverb
> published by Julian Parker in 2013.  What's funny is that the stretched
> allpass is defined but not used.  I'll be giving it a whirl before too long.
> >
> >
> https://github.com/supercollider/sc3-plugins/blob/main/source/DEINDUGens/faust_src/JPverbRaw.dsp
> >
> > By the way I made a VST and Windows standalone app from Julian's code:
> >
> > https://github.com/HolyCityAudio/Plugins/tree/main/ParkerReverb
> >
> > Thanks,
> >
> > GW
> >
> > On Wed, Jun 9, 2021 at 5:12 AM Julius Smith 
> wrote:
> > > I think that most likely, Faust does not include a library function
> which is a "stretched" allpass and a fixed delay line with an interpolating
> allpass on the end doesn't quite give the same thing... does it?
> >
> > I think it does if you use an allpass-interpolating delay line, e.g.,
> >
> > allpass_comb_stretched(maxN,N,aN,strf) = (+ <:
> de.fdelay1a(maxN,N-1+strf),*(aN)) ~ *(-aN) : mem,_ : +;
> >
> > (compare to allpass_comb in filters.lib)
> >
> > Cheers,
> > Julius
> >
> > On Thu, Jun 3, 2021 at 11:29 PM Julius Smith 
> wrote:
> > Hi Gary,
> >
> > I had to google "stretched allpass filters" and found this:
> >
> >
> https://dsp.stackexchange.com/questions/46221/real-time-implementation-of-cascaded-all-pass-filters-from-given-transfer-functi
> >
> > They appear to be a special case of what I normally would call "nested
> allpass filters".  In any case, Faust can certainly do this as well, and
> it's a great opportunity for a recursive definition using pattern
> matching.  Take a look at allpassnt() in filters.lib for an example.  (The
> two-multiply lattice filter is a nested allpass.)
> >
> > Due to negative free time, I will keep a star on this in gmail and
> circle back when I can, as I am definitely interested in this project.
> Quick urgent questions always welcome, however.
> >
> > Cheers,
> > Julius
> >
> >
> > On Tue, Jun 1, 2021 at 7:22 AM Gary Worsham 
> wrote:
> > Hi Julius,
> >
> > I made a brave attempt to read these articles.  I only ever got as far
> as EE263 and that was more than 40 years ago!  Anyway, a few questions
> regarding direct form biquad allpasses vs. "stretched" allpass blocks as
> proposed by Julian Parker.
> >
> > I think that most likely, Faust does not include a library function
> which is a "stretched" allpass and a fixed delay line with an interpolating
> allpass on the end doesn't quite give the same thing... does it?
> > I could probably take the Faust library definition of an interpolating
> allpass and add the stretching internally.
> > Only the stretched allpass blocks give that "imaging" effect where the
> phase delay maximum is repeated up the spectrum, resulting in the need to
> low pass filter to just keep the lowest one.   However, now that I think of
> it with another cup of coffee, even a single all-pass is going to have that
> phase delay peak, meaning that above that transition frequency, the chirp
> would go from high to low, while below it, it would go low to high.  So you
> still want to low pass filter the result so you only get the upward going
> part of the chirp.
> > Looks like calculating the coefficients for these filters requires
> Matlab and Newton's method?  eeek!  That doesn't sound like something that
> would be too easy to modulate in real time.
> >
> > Let me give a little more background on my actual goal here.  A few
> years ago I got pretty good at the Spin FV-1 and tried to drum up some
> consulting business among guitar amp manufacturers.  One of the amp
> builders I talked to said "hey can you do that "Vinnie Bell" sound as
> evidenced on the Ferrante and Teicher version of "Midnight Cowboy" and
> "Airport Love Theme""?  If nothing else, this stuff really has to take you
> back!
> >
> > https://www.youtube.com/watch?v=payWL0Y8Dd4
> > https://www.youtube.com/watch?v=OsTne8nT8BI
>

Re: [Faudiostream-users] inspect the value of a variable

[Julius Smith]

Hi Julián,

I would (and did) use faust2octave for that.

Cheers,
Julius


On Mon, May 31, 2021 at 7:13 PM Julián Villegas  wrote:

> Hi,
>
> How can I inspect the value of a variable in Faust? I’m trying to build a
> spectral tilt filter in Matlab (for learning purposes), following the Faust
> implementation. The results are wrong in Matlab, and I would like to
> compare my variables in Matlab with those in Faust.
>
> This is what I have so far in Faust:
>
> import("filters.lib");
> import("noises.lib");
>
>alpha = hslider("[1] Slope of Spectral Tilt across
> Band",-1/2,-1,1,0.001);
>f0 = hslider("[2] Band Start Frequency [unit:Hz]",100,20,1,1);
>bw = hslider("[3] Band Width [unit:Hz]",5000,100,1,1);
>
> process(x) =  no.noise  : spectral_tilt(2,f0,bw,alpha) : _;
>
> and this what I have in Matlab:
>
> function tilt()
>
> sr = 48000;
> N = 10; % Number of poles
> alpha = -0.5;
> f0 = 100;
> f1 = 18000;
>
> noise = rand(sr,1);
>
> w0 = 2 * pi * f0;
> r =  (f1/f0)^(1.0/(N-1));
>
> mp = w0*r .^ (0:N-1);
> mz = w0*r .^(-alpha + (0:N-1));
>
>
> % prewarping for bilinear transform
> mph = prewarp(mp,sr,w0);
> mzh = prewarp(mz,sr,w0);
>
> for i=1:N
>g = mph(i)/mzh(i); % a0/b0
>[b1, b0, a1] = tf1s(1,mzh(i),mph(i),1,sr);
>noise = g*filter([b0, b1],[1, -a1], noise,sr);
>   % soundsc(noise,sr);
> end
> plot(noise)
> soundsc(filter(Ba,[1 Aa],rand(sr,1)), sr)
>
> end
>
> function warped = prewarp(w,sr,wp)
> T = 1/sr;
> warped = wp * tan(w*T/2)/tan(wp*T/2);
> end
>
> function [b1d, b0d, a1d] = tf1s(b1,b0,a0,w1,sr)
> c   = 1/tan(w1*0.5/sr); % bilinear-transform scale-factor
> d   = a0 + c;
> b1d = (b0 - b1*c) / d;
> b0d = (b0 + b1*c) / d;
> a1d = (a0 - c) / d;
> end
>
> I’d like to compare the Matlab results in mzh, and mph, with those of
> Faust (e.g., a0,b0, etc.), but I can’t figure out how.
>
> I’m sorry if this is obvious, I’m new to Faust.
>
> Thanks,
>
> Julian Villegas, Ph.D.
>
>
> PS: The Matlab code is based on that provided in "Closed Form Fractional
> Integration and Differentiation via Real Exponentially Spaced Pole-Zero
> Pairs” by
> Julius Orion Smith and Harrison Freeman Smith.
>
> ___
> 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] multimode and svf filters

[Julius Smith]

Let us know which structure wins!

Also, in my previous email, I meant to say "At 15278 / 48kHz, instability
is expected", just to ward off that potential confusion.  Emailing too fast
again . . .
To see it clearly, note that  |p| > 1 for fc above 15278 Hz (when
SR=48Khz).  The approximation I used is based on a linearization of the
bilinear transform around z = 1.

- Julius

On Sat, May 29, 2021 at 10:32 AM Oleg Nesterov  wrote:

> On 05/28, Till Bovermann wrote:
> >
> > I was thinking to use the fi.svf.lp filter as a building block instead
> > but it is (AFAICS, it is not mentioned in the doc string...) not a 1st
> > order design (which is crucial here, partly for consistency with the to
> > be emulated analog circuitry, partly because the phase shift should be
> > consistent to be able to deal with the resonance feedback).
>
> Yes, fi.svf is 2nd order. You can this 1nd order filter:
>
> lp(fc) = tick ~ _ : !,_ with {
> g = tan(fc * ma.PI/ma.SR);
> tick(ic1eq, v0) = 2*v1 - ic1eq, v1
> with { v1 = (g * v0 + ic1eq) / (1 + g); };
> };
>
> it has the same impulse response as fi.lowpass(1, fc) when fc is constant,
> but probably differs when fc is modulated.
>
> Oleg.
>
>
>
> ___
> 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] multimode and svf filters

[Julius Smith]

Hi Till,

Sorry to introduce confusion here.   The "p = 1-w1(freq)/pl.SR" formula is
only reasonable at low frequencies.  At 48kHz, instability is expected.  I
was only doing a low-frequency test.

Also, both filter1 and filter2 in my code example are normalized ladders.
I did initially have a comparison to direct form, as the erroneous first
comment indicates (which threw me off when I sent the email in haste due to
a timeout), but looking at it now, the purpose of the filter1 and filter2
comparison is to check that fi.iir_nl (which can design normalized ladders
of any order, including order 1) matches fi.tf2snp (which can only do order
2).  The comparison was inconvenienced by the fact that tf2snp maps
frequencies through the bilinear transform while iir_nl does not, hence the
direct pole calculation for filter2.

I agree that the right path is to use tf2snp specialized to first-order
(filter1).  (I have now added tf1snp (and tf1s) to filters.lib doing this,
and they are finished if the C++ optimization does the right thing.)

Sorry for emailing in a rush!  The alternative was most likely no email at
all until two weeks from now :-)

- Julius

On Sat, May 29, 2021 at 6:38 AM Till Bovermann  wrote:
>
> Dear Julius,
>
>
> thank you for your input!
>
> My filter theory background is nearly non-existent (for now!) so I try to
catch up as best I can, this is very helpful indeed!
>
> My aim here is more to build something that is musically similar and
approximates the analog design relatively close while maintaining numerical
stability when quickly changing parameters and input.
> Based on your comments, I would have thought that the normalized-ladder
form of the filter would be a better choice for this purpose, however I
found that it blows up with a corner frequency >= 15278 (at a constant SR
of 48k).
>
> Next step will be to adapt my multimode filter design to incorporate your
`lp1` filters and test their behaviour...
>
> Below my partial rework of your sketch (mainly renaming of variables to
make them more explicit for me to understand), possibly helpful for others
on this list, too :)
>
> all the best
> Till
>
> ```
> //
> import("stdfaust.lib");
>
> // Frequency-scaling parameter for real-time bilinear form = corner
frequency:
>
> // direct form 1st order implemented with filling
> // appropriate params into 2nd order direct form and setting a0 = 0.
> // JOS: does not optimise properly on faust-level (possibly C compiler
does?)
> // JOS: needs oversampling for numerical stability
> lp1_direct(freq) = fi.tf2snp( b2, b1, b0, a1, a0, w1(freq) ) with {
> // freq argument: corner frequency (-3dB drop-off)
> w1(fc) = 2 * ma.PI * max( fc, 20 );
>
> g = 1.0;   // dc gain
>
> // Analog zero at infinity:
> b2 = 0;  b1 = g;  b0 = 0;
>
> // Analog poles in normalized form (a2=1 implicitly):
> a1 = 1.0;
> a0 = 0; // Optimization should remove anything associated with this
>
> };
>
> // normalized-ladder
> // JOS: digital counterpart for musical use at normal audio sampling rates
> // blows (@ SR = 48000) for freq >= 15278
> lp1_ladder(freq) = 0.5*(1-p) * fi.iir_nl(bvd,avd) with {
> // freq argument: corner frequency (-3dB drop-off)
> w1(fc) = 2 * ma.PI * max( fc, 20 );
>
> bvd = (1,1);
> avd = -p;
> p = 1-w1(freq)/pl.SR;
> };
>
> process = os.square(freq) <: lp1_direct(ffreq), lp1_ladder(ffreq) with {
> ffreq = hslider("ffreq", 20, 20, 2, 0.001);
> freq = hslider("freq", 20, 20, 1, 0.001);
> };
> ```
>
>
>
> --
> Till Bovermann
>
> https://tai-studio.org | http://lfsaw.de |
https://www.instagram.com/_lfsaw/
>
>
>
>
>
>
>
>
>
>
>
> > On 29. May 2021, at 01:43, Julius Smith  wrote:
> >
> > Hi Till,
> >
> > Thanks for the cool app note - very interesting!
> >
> > I am not familiar with fi.svf.lp, but I've done similar things.
> >
> > If you just want to emulate the analog for testing purposes, I would
use direct form first-order filters and oversample like crazy.
> >
> > If you want to deploy a digital counterpart for musical use at normal
audio sampling rates, I would use the normalized ladder form in place of
direct form (see code below).
> >
> > You could also make a wave digital filter version (now that we have
wdmodels.lib thanks to Dirk).
> >
> > These "multimode filters" look like normal state variable filters to me
(following early analog filters used for solving differential equations in
a state-space format, according to my experience - I first encountered one
in 1972 or so at Rice University).
> >
> > I 

Re: [Faudiostream-users] Which all-pass block to use for spring reverb "chirps"?

[Julius Smith]

HI GW,

I would use this method (simple fi.tf2() biquad allpasses in series):

https://www.researchgate.net/publication/224106863_Robust_Efficient_Design_of_Allpass_Filters_for_Dispersive_String_Sound_Synthesis

@ARTICLE{AbelAndSmithDAFX06,
AUTHOR = "Jonathan Abel and Julius O. " # Smith3,
TITLE = "Robust Design of Very High-Order Allpass Dispersion
Filters",
JOURNAL = dafx06,
MONTH = sep,
YEAR = 2006
}

Cheers,
- Julius


On Fri, May 28, 2021 at 1:00 PM Gary Worsham  wrote:

> Sorry if this is a repeat but I've just signed up for the mailing list
> again, and previous submissions said "you're not registered"... maybe I'm
> in some sort of limbo at the moment.
> =
> I'm interested in messing with some structures suggested by Julian
> Parker's work on spring reverb emulation.
> https://acris.aalto.fi/ws/portalfiles/portal/13004391/art_10.1155_2011_646134.pdf
>
> This paper suggests an "interpolating all-pass delay".  Initially, I don't
> think I would care about modulating these in real time, but of course,
> everything is better with envelope modulation so I'd probably try that
> eventually.
>
> The library includes a handful of all passes and of course I can try all
> of them, but wondering if a particular one would be particularly swell for
> this kind of thing.
>
>
> https://faustcloud.grame.fr/doc/libraries/index.html#thiran-allpass-interpolation
>
> https://faustcloud.grame.fr/doc/libraries/index.html#fi.allpass_comb
>
> https://faustcloud.grame.fr/doc/libraries/index.html#fi.allpass_fcomb
>
>
> https://faustcloud.grame.fr/doc/libraries/index.html#fi.allpass_fcomb5-and-fi.allpass_fcomb1a
>
> Note that I did some experiments in the past with this sort of thing on a
> Spin FV-1 and found that chirp block lengths in the 12 to 20 samples range
> (at 32768 Hz fs) seemed to work well for this sort of thing.  However, the
> FV-1 doesn't have enough instructions to generate a very long chirp.  I am
> really looking to emphasize the dispersion "chirp" in this particular
> exercise.
>
> Thanks!
>
> GW
>
>
> 
>  Virus-free.
> www.avast.com
> 
> <#m_3768652731459431734_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
> ___
> 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] multimode and svf filters

[Julius Smith]

Hi Till,

Thanks for the cool app note - very interesting!

I am not familiar with fi.svf.lp, but I've done similar things.

If you just want to emulate the analog for testing purposes, I would use
direct form first-order filters and oversample like crazy.

If you want to deploy a digital counterpart for musical use at normal audio
sampling rates, I would use the normalized ladder form in place of direct
form (see code below).

You could also make a wave digital filter version (now that we have
wdmodels.lib thanks to Dirk).

These "multimode filters" look like normal state variable filters to me
(following early analog filters used for solving differential equations in
a state-space format, according to my experience - I first encountered one
in 1972 or so at Rice University).

I have a small write-up on digitizing state-variable filters here:
https://ccrma.stanford.edu/~jos/svf/
but I didn't get into normalized structures (there are several).

I just compared direct-form to normalized-ladder in the test example
below.  The Faust compiler does not catch the optimization opportunity
(1st-order filter written in 2nd-order form), so it's up to the C++
compiler to find that.  I don't have time to look at the assembly code
right now, so please let us know if you check on that and learn the
result.  It should not be necessary to write out tf1snp explicitly.

// Test tf1snp defined as tf2snp with two 0 coefficients and compare to
direct-form

import("stdfaust.lib");

fc = 1000; // -3 dB frequency
g = 1.0;   // dc gain

// Analog zero at infinity:
b2 = 0;  b1 = g;  b0 = 0;

// Analog poles in normalized form (a2=1 implicitly):
a1 = 1.0;
a0 = 0; // Optimization should remove anything associated with this

// Frequency-scaling parameter for real-time bilinear xform = corner
frequency:
w1 = 2*ma.PI*max(fc,20);

filter1 = fi.tf2snp(b2,b1,b0,a1,a0,w1);
filter2 = 0.5*(1-p) * fi.iir_nl(bvd,avd) with { bvd = (1,1); avd = -p; p =
1-w1/pl.SR; };
process = 1-1' <: filter1, filter2;

// Check using faust2octave

On Fri, May 28, 2021 at 7:21 AM Till Bovermann  wrote:

> Hello list,
>
> long time again that I sneaked in here...
> but still working with faust and it is generally a nice experience, thanks
> everybody!
>
> I am currently looking into multimode filters; we are considering building
> something (analog) with a multimode filter based on the design found in
>
> http://www.soundsemiconductor.com/downloads/AN701.pdf
>
> p.19
>
> however with a feedback path to control filter resonance (as outlined on
> p.16)
>
>
> I build a preliminary emulation in faust like so [1].
>
> However, I am not happy with the dynamics of the filter when changing its
> parameters.
>
> I was thinking to use the fi.svf.lp filter as a building block instead but
> it is (AFAICS, it is not mentioned in the doc string...) not a 1st order
> design (which is crucial here, partly for consistency with the to be
> emulated analog circuitry, partly because the phase shift should be
> consistent to be able to deal with the resonance feedback).
>
>
> I would be very much interested in other approaches, especially one's that
> are closely related to the analog filter topology and its numerical
> stability when applying dynamics to the filter freq and q.
>
>
> any help much appreciated!
>
>
>
> Till
>
>
> (I am also searching for a gentle introduction to filter theory, i.e.
> explanations of Laplace / z-transforms, transfer functions, (virtual)
> analog filter design, ... I am OK in general maths but filter theory
> escapes me and most of the literature I find online assumes to much
> preliminary knowledge or dives too fast into mathematical deeps for me to
> follow...)
>
>
> [1]
>
> a parametric multimode filter inspired by Semiconductor's AN701
>
>  Parameters
> + a_amp: amplitude of original signal added in the mixing stage
>* `< 0` — use table
>* `> 0` — use this amplitude
> + freq; filter frequency
> + q; Q-factor
> + idx; indicates one of the 45 modes of the filter based on Sound
> Semiconductor's AN701
> [ 4LP, 3LP1HP, 3LP1AP, 3LP, 2LP2HP, 2LP1HP1AP, 2LP1HP, 2LP2AP, 2LP1AP,
> 2LP, 2LP1NT, 1LP3HP, 1LP2HP1AP, 1LP2HP, 1LP1HP2AP, 1LP1HP1AP, 1LP1HP,
> 1LP1HP1NT, 1LP3AP, 1LP2AP, 1LP1AP, 1LP1AP1NT, 1LP, 1LP1NT, 4HP, 3HP1AP,
> 3HP, 2HP2AP, 2NP1AP, 2HP, 2HP1NT, 1HP3AP, 1HP2AP, 1HP1AP, 1HP1AP1NT, 1HP,
> 1HP1NT, 4AP1, 3AP, 2AP, 2AP1NT, 1AP, 1AP1NT, 1NT, 2NT ]
>
>  Usage
>
> process = _ : multimode(freq, q, idx, a_amp) * amp <: _,_ with {
> freq = hslider("[0]freq[scale:exp]",100,10,2,0.001);
> q = hslider("[1]Q",0,0,15,0.001);
> idx = hslider("[2]mode",10, 0,44,1);
> amp = hslider("outamp",1, 0,4,0.001);
> a_amp = hslider("a_amp",-0.001, -0.001,1.0001,0.001);
> };
>
> ```
> multimode(freq, q, idx, a_amp) = _ : mix ~ _ : !, _ with {
>
> a(fbck, x) = x - (q * fbck);
>
> node = _ : lp(freq) * ba.db2linear(-3) * (-1) with {
> lp(freq) = fi.lowpass(1, freq);
> };
>
> b(fbck, x) = 

Re: [Faudiostream-users] FaustIDE to SC

[Julius Smith]

When I last used it, faust2supercollider had a -noprefix option.

- Julius

On Mon, May 17, 2021 at 1:32 PM Sam Pluta  wrote:

> Is there a way to use the faustIDE to export to supercollider without
> adding the word Faust in front of the UGen? I imagine this is going with
> the default of faust2supercollider, but it would be great to be able to
> turn it off (as you can in the Ruby script). The online IDE is amazing,
> btw. Thanks for that work.
>
> sam
>
> ___
> 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] [EXTERNAL] Re: hopping

[Julius Smith]

Hi Victor,

Yes, I was thinking of time-domain in, time-domain out, but amp and freq
streams would be more interesting to work with in Faust.  We can do that
now using a filter-bank approach, but of course that's more CPU load
without an FFT and without downsampling of the channels.

"Stream bundles" would be a major addition to the language!

Cheers,
Julius

On Thu, May 6, 2021 at 11:24 PM Victor Lazzarini 
wrote:

> Thanks, Julius.
>
> So that I understand what you mean: what form does the out stream take?
> Are you suggesting that the ffunction does all frequency-domain processing
> and returns
> a time-domain signal, or that it puts out the STFT frames back-to-back
> (not sure how it would work)?
>
>  I guess a pv analysis in an ffunction could produce amp and freq streams
> (for each bin). Just how to manage so many streams may be a challenge. If
> there was some sort of a container format that bundled several streams
> together, I think it would work. Then functions to pack/unpack. A ffunction
> pair for analysis/synthesis, a library function for additive synthesis.
> Library functions for common processes, and there you go, a spectral
> processing system within Faust.
>
> Prof. Victor Lazzarini
> Maynooth University
> Ireland
>
> On May 6, 2021, at 9:26 PM, Julius Smith  wrote:
>
> 
> Hi Victor and Dario,
>
> In the current Faust, I would put the FFT in a ffunction which hops
> internally.  From the Faust perspective, it would accept a signal stream
> and return an FFT-processed stream.
>
> Cheers,
> Julius
>
> On Thu, May 6, 2021 at 9:30 AM Victor Lazzarini 
> wrote:
>
>> yes, I wonder. The Hann window would of course be a raised scaled cosine
>> (it could reside in a library of course).
>>
>> Hopping and overlapp-add may be important beyond the STFT, for other
>> types of processing. As I said, maybe it just can't be done within the
>> constraints set by the language. It's been quite a while since I remember
>> chatting about this with Yann.
>>
>> best
>>
>> Prof. Victor Lazzarini
>> Maynooth University
>> Ireland
>>
>> On May 6, 2021, at 2:41 PM, Dario Sanfilippo 
>> wrote:
>>
>> 
>> *Warning*
>>
>> This email originated from outside of Maynooth University's Mail System.
>> Do not reply, click links or open attachments unless you recognise the
>> sender and know the content is safe.
>> Hi, Victor.
>>
>> I literally never work with FFT and all I know dates back to a decade or
>> so ago when I studied it for my master: I don't remember much. Sorry in
>> advance for clueless questions.
>>
>> If we had primitives performing FFT and IFFT, would it be possible to do
>> the overlapping stages in Faust with delayed signals?
>>
>> Something like this, for example?
>>
>> import("stdfaust.lib");
>> hann(size) = sin((ba.period(size) / size) * ma.PI) ^ 2.0;
>> hann_overlap(size, factor) = sum(i, factor, hann(size) @ ((size * i) /
>> factor)) / (factor / 2);
>> process = hann_overlap(1024, 8);
>>
>> Ciao,
>> Dario
>>
>> On Sun, 2 May 2021 at 14:52, Victor Lazzarini 
>> wrote:
>>
>>> Because it's been so many years since I remember discussing this, and
>>> because there's so many clever and knowledgeable people working on the
>>> Faust sources, I am supposing the hopping issue has no solution.
>>>
>>> Is that right?
>>>
>>> I was reminded of it by an user asking about the question here last
>>> week. My answer, which went directly to him, is that as far as I knew
>>> hopping was out of question, but that Julius had written an FFT, but to
>>> apply it to a stream, it had to be done on sample-by-sample basis. Julius
>>> then confirmed it here.
>>>
>>> Just curious to know the status of this.
>>>
>>> Prof. Victor Lazzarini
>>> Maynooth University
>>> Ireland
>>>
>>> ___
>>> Faudiostream-users mailing list
>>> Faudiostream-users@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/faudiostream-users
>>> <https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.sourceforge.net%2Flists%2Flistinfo%2Ffaudiostream-users=04%7C01%7CVictor.Lazzarini%40mu.ie%7C5b8d7bb7ec524ff0687908d910cd3b47%7C1454f5ccbb354685bbd98621fd8055c9%7C1%7C0%7C637559295915558171%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000=db92KsX9f5SGsCzMpBs0TSmt5idNkbVYG1l8KN1%2BY%2BI%3D=0>
>>>
>> ___

Re: [Faudiostream-users] [EXTERNAL] Re: hopping

[Julius Smith]

Hi Victor and Dario,

In the current Faust, I would put the FFT in a ffunction which hops
internally.  From the Faust perspective, it would accept a signal stream
and return an FFT-processed stream.

Cheers,
Julius

On Thu, May 6, 2021 at 9:30 AM Victor Lazzarini 
wrote:

> yes, I wonder. The Hann window would of course be a raised scaled cosine
> (it could reside in a library of course).
>
> Hopping and overlapp-add may be important beyond the STFT, for other types
> of processing. As I said, maybe it just can't be done within the
> constraints set by the language. It's been quite a while since I remember
> chatting about this with Yann.
>
> best
>
> Prof. Victor Lazzarini
> Maynooth University
> Ireland
>
> On May 6, 2021, at 2:41 PM, Dario Sanfilippo 
> wrote:
>
> 
> *Warning*
>
> This email originated from outside of Maynooth University's Mail System.
> Do not reply, click links or open attachments unless you recognise the
> sender and know the content is safe.
> Hi, Victor.
>
> I literally never work with FFT and all I know dates back to a decade or
> so ago when I studied it for my master: I don't remember much. Sorry in
> advance for clueless questions.
>
> If we had primitives performing FFT and IFFT, would it be possible to do
> the overlapping stages in Faust with delayed signals?
>
> Something like this, for example?
>
> import("stdfaust.lib");
> hann(size) = sin((ba.period(size) / size) * ma.PI) ^ 2.0;
> hann_overlap(size, factor) = sum(i, factor, hann(size) @ ((size * i) /
> factor)) / (factor / 2);
> process = hann_overlap(1024, 8);
>
> Ciao,
> Dario
>
> On Sun, 2 May 2021 at 14:52, Victor Lazzarini 
> wrote:
>
>> Because it's been so many years since I remember discussing this, and
>> because there's so many clever and knowledgeable people working on the
>> Faust sources, I am supposing the hopping issue has no solution.
>>
>> Is that right?
>>
>> I was reminded of it by an user asking about the question here last week.
>> My answer, which went directly to him, is that as far as I knew hopping was
>> out of question, but that Julius had written an FFT, but to apply it to a
>> stream, it had to be done on sample-by-sample basis. Julius then confirmed
>> it here.
>>
>> Just curious to know the status of this.
>>
>> Prof. Victor Lazzarini
>> Maynooth University
>> Ireland
>>
>> ___
>> Faudiostream-users mailing list
>> Faudiostream-users@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/faudiostream-users
>> 
>>
> ___
> Faudiostream-users mailing list
> Faudiostream-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/faudiostream-users
>


-- 
"Anybody who knows all about nothing knows everything" -- Leonard Susskind
___
Faudiostream-users mailing list
Faudiostream-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/faudiostream-users

Re: [Faudiostream-users] random value

[Julius Smith]

Hi Bob,

You could use latch to sample the random number stream.  However, it's more
efficient to do something that can be completed at compile time, e.g.,

rtz = (*(1103515245) + 12345) & mask;
rt(i) = seq(j,i+1,rtz) / RANDMAX;
process = 1 <: par(i,N,*(rt(i)));


On Wed, May 5, 2021 at 5:19 PM Bob Bobsled  wrote:

>
> Hi,
> I've pondered this code for a while, and am failing to understand how to
> declare a variable which has a single random value.  Of course this code
> creates random values at the sample rate.  How would you get just one value
> instead of a constant stream of values?
>
> mynoise = random / RANDMAX
> with{
> mask = 4294967295; // 2^32-1
> random = +(12345) ~ *(1103515245) & mask; // "linear congruential"
> RANDMAX = 2147483647.0; // = 2^31-1 = MAX_SIGNED_INT in 32 bits
> };
> process = mynoise;
>
> In other words, one would like to be able to do something such as this:
> process = os.osc(myrandomvalue);
>
> I understand there are various ways to provide frequencies, graphical and
> non-graphical. What I'm fundamentally searching for is how to declare a
> variable with a single random value.  I cannot seem to figure out how to
> slow down or stop things from flowing at the SR other than set SR to 1.
>
> Regards,
> Bob
> ___
> 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] moogladder

[Julius Smith]

Which of the three implementations are you using?  I prefer moog_vcf_2bn
myself.  It can be rapidly modulated and does not have the stability
problem of moog_vcf at high fundamental frequencies (which is caused by the
one-sample feedback delay).

- Julius

On Tue, May 4, 2021 at 1:02 PM Sam Pluta  wrote:

> The moogladder in the ve library sounds great. I am wondering if there is
> a mathematical way to understand the q at which the filter self-oscillates
> and when it blows up. This differs across the frequency range, and I want
> to limit it at the point of self oscillaiton. I could figure this out
> empirically, but if someone understands the maths, I would love to know.
>
> Thanks,
>
> Sam
>
> ___
> 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] Inputs as arguments

[Julius Smith]

I am no expert on the compiler, but it looks to me like there is a missing
signature for vbargraph defining the four-argument case.  There is a
similar restriction with button, checkbox, etc., but vgroup and hgroup have
explicit block-diagram arguments that cannot be "curried out", so to speak.

Maybe the right way to think about it is that "User Interface Elements" are
not Faust functions in the usual sense,  but something else?  It seems like
it shouldn't be hard to integrate them more completely, but again, I've not
looked at the details. Maybe they're parsed separately somehow...

- Julius

On Sat, May 1, 2021 at 9:56 AM Dario Sanfilippo 
wrote:

> Thank you for your answers, Oleg and Stéphane.
>
> I was wrong assuming that, at least for run-time cases, inputs could
> always be provided as arguments. If I'm not wrong, that is always possible
> with Faust-implemented functions (non-primitives).
>
> Ciao,
> Dario
>
> On Sat, 1 May 2021 at 18:41, Stéphane Letz  wrote:
>
>>
>>
>> > Le 1 mai 2021 à 18:37, Oleg Nesterov  a écrit :
>> >
>> > Hi Dario,
>> >
>> > I can't answer authoritatively, but nobody else bothered to reply and
>> > I hate the fact this list has a lot of unanswered technical questions.
>> >
>> > Add Stephane.
>> >
>> > On 04/25, Dario Sanfilippo wrote:
>> >>
>> >> Hello, list.
>> >>
>> >> I may be missing something obvious but would you know why
>> >>
>> >> process(x) = x : vbargraph("test", -1, 1);compiles
>> >>
>> >> while
>> >>
>> >> process(x) = vbargraph("test", -1, 1, x);
>> >>
>> >> doesn't?
>> >
>> > Because I think this is literally syntax error.
>> >
>> > See compiler/parser/faustparser.y:701
>> >
>> >   vbargraph   : VBARGRAPH LPAR uqstring PAR argument
>> PAR argument RPAR
>> >
>> > This means that faust simply can't parse, for example,
>> >
>> >   process = 0;
>> >   unused = vbargraph("test", 0,0,0);
>> >
>> > Oleg.
>>
>> Yes it it a syntax error, bargraph expects 3 arguments.
>>
>> 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] What are the limits to faust generated code?

[Julius Smith]

The problem is that the current Faust fft function provides only a
"sliding" FFT instead of the usual "hopping" FFT.
For fast FFT convolution, you want it to hop by its rectangular window
length.

On Sun, Apr 25, 2021 at 1:30 AM Muziker Mammoth 
wrote:

> I recall there is, on the website a set of disclaimers about what faust
> cannot do well, for example, fft/ifft, convolution. On the other hand,
> there's a faust library with fft & ifft, so what does this imply? Is this
> still true?
> ___
> 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] How to create a hslider that impacts other hsliders?

[Julius Smith]

Hi Muziker,

You can display a product of sliders in a bargraph and route the number out
as a signal, but to set another slider will require an external connection
via the architecture file or MIDI/OSC, etc.

Cheers,
- Julius


On Wed, Apr 7, 2021 at 11:58 PM Muziker Mammoth 
wrote:
>
> To be clearer, I would like to get hslider A to do some calculations and
set the level of hslider B, and between each other as well. Also is there
somekind of indicator widget, where lets say the result of
hslider("multiplier",0,1,1,0.1)*hslider("scale",0,1,1,0.1) can be stored
and displayed?
>
> On Wed, Apr 7, 2021 at 1:12 PM Muziker Mammoth 
wrote:
>>
>> I want to have a main hslider (main) that does some calculation and sets
two other hsliders ( A & B ). The user is able to use either A or B as a
variable to some other function, but when main is used, it will affect A &
B. Is there an example of how this can be achieved?
>
> ___
> 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] Faust, Big Sur, Macbook M1 CPU, RME Babyface

[Julius Smith]

Ok, this is progress!  Definitely don't use my spec file, as we're on
different processor architectures.
I guess the next question is "who is having no trouble with faust2caqt on a
Mac M1?"

On Tue, Feb 16, 2021 at 12:35 PM Dario Sanfilippo <
sanfilippo.da...@gmail.com> wrote:

> Hi, Julius.
>
> I guess that building for ARM would be correct since the new M1 chip is
> ARM-based.
>
> I've only got this if I run the command:
>
> dariosanfilippo@Darios-MBP faustlibraries % printenv | grep pkgconfig
>
>
> PKG_CONFIG_PATH=/opt/homebrew/opt/qt/lib/pkgconfig
>
> I can't see a lib dir but perhaps that wouldn't solve my problem.
>
> Stéphane did a bit of digging and, while the -march=native an M1 one
> issue because that flag is not supported, which I solved by commenting that
> line, the fact that the CAQt program crashed was apparently due to a
> codesign issue, which is Big Sur-related.
>
> Now, I'm also on the latest, 11.2.1, but I wouldn't know why you're not
> having such problems.
>
> Really, thank you so much for your time.
>
> Dario
>
> On Tue, 16 Feb 2021 at 20:49, Julius Smith  wrote:
>
>> Hi Dario,
>>
>> Do you really mean to be building for ARM?
>>
>> Another thing to check is your PKG_CONFIG set up.   Here is mine:
>>
>> > printenv | grep pkgconfig
>>
>> PKG_CONFIG_PATH=.:/usr/local/lib/pkgconfig:/opt/local/lib/pkgconfig:/usr/lib/pkgconfig:/usr/share/pkgconfig
>> PKG_CONFIG_LIBDIR=/usr/local/lib/pkgconfig
>>
>> If you want to try my macx-clang make-spec, here it is:
>> https://ccrma.stanford.edu/~jos/tgz/macx-clang.tgz
>> I am on an iMac Pro, latest Big Sur update.
>>
>> - Julius
>>
>> On Tue, Feb 16, 2021 at 4:45 AM Dario Sanfilippo <
>> sanfilippo.da...@gmail.com> wrote:
>>
>>> Following suggestion by Stéphane, I have removed the -march=native flag
>>> and I managed to build a faust2caqt app, but the app instantly crashes with
>>> the following error when opening it:
>>>
>>> Process:   test_adaa [6556]
>>> Path:
>>>  /Users/USER/*/test_adaa.app/Contents/MacOS/test_adaa
>>> Identifier:com.yourcompany.test-adaa
>>> Version:   1.0.0 (1.0.0)
>>> Code Type: ARM-64 (Native)
>>> Parent Process:??? [1]
>>> Responsible:   test_adaa [6556]
>>> User ID:   501
>>>
>>> Date/Time: 2021-02-16 13:42:28.486 +0100
>>> OS Version:macOS 11.2.1 (20D74)
>>> Report Version:12
>>> Anonymous UUID:4A161F82-9B5B-4297-A5A3-82B4C2586876
>>>
>>> Sleep/Wake UUID:   4B4B7471-D0EE-465C-BA66-8283EBC78547
>>>
>>> Time Awake Since Boot: 34000 seconds
>>> Time Since Wake:   1700 seconds
>>>
>>> System Integrity Protection: enabled
>>>
>>> Crashed Thread:0
>>>
>>> Exception Type:EXC_BAD_ACCESS (Code Signature Invalid)
>>> Exception Codes:   0x0032, 0x00010415c000
>>> Exception Note:EXC_CORPSE_NOTIFY
>>>
>>> Termination Reason:Namespace CODESIGNING, Code 0x2
>>>
>>> kernel messages:
>>>
>>> VM Regions Near 0x10415c000:
>>> __LINKEDIT  10414c000-10415c000[   64K] r--/r--
>>> SM=COW  /Users/*/test_adaa.app/Contents/MacOS/test_adaa
>>> --> mapped file 10415c000-10416[   16K] r--/r-x
>>> SM=PRV  Object_id=c7c4649
>>> __TEXT  1042ec000-104368000[  496K] r-x/r-x
>>> SM=COW  /usr/lib/dyld
>>>
>>> Application Specific Information:
>>> dyld: launch, loading dependent libraries
>>>
>>> @executable_path/../Frameworks/QtPrintSupport.framework/Versions/5/QtPrintSupport
>>>
>>> Thread 0 Crashed:
>>> 0   dyld   0x000104348780 bcmp + 16
>>> 1   dyld   0x000104309408
>>> ImageLoaderMachO::validateFirstPages(linkedit_data_command const*, int,
>>> unsigned char const*, unsigned long, long long, ImageLoader::LinkContext
>>> const&) + 136
>>> 2   dyld   0x0001043103b8
>>> ImageLoaderMachOCompressed::instantiateFromFile(char const*, int, unsigned
>>> char const*, unsigned long, unsigned long long, unsigned long long, stat
>>> const&, unsigned int, unsigned int, linkedit_data_command const*,
>>> encryption_info_command const*, ImageLoader::LinkContext const&) + 2

Re: [Faudiostream-users] Faust, Big Sur, Macbook M1 CPU, RME Babyface

[Julius Smith]

t; Graphics: kHW_AppleM1Item, Apple M1, spdisplays_builtin
> Memory Module: lp_ddr4
> AirPort: spairport_wireless_card_type_airport_extreme, wl0: Dec 31 2020
> 21:39:03 version 18.20.222.20.7.8.104 FWID 01-1b2645bc
> Bluetooth: Version 8.0.3d9, 3 services, 25 devices, 1 incoming serial ports
> Network Service: Wi-Fi, AirPort, en0
> USB Device: USB 3.1 Bus
> USB Device: USB 3.1 Bus
> Thunderbolt Bus: MacBook Pro, Apple Inc.
> Thunderbolt Bus: MacBook Pro, Apple Inc.
>
> On Tue, 16 Feb 2021 at 10:20, Dario Sanfilippo 
> wrote:
>
>> Hi, Julius.
>>
>> I have:
>>
>> dariosanfilippo@Darios-MBP faustlibraries % which qmake
>>
>> /opt/homebrew/opt/qt/bin/qmake
>>
>> dariosanfilippo@Darios-MBP faustlibraries % `which qmake` -v
>>
>> QMake version 3.1
>>
>> Using Qt version 5.15.2 in /opt/homebrew/Cellar/qt/5.15.2/lib
>>
>> and
>>
>> dariosanfilippo@Darios-MBP faustlibraries % `which clang` -v
>>
>> Apple clang version 12.0.0 (clang-1200.0.32.29)
>>
>> Target: arm64-apple-darwin20.3.0
>>
>> Thread model: posix
>> InstalledDir: /Library/Developer/CommandLineTools/usr/bin
>>
>> These are the last few lines before the error:
>>
>> + faust -i -json -a /usr/local/share/faust/ca-qt.cpp -double
>> ./test_adaa.dsp -o faust.hLi9nX/test_adaa/test_adaa_tmp.cpp
>>
>> + '[' auto = auto ']'
>>
>> + echo '#define PRESETDIR "/var/tmp/"'
>>
>> + cat faust.hLi9nX/test_adaa/preset.cpp
>> faust.hLi9nX/test_adaa/test_adaa_tmp.cpp
>>
>> + rm faust.hLi9nX/test_adaa/preset.cpp
>> faust.hLi9nX/test_adaa/test_adaa_tmp.cpp
>>
>> + cd faust.hLi9nX/test_adaa
>>
>> + qmake -project 'QT += widgets printsupport network' CONFIG+=warn_off
>> 'QMAKE_MACOSX_DEPLOYMENT_TARGET = 10.9'
>> INCLUDEPATH+=/Users/dariosanfilippo/Research/Faust_dev/faustlibraries
>> 'INCLUDEPATH+=/usr/local/include /opt/local/include' 'QMAKE_CXXFLAGS=  
>> -std=c++11
>> -Ofast -march=native -mmacosx-version-min=10.9 -Wno-unused-parameter '
>> QMAKE_INFO_PLIST=/usr/local/share/faust/Info.plist 'LIBS+=-L/usr/local/lib
>> -L/usr/local/lib  -framework CoreAudio -framework AudioUnit -framework
>> CoreServices -framework CoreMIDI -framework CoreFoundation'
>> HEADERS+=/usr/local/include/faust/gui/QTUI.h 'RESOURCES+=
>> /usr/local/include/faust/gui/Styles/Grey.qrc' '' '' '' '' '' '' '' '' ''
>>
>> + qmake -spec macx-clang
>>
>> Project WARNING: Qt has only been tested with version 10.15 of the
>> platform SDK, you're using 11.1.
>>
>> Project WARNING: This is an unsupported configuration. You may experience
>> build issues, and by using
>>
>> Project WARNING: the 11.1 SDK you are opting in to new features that Qt
>> has not been prepared for.
>>
>> Project WARNING: Please downgrade the SDK you use to build your app to
>> version 10.15, or configure
>>
>> Project WARNING: with CONFIG+=sdk_no_version_check when running qmake to
>> silence this warning.
>>
>> + make
>>
>> clang: error: the clang compiler does not support '-march=native'
>>
>> make: *** [test_adaa.o] Error 1
>> + exit
>>
>> Thanks,
>> Dario
>>
>>
>>
>> On Tue, 16 Feb 2021 at 01:48, Julius Smith 
>> wrote:
>>
>>> I've seen that before, and -march=native should be ok.
>>>
>>> Here is what I have:
>>>
>>> > `which qmake` -v
>>> QMake version 3.1
>>> Using Qt version 5.15.2 in /usr/local/Cellar/qt/5.15.2/lib
>>>
>>> > `which clang` -v
>>> Apple clang version 12.0.0 (clang-1200.0.32.27)
>>> Target: x86_64-apple-darwin20.3.0
>>> Thread model: posix
>>> InstalledDir:
>>> /Devel/Xcode12p2.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin
>>>
>>> How about you?  Another thing to do is uncomment the "set -x" line in
>>> /usr/local/bin/faust2caqt
>>> Then you can follow the script progress.
>>> I too get those warning messages, but my clang is fine with -march=native
>>>
>>> - Julius
>>>
>>>
>>>
>>> On Mon, Feb 15, 2021 at 11:27 AM Dario Sanfilippo <
>>> sanfilippo.da...@gmail.com> wrote:
>>>
>>>> Thanks for your help, Julius.
>>>>
>>>> I linked macx-clang-arm64 as I'm on the M1 chip but now it's this other
>>>> issues:
>>>>
>>>> dariosanfilippo@Darios-MBP faustlibraries % faust2caqt -double
>>>> test_adaa.dsp
>>>&g

Re: [Faudiostream-users] Faust, Big Sur, Macbook M1 CPU, RME Babyface

[Julius Smith]

I've seen that before, and -march=native should be ok.

Here is what I have:

> `which qmake` -v
QMake version 3.1
Using Qt version 5.15.2 in /usr/local/Cellar/qt/5.15.2/lib

> `which clang` -v
Apple clang version 12.0.0 (clang-1200.0.32.27)
Target: x86_64-apple-darwin20.3.0
Thread model: posix
InstalledDir:
/Devel/Xcode12p2.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin

How about you?  Another thing to do is uncomment the "set -x" line in
/usr/local/bin/faust2caqt
Then you can follow the script progress.
I too get those warning messages, but my clang is fine with -march=native

- Julius



On Mon, Feb 15, 2021 at 11:27 AM Dario Sanfilippo <
sanfilippo.da...@gmail.com> wrote:

> Thanks for your help, Julius.
>
> I linked macx-clang-arm64 as I'm on the M1 chip but now it's this other
> issues:
>
> dariosanfilippo@Darios-MBP faustlibraries % faust2caqt -double
> test_adaa.dsp
>
> Project WARNING: Qt has only been tested with version 10.15 of the
> platform SDK, you're using 11.1.
>
> Project WARNING: This is an unsupported configuration. You may experience
> build issues, and by using
>
> Project WARNING: the 11.1 SDK you are opting in to new features that Qt
> has not been prepared for.
>
> Project WARNING: Please downgrade the SDK you use to build your app to
> version 10.15, or configure
>
> Project WARNING: with CONFIG+=sdk_no_version_check when running qmake to
> silence this warning.
>
> clang: error: the clang compiler does not support '-march=native'
>
> make: *** [test_adaa.o] Error 1
>
> Dario
>
>
> On Mon, 15 Feb 2021 at 20:14, Julius Smith  wrote:
>
>> That looks like the problem.  I would cd to that directory and type
>>
>> sudo ln -s macx-clang-x64 macx-clang
>>
>> assuming you are on an Intel Mac.
>>
>> - Julius
>>
>> On Mon, Feb 15, 2021 at 1:25 AM Dario Sanfilippo <
>> sanfilippo.da...@gmail.com> wrote:
>>
>>> Hi, Julius.
>>>
>>> I have
>>>
>>> macx-clang-arm64
>>>
>>> macx-clang-x64
>>>
>>> in
>>>
>>> /opt/homebrew/Cellar/qt/5.15.2/mkspecs
>>>
>>>
>>> Shouldn't the first line in my .zshrc refer to this folder too? Should
>>> there also be a macx-clang or does Faust need to specify macx-clang-arm64
>>> for these machines?
>>>
>>> Thanks,
>>> Dario
>>>
>>>
>>> On Mon, 15 Feb 2021 at 02:20, Julius Smith 
>>> wrote:
>>>
>>>> Hi Dario,
>>>>
>>>> Do you have this?:
>>>>
>>>> > locate macx-clang
>>>> /usr/local/Cellar/qt/5.15.2/mkspecs/macx-clang
>>>>
>>>> If so, maybe there is a config problem
>>>>
>>>> faust2caqt is working for me on Big Sur.
>>>>
>>>> - Julius
>>>>
>>>> On Sun, Feb 14, 2021 at 12:47 PM Dario Sanfilippo <
>>>> sanfilippo.da...@gmail.com> wrote:
>>>>
>>>>> By the way, these are the lines added to my .zshrc file:
>>>>>
>>>>> export PATH="/opt/homebrew/opt/qt/bin:$PATH"
>>>>>
>>>>> export LDFLAGS="-L/opt/homebrew/opt/qt/lib"
>>>>>
>>>>> export CPPFLAGS="-I/opt/homebrew/opt/qt/include"
>>>>>
>>>>> export PKG_CONFIG_PATH="/opt/homebrew/opt/qt/lib/pkgconfig"
>>>>>
>>>>> Thanks,
>>>>> Dario
>>>>>
>>>>>
>>>>> On Sun, 14 Feb 2021 at 20:23, Dario Sanfilippo <
>>>>> sanfilippo.da...@gmail.com> wrote:
>>>>>
>>>>>> Hi, Alex and all.
>>>>>>
>>>>>> I'm trying to have Faust running on OSX 11.2.1, M1 chip, but I'm
>>>>>> having a few issues.
>>>>>>
>>>>>> With faust2caqt, I get the following error:
>>>>>>
>>>>>> Could not find qmake spec 'macx-clang'.
>>>>>>
>>>>>> Error processing project file:
>>>>>> /Users/dariosanfilippo/Research/Faust_dev/faustlibraries/faust.JD9TVA/test_adaa/
>>>>>> test_adaa.pro
>>>>>>
>>>>>> make: *** No targets specified and no makefile found.  Stop.
>>>>>>
>>>>>> If I run a "which" on qmake and make, I get this:
>>>>>>
>>>>>> dariosanfilippo@Darios-MBP ~ % which qmake
>>>>>>
>>>>>> /o

Re: [Faudiostream-users] Faust, Big Sur, Macbook M1 CPU, RME Babyface

[Julius Smith]

That looks like the problem.  I would cd to that directory and type

sudo ln -s macx-clang-x64 macx-clang

assuming you are on an Intel Mac.

- Julius

On Mon, Feb 15, 2021 at 1:25 AM Dario Sanfilippo 
wrote:

> Hi, Julius.
>
> I have
>
> macx-clang-arm64
>
> macx-clang-x64
>
> in
>
> /opt/homebrew/Cellar/qt/5.15.2/mkspecs
>
>
> Shouldn't the first line in my .zshrc refer to this folder too? Should
> there also be a macx-clang or does Faust need to specify macx-clang-arm64
> for these machines?
>
> Thanks,
> Dario
>
>
> On Mon, 15 Feb 2021 at 02:20, Julius Smith  wrote:
>
>> Hi Dario,
>>
>> Do you have this?:
>>
>> > locate macx-clang
>> /usr/local/Cellar/qt/5.15.2/mkspecs/macx-clang
>>
>> If so, maybe there is a config problem
>>
>> faust2caqt is working for me on Big Sur.
>>
>> - Julius
>>
>> On Sun, Feb 14, 2021 at 12:47 PM Dario Sanfilippo <
>> sanfilippo.da...@gmail.com> wrote:
>>
>>> By the way, these are the lines added to my .zshrc file:
>>>
>>> export PATH="/opt/homebrew/opt/qt/bin:$PATH"
>>>
>>> export LDFLAGS="-L/opt/homebrew/opt/qt/lib"
>>>
>>> export CPPFLAGS="-I/opt/homebrew/opt/qt/include"
>>>
>>> export PKG_CONFIG_PATH="/opt/homebrew/opt/qt/lib/pkgconfig"
>>>
>>> Thanks,
>>> Dario
>>>
>>>
>>> On Sun, 14 Feb 2021 at 20:23, Dario Sanfilippo <
>>> sanfilippo.da...@gmail.com> wrote:
>>>
>>>> Hi, Alex and all.
>>>>
>>>> I'm trying to have Faust running on OSX 11.2.1, M1 chip, but I'm having
>>>> a few issues.
>>>>
>>>> With faust2caqt, I get the following error:
>>>>
>>>> Could not find qmake spec 'macx-clang'.
>>>>
>>>> Error processing project file:
>>>> /Users/dariosanfilippo/Research/Faust_dev/faustlibraries/faust.JD9TVA/test_adaa/
>>>> test_adaa.pro
>>>>
>>>> make: *** No targets specified and no makefile found.  Stop.
>>>>
>>>> If I run a "which" on qmake and make, I get this:
>>>>
>>>> dariosanfilippo@Darios-MBP ~ % which qmake
>>>>
>>>> /opt/homebrew/opt/qt/bin/qmake
>>>>
>>>> dariosanfilippo@Darios-MBP ~ % which make
>>>> /usr/bin/make
>>>>
>>>> If I run qmake -v I get:
>>>>
>>>> QMake version 3.1
>>>>
>>>> Using Qt version 5.15.2 in /opt/homebrew/Cellar/qt/5.15.2/lib
>>>>
>>>> I have also added these lines to my .zshrc as suggested by Brew as the
>>>> formula is keg-only.
>>>>
>>>> With faust2csvplot, I get this error:
>>>>
>>>> clang: error: the clang compiler does not support '-march=native'
>>>>
>>>> If I run "which" on clang, I get this:
>>>>
>>>> /usr/bin/clang
>>>>
>>>> And then running clang -v:
>>>>
>>>> Apple clang version 12.0.0 (clang-1200.0.32.29)
>>>>
>>>> Target: arm64-apple-darwin20.3.0
>>>>
>>>> Thread model: posix
>>>> InstalledDir: /Library/Developer/CommandLineTools/usr/bin
>>>>
>>>> Can anybody help with this?
>>>>
>>>> Thanks,
>>>> Dario
>>>>
>>>>
>>>> On Sun, 24 Jan 2021 at 01:03,  wrote:
>>>>
>>>>> I’ve used Faust on my M1 Mac (Big Sur 11.1) without too many problems
>>>>> apart from having to whitelist modules after exporting them. Haven’t used
>>>>> RME Babyface.
>>>>>
>>>>> – Alex
>>>>> Le 23 janv. 2021 18:48 -0500, Dario Sanfilippo <
>>>>> sanfilippo.da...@gmail.com>, a écrit :
>>>>>
>>>>> Hello, list. I hope that you're all well.
>>>>>
>>>>> Do you have experience with Faust and the hardware/software in the
>>>>> subject? Anything I should worry about in particular?
>>>>>
>>>>> --
>>>>> Dr Dario Sanfilippo
>>>>> http://dariosanfilippo.com
>>>>> ___
>>>>> Faudiostream-users mailing list
>>>>> Faudiostream-users@lists.sourceforge.net
>>>>> https://lists.sourceforge.net/lists/listinfo/faudiostream-users
>>>>>
>>>>>
>>>>
>>>> --
>>>> Dr Dario Sanfilippo
>>>> http://dariosanfilippo.com
>>>>
>>>
>>>
>>> --
>>> Dr Dario Sanfilippo
>>> http://dariosanfilippo.com
>>> ___
>>> 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
>>
>
>
> --
> Dr Dario Sanfilippo
> http://dariosanfilippo.com
>


-- 
"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] Faust, Big Sur, Macbook M1 CPU, RME Babyface

[Julius Smith]

Hi Dario,

Do you have this?:

> locate macx-clang
/usr/local/Cellar/qt/5.15.2/mkspecs/macx-clang

If so, maybe there is a config problem

faust2caqt is working for me on Big Sur.

- Julius

On Sun, Feb 14, 2021 at 12:47 PM Dario Sanfilippo <
sanfilippo.da...@gmail.com> wrote:

> By the way, these are the lines added to my .zshrc file:
>
> export PATH="/opt/homebrew/opt/qt/bin:$PATH"
>
> export LDFLAGS="-L/opt/homebrew/opt/qt/lib"
>
> export CPPFLAGS="-I/opt/homebrew/opt/qt/include"
>
> export PKG_CONFIG_PATH="/opt/homebrew/opt/qt/lib/pkgconfig"
>
> Thanks,
> Dario
>
>
> On Sun, 14 Feb 2021 at 20:23, Dario Sanfilippo 
> wrote:
>
>> Hi, Alex and all.
>>
>> I'm trying to have Faust running on OSX 11.2.1, M1 chip, but I'm having a
>> few issues.
>>
>> With faust2caqt, I get the following error:
>>
>> Could not find qmake spec 'macx-clang'.
>>
>> Error processing project file:
>> /Users/dariosanfilippo/Research/Faust_dev/faustlibraries/faust.JD9TVA/test_adaa/
>> test_adaa.pro
>>
>> make: *** No targets specified and no makefile found.  Stop.
>>
>> If I run a "which" on qmake and make, I get this:
>>
>> dariosanfilippo@Darios-MBP ~ % which qmake
>>
>> /opt/homebrew/opt/qt/bin/qmake
>>
>> dariosanfilippo@Darios-MBP ~ % which make
>> /usr/bin/make
>>
>> If I run qmake -v I get:
>>
>> QMake version 3.1
>>
>> Using Qt version 5.15.2 in /opt/homebrew/Cellar/qt/5.15.2/lib
>>
>> I have also added these lines to my .zshrc as suggested by Brew as the
>> formula is keg-only.
>>
>> With faust2csvplot, I get this error:
>>
>> clang: error: the clang compiler does not support '-march=native'
>>
>> If I run "which" on clang, I get this:
>>
>> /usr/bin/clang
>>
>> And then running clang -v:
>>
>> Apple clang version 12.0.0 (clang-1200.0.32.29)
>>
>> Target: arm64-apple-darwin20.3.0
>>
>> Thread model: posix
>> InstalledDir: /Library/Developer/CommandLineTools/usr/bin
>>
>> Can anybody help with this?
>>
>> Thanks,
>> Dario
>>
>>
>> On Sun, 24 Jan 2021 at 01:03,  wrote:
>>
>>> I’ve used Faust on my M1 Mac (Big Sur 11.1) without too many problems
>>> apart from having to whitelist modules after exporting them. Haven’t used
>>> RME Babyface.
>>>
>>> – Alex
>>> Le 23 janv. 2021 18:48 -0500, Dario Sanfilippo <
>>> sanfilippo.da...@gmail.com>, a écrit :
>>>
>>> Hello, list. I hope that you're all well.
>>>
>>> Do you have experience with Faust and the hardware/software in the
>>> subject? Anything I should worry about in particular?
>>>
>>> --
>>> Dr Dario Sanfilippo
>>> http://dariosanfilippo.com
>>> ___
>>> Faudiostream-users mailing list
>>> Faudiostream-users@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/faudiostream-users
>>>
>>>
>>
>> --
>> Dr Dario Sanfilippo
>> http://dariosanfilippo.com
>>
>
>
> --
> Dr Dario Sanfilippo
> http://dariosanfilippo.com
> ___
> 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] [Faudiostream-devel] Documentation on architectures files

[Julius Smith]

This is excellent!
Thanks!
Julius

On Wed, Feb 3, 2021 at 12:14 AM Stéphane Letz  wrote:

> Hi all,
>
> Never too late, an extensive documentation on architecture files is now
> published: https://faustdoc.grame.fr/manual/architectures/
>
> Feedback welcome: parts still not so clear, missing explanations, typos...
>
> Stéphane
>
> ___
> Faudiostream-devel mailing list
> faudiostream-de...@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/faudiostream-devel
>


-- 
"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] Looping / Retriggerable Envelope

[Julius Smith]

How about a pulse train gate?:

period = attT60+relT60;
freqHz = 1.0/period;
duty = attT60/period;
gate = os.lf_pulsetrainpos(freqHz,duty);
process = en.arfe(attT60,relT60,0,gate);


On Thu, Jan 7, 2021 at 1:55 PM Thomas Züblin  wrote:

> Thanks for the suggestion, it sounds very reasonable. I managed to get a
> step closer to what i want using this code:
>
> arrt(attT60,relT60,fv,gate) = envelope with {
>   ugate = pulsen(200,sec2samp(attT60 + relT60)); // gate > 0 ;
>   target = select2(ugate, fv, float(gate));
>   t60 = select2(ugate, relT60, attT60);
>   pole = si.smooth(ba.tau2pole(t60/6.91));
>   envelope = target : pole;
> };
>
> The pulsen repeatedly triggers the env, the interval depends on Attack /
> Release. It sounds close to what i want, the only problem i have is that i
> would need a way to restart the pulsen at every gate upfront. I think I
> first need to take a good look at all the available library objects.
>
>
>
>
> Am 07.01.2021 um 22:05 schrieb Mouldy Soul :
>
> This may sound dumb, but do you even need to check?
>
> Can't you just add the time for A + D together and trigger based on that
> interval?
>
> On Thu, 7 Jan 2021 at 20:59, Thomas Züblin  wrote:
>
>> Hi all,
>>
>> I’m very new to Faust and for the last two evenings i was trying to add
>> some kind of retrigger functionality to the existing AR envelope. By that i
>> mean, that the envelope should retrigger itself, as soon as the release
>> phase is finished, ideally with some option to toggle between single cycle
>> and retrigger behaviour. I tried to add some check that detects the end of
>> the release phase (that worked) and combine this with the gate that
>> triggers the envelope but ran into some recursion problems.
>>
>> Any ideas or tips how to achieve this? Thanks for your time,
>>
>> Tom
>>
>> ___
>> Faudiostream-users mailing list
>> Faudiostream-users@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/faudiostream-users
>>
>
> ___
> Faudiostream-users mailing list
> Faudiostream-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/faudiostream-users
>


-- 
"Anybody who knows all about nothing knows everything" -- Leonard Susskind
___
Faudiostream-users mailing list
Faudiostream-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/faudiostream-users

Re: [Faudiostream-users] documentation of headers

[Julius Smith]

I second Stéphane's recommendation of APIUI.h
Here is my "faust2header.cpp" architecture file that converts .dsp to .h
for integration into larger C++ projects:

#include 
#include 
<>
<>

- Julius

On Mon, Dec 28, 2020 at 1:07 AM Stéphane Letz  wrote:

> You cal possible use APIUI here :
> https://github.com/grame-cncm/faust/blob/master-dev/architecture/faust/gui/APIUI.h
>
> (even it it is possible a bit « too much » for you use case)
>
> Stéphan e
>
> > Le 28 déc. 2020 à 09:45, Till Bovermann  a écrit :
> >
> > Season's greetings!
> >
> > I was wondering if there is any documentation of the header files to be
> included into arch-files.
> > I am particularly interested to find a UI header that, unlike
> "faust/gui/MapUI.h", stores
> > min, max, step, etc.
> > of active gui elements.
> >
> > cheers and thanks for any help
> >   Till
> >
> >
> > --
> > Till Bovermann
> >
> > https://tai-studio.org | http://lfsaw.de |
> https://www.instagram.com/_lfsaw/
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > ___
> > Faudiostream-users mailing list
> > Faudiostream-users@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/faudiostream-users
>
>
>
> ___
> Faudiostream-users mailing list
> Faudiostream-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/faudiostream-users
>


-- 
"Anybody who knows all about nothing knows everything" -- Leonard Susskind
___
Faudiostream-users mailing list
Faudiostream-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/faudiostream-users

Re: [Faudiostream-users] noise from fi.highpass

[Julius Smith]

Interesting test!
Will have to drill down on this...

On Tue, Dec 22, 2020 at 11:43 AM Oleg Nesterov  wrote:

> Julius, et al,
>
> sorry for delay, I was busy.
>
> And let me apologize in advance, most probably I won't be responsive
> till next week.
>
> On 12/20, Julius Smith wrote:
> >
> > In filters.lib, I just now changed (in faustlibraries / master)
> >   smax = 0.;
> > to
> >   smax = 1.0-ma.EPSILON;
>
> OK, I ran the test below with this change applied,
>
> > The question remains as to which filter form is more accurate.
>
> Hmm. QUITE POSSIBLY I am wrong, I'll recheck. But see below, it seems
> that svf is more accurate, at least with -single option.
>
> > Another thing worth mentioning, by the way, is that tf2snp can be
> > modulated, even using white noise for its coefficients, without affecting
> > signal energy.
>
> I'll write another email about this when I have time...
>
>
> ---
>
> test:
> import("stdfaust.lib");
>
> F = 1;
> w1 = 2*ma.PI*F;
> a1s = -2.0*cos((ma.PI)*-1.0 + ma.PI/4.0);
>
> hp_df = fi.tf2s   (1,0,0,a1s,1,w1);
> hp_np = fi.tf2snp (1,0,0,a1s,1,w1);
> hp_svf = fi.svf.hp(F, 1/sqrt(2));
>
> process = 1-1' <: hp_df, hp_np, hp_svf;
>
> Compile with "-single -a plot.cpp", save the output to file:
>
> $ ./test-plot -n 5 >/tmp/ir
>
> Now, lets plot the difference with the theoretical impulse response
> calculated by maxima:
>
> F0 : 1 $
> SR : 44100 $
>
> H(s,Q) := s^2 / (s^2 + s/Q + 1) $
>
> subst(s = G * (z-1)/(z+1), H(s,Q)) $
> define(TF(z), facsum(ratsimp(%),z)) $
>
> res2(tf, z) := block([t,d, p1,p2, r1,r2],
> t: facsum(ratsimp(tf), z), d: denom(t),
> solve(d, z), [p1,p2] : map(rhs, %%),
> t: num(t) / (coeff(d,z,2) * (z-p1) * (z-p2)),
>
> t * (z-p1)/z, ev(%%, z=p1), r1: map(factor, %%),
> t * (z-p2)/z, ev(%%, z=p2), r2: map(factor, %%),
>
> [r1,r2, p1,p2]
> ) $
>
> [r1,r2, p1,p2]: res2(TF(z),z) $
> /* check, should print zero */
> ratsimp(r1/(1-p1/z) + r2/(1-p2/z) + TF(0) - TF(z));
>
> G: 1/tan(%pi*F0/SR) $ Q: 1/sqrt(2) $
> /* check, should print zero */
> r1-conjugate(r2), eval, bfloat, polarform;
> p1-conjugate(p2), eval, bfloat, polarform;
>
> [i,r,p]: ev([TF(0),r1,p1], eval, bfloat, polarform) $
>
> /*
> declare(n, integer) $
> assume(n >= 0) $
> declare([rm,ra,pm,pa],real) $
> rm*exp(%i*ra) * (pm*exp(%i*pa))^n +
> conjugate(rm*exp(%i*ra)) * conjugate(pm*exp(%i*pa))^n $
> demoivre(%)$ ratsimp(%);
>
> */
>
> define(IR(n),
> charfun(n<1) * i +
> 2 * cabs(r) * cabs(p)^n * cos(carg(r) + carg(p) * n)
> );
>
> /* OK, lets print the difference */
> m: transpose(read_matrix("/tmp/ir")) $
> I: makelist(IR(n),n,0,length(m[3])-1) $
> e: m - matrix(I,I,I) $
> plot2d([[discrete, e[1]], [discrete, e[2]], [discrete, e[3]]],
> [yx_ratio, 0], grid2d) $
>
> See the result:
>
> http://people.redhat.com/onestero/svf/ir-diff.png
>
> Oleg.
>
>

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