Re: [Faudiostream-users] [Faudiostream-devel] Documentation on architectures files

[pdowling]

i just want to second that this is great documentation, thanks.


> On 6. Feb 2021, at 21:23, Julius Smith  wrote:
> 
> 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

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

Re: [Faudiostream-users] Hilbert filter

[pdowling]

Polyphase IIR by Oli Niemitalo.

P .


> On 6. Jul 2019, at 08:16, Julius Smith  wrote:
> 
> Do we know its copyright status?  I think it would
> be worth adding to the library if we can determine this and author.

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

Re: [Faudiostream-users] "ZDF" SVF in C++, could this be converted to FAUST?

[pdowling]

> By the way, I don't know why they are called "zero-delay filters".  I
> just see second-order digital filters, 

they are *not* called 'zero-delay filters'. they are called 'zero-delay 
feedback (filters)' - 'zdf filters' - the f stands for feedback, as of course 
there is no such thing as a filter with no delay :-)

> There's no bell filter,
> however, because I don't know what that is.

'bell' is just a fun terminology for 'peaknotch'.

in the most recent version of the paper simper makes the comparison with 
coefficients worked for df1 / df2, and coefficients worked for this zdf svf. 
they produce identical (linear) filters.

they come into their own when 1) modulated - they perform far superior to df1/2 
and 2) when solved for nonlinear behaviour - what the zdF is essentially for - 
no unit delay in the feedback path if done correctly, behave complete 
differently.


thanks,
pete .



> On 22 Aug 2018, at 16:49, Julius Smith  wrote:
> 
> Hi Oleg,
> 
> I don't yet know what benefits are offered by ZDFs that are not
> already covered by the existing filter forms in filters.lib.  Search
> for "Parametric Equalizers (Shelf, Peaking)" in that file, and
> lowpass, highpass, allpass, and so on.  There's no bell filter,
> however, because I don't know what that is.  The classic state
> variable filter cases (lowpass, bandpass, highpass, notch) are
> immediately obtained using tf2s, as derived in
> https://ccrma.stanford.edu/~jos/svf/ .
> 
> So, except for bell, which I'm happy to add if I can get some doc on
> what it's for, all of these functions are available already.  Your zdf
> forms presumably have different numerical properties in the LSBs, and
> they might even result in more or less efficient Faust code.  Please
> let us know if you can make a case for them relative to the existing
> implementations.
> 
> By the way, I don't know why they are called "zero-delay filters".  I
> just see second-order digital filters, but implemented in what looks
> like a state-variable-inspired topology.  I suppose I need to read the
> derivation of ZDFs, which I haven't yet, but I will if they do
> something the other second-order forms can't do.
> 
> Note that filters.lib does have alternate forms available already
> (ladder, lattice, etc.), and there is a literature explaining when and
> how they are better and under what conditions.  I try to give my
> favorite literature pointers in the comments in the Faust source.  Is
> there such a literature for ZDFs?   If so, under what conditions do
> they win over all the others?
> 
> Thanks,
> - Julius
> 
> 
> On Wed, Aug 22, 2018 at 8:44 PM Oleg Nesterov  > wrote:
>> 
>> On 08/22, Julius Smith wrote:
>>> 
>>> Hey, thanks for posting.  I made a faust2octave test program
>>> (attached).  Everything looks good to me, assuming I guessed all the
>>> names right.
>> 
>> Great, thanks.
>> 
>> do you think it can live in filters.lib? If yes, then I think
>> "svf = environment" makes sense, so that you can use it like
>> 
>>process = fi.svf.lp(f,q);
>> 
>> See the code below. Note that this version differs a little bit, it uses
>> the second version described in that paper (see "algorithm using v1 to
>> compute v2").
>> 
>> iow
>> 
>>v2 = ic2eq + g*v1;  (2)
>> 
>> instead of
>> 
>>v2 = ic2eq + a2*ic1eq + a3*v3;  (1)
>> 
>> I think it makes more sense for faust because it is simpler, and because
>> quite possibly faust will turn (2) into (1) after aterm/mterm normalization
>> anyway.
>> 
>> I even verified that "all pass" generates the same code with this change.
>> 
>> Oleg.
>> 
>> ---
>> svf = environment {
>>svf(T,F,Q,G) = tick ~ (_,_) : !,!,_,_,_ : si.dot(3, mix)
>>with {
>>a1 = 1/(1 + g*(g + k));
>>a2 = g*a1;
>> 
>>tick(ic1eq, ic2eq, v0) =
>>2*v1 - ic1eq,
>>2*v2 - ic2eq,
>>v0, v1, v2
>>with {
>>v1 = a1*ic1eq + a2*(v0 - ic2eq);
>>v2 = ic2eq + g*v1;
>>};
>> 
>>A = pow(10.0, G / 40.0);
>> 
>>g = tan(F * ma.PI / ma.SR) : case {
>>(7) => /(sqrt(A));
>>(8) => *(sqrt(A));
>>(t) => _;
>>} (T);
>> 
>>k = case {
>>(6) => 1/(Q*A);
>>(t) => 1/Q;
>>} (T);
>> 
>>mix = case {
>>(0) => 0, 0, 1;
>>(1) => 0, 1, 0;
>>(2) => 1, -k, -1;
>>(3) => 1, -k, 0;
>>(4) => 1, -k, -2;
>>(5) => 1, -2*k, 0;
>>(6) => 1, k*(A*A - 1), 

Re: [Faudiostream-users] Performances of audio DSP code compiled in WebAssembly

[pdowling]

In my experience these amazing bitshifting fast* approxes are really quite bad 
if you are expecting to use them as plain ‘replacements’ in audio work. The 
Max/Gen environment implements some of them and for CPU and GPU video work they 
are fine, but in most audio applications one has to work against them, working 
out offsets and rescaling issues per use case. If you used any of the fast* 
series in the ‘filterBank.dsp’, for example, they would totally alter the 
tuning etc unless you re-coded around them.

Personally I have got much greater use out of the 'Ganssle Group’ stuff, based 
on "Computer Approximations" by John Hart, their versions here: 
http://www.ganssle.com/approx/sincos.cpp and here: 
http://www.ganssle.com/approx/approx.pdf

I am a great believer in approximations and it drives me mad when people are 
using 8th order Taylor series sines for LFO’s for example. However, in 
environments like Faust you surely have to empower the user with the ability to 
choose an approximation on the basis of empirical guidance (The Ganssle Group 
stuff mentioned above it perfect for this). I.E., with exact data for each 
approx type per different use case. For example in my own code I have sin/cos 
approxes for a pan abstraction, but different approxes for an xfade 
abstraction, based on how they behave at extremes or centers.

One application which goes some way to getting this right is Reaktor core. 
Every trig function is an approximation with selectable levels of accuracy 
settable by the user, in % or dB or time or whatever is appropriate for each 
specific scenario.

Just 2cents,
Pete .


On 25 Sep 2017, at 10:49, l...@grame.fr wrote:

> What is probably possible in the WebAssembly context would be to compile and 
> use this fastapprox library in wasm.
> 
> The thing is that the documentation is quite inexistant..., and looking at 
> the API I see for instance for cos : « fastcos »,  « fastercos » « 
> fastcosfull » « fastercosfull » ===> how are we supposed to choose which one 
> to use ?
> 
> Stéphane
> 
> 
>> Le 23 sept. 2017 à 09:42, Stéphane Letz  a écrit :
>> 
>> - yes pow is slow, but we still have to understand why this filterBank.dsp 
>> is so slower in the wasm context...
>> 
>> - that for this «  fastapprox » reference. I guess one way to switch between 
>> the standard math functions to specific ones would be to have a kind of « 
>> function mapping file » described somewhere that the compiler would use with 
>> a special -approx parameter or something. 
>> 
>> Stéphane
>> 
>>> Le 22 sept. 2017 à 18:49, Julius Smith  a écrit :
>>> 
>>> Ah, yes, pow is definitely way slow.  For occurrences in the inner
>>> loop (audio rate), I've taken to using the foreign function fastpow2()
>>> from fastapprox-0.3.2.tar.gz by Paul Mineiro (this might also be the
>>> one Kjetil Matheussen uses, who alerted me to the idea).  It
>>> sacrifices precision for speed, so if the Faust compiler is to use it,
>>> maybe there should be a new fastpow() primitive, and/or a compiler
>>> switch that says to use it wherever applicable at the audio sampling
>>> rate.  This was critical for getting GeoShred running on the iPad 2
>>> without dropouts!
>>> 
>>> - Julius
>>> 
>>> On Fri, Sep 22, 2017 at 12:21 AM, Stéphane Letz  wrote:
 Thanks Julius for the feedback. Several things:
 
 - it appears that this "5 times slower » case for filterBank.dsp is a bit 
 of a « pathological one » : since 1) Chrome which is usually the best is 
 significantly slower in this example, I don’t know why… 2) filterBank.dsp 
 uses a lot of pow (10, x) that the C++ backend  path rewrites (and I guess 
 optimize as...) as exp10(x) which probably explains the « C++ is better 
 than LLVM IR which does not do this rewriting ». I will add this remark in 
 the post… And doing this pow (10, x) ==>  exp10(x) rewrite rule is 
 probably easy to add in the Faust compiler
 
 - I’m currently only testing the Faust internal wasm backend. I should 
 also benchmark the Faust ==> C++ ==> Emscripten ==> wasm path, to see if 
 the Emscripten C++ ==> wasm  path is better and by how much compared to 
 our own Faust internal wasm backend.
 
 - I think we should avoid to go for a "use native primitives » strategy...
 
 - so I’m trying to get feedback from a french Mozilla developer, who works 
 in the compiler part. I hope he will give me some insights...
 
 Stéphane
 
 
> Le 22 sept. 2017 à 00:36, Julius Smith  a écrit :
> 
> Hi Stéphane,
> 
> Thanks for the interesting and informative report!  It appears that
> the big differentiator in performance is small audio feedback loops,
> such as used in filterbank.  If this is the case, then the simple
> one-pole filter, "pole(p) = + ~ *(p);" should show substantially the
> same performance differentials as