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
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
I'm sorry for the noise, but the tests below are wrong. I had to change the
SR limits to do some oversampling but then some code was not compiling. So
I changed it back and it looks like faust2csvplot is only working at
44.1KHz now, which is probably why the filters went unstable at CFs below
what
>
> Following this idea, would it be good to have guards in tables and delays to
> avoid seg_fault 11 when indexes are weird values such as NAN? INF doesn't
> seem to be a problem for delay values in delay lines. For example:
>
> import("stdfaust.lib");
> process = de.fdelay(16, del,
Hi, Julius.
Yes, I was a bit surprised to see NANs in the last case because I've read a
lot about how zero-delay feedback filters perform well for the entire
spectrum, but I guess it must only to true for first-order filters. I'll do
more testing later.
Ciao,
Dario
On Mon, 21 Dec 2020 at 04:47,
On Mon, 21 Dec 2020 at 11:55, Stéphane Letz wrote:
> Very interesting discussion ! (even if I do now follow all the details for
> now):
>
> - about the « singleprecision/doubleprecision/quadprecision » recent
> addition in the language, and about the use of ma.EPSILON (that is indeed
> defined
Very interesting discussion ! (even if I do now follow all the details for now):
- about the « singleprecision/doubleprecision/quadprecision » recent addition
in the language, and about the use of ma.EPSILON (that is indeed defined using
singleprecision/doubleprecision/quadprecision model).
Hi Dario,
Those numbers look good except for the NaNs in the last case.
- Julius
On Sun, Dec 20, 2020 at 7:12 PM Dario Sanfilippo
wrote:
> Hi, Julius and Oleg.
>
>
>> The question remains as to which filter form is more accurate.
>>
>> Another thing worth mentioning, by the way, is that
Thanks for the detective work!
I like the idea of setting the pole protection margin according to the
working precision.
The boldest choice would be 1.0 - machineEpsilon.
I think it was Stéphane who gave us ma.EPSILON to use in this kind of
situation (it arose fairly recently for fi.tau2pole's
>
> looks like tf2np() limits the reflection-coefficients too much...
> The patch below seems to make the things better.
>
> Forgot to mention, I ran these tests with -double.
>
> Oleg.
>
>
> diff --git a/filters.lib b/filters.lib
> index 5b276e3..b530a52 100644
> --- a/filters.lib
> +++
On 12/20, Dario Sanfilippo wrote:
>
> > --- a/filters.lib
> > +++ b/filters.lib
> > @@ -1004,7 +1004,7 @@ declare tf2np copyright "Copyright (C) 2003-2019 by
> > Julius O. Smith III > declare tf2np license "MIT-style STK-4.3 license";
> > tf2np(b0,b1,b2,a1,a2) = allpassnnlt(M,sv) :
On 12/20, Oleg Nesterov wrote:
>
> On 12/19, Julius Smith wrote:
> >
> > All we can conclude from this test is that tf2s and svf are closer to each
> > other than either is to tf2snp.
>
> Julius, I can't believe it but it seems that tf2snp is just wrong
> when cf is low ;)
>
> test1:
>
> F =
On 12/19, Julius Smith wrote:
>
> All we can conclude from this test is that tf2s and svf are closer to each
> other than either is to tf2snp.
Julius, I can't believe it but it seems that tf2snp is just wrong
when cf is low ;)
test1:
F = 20;
w1 = 2*ma.PI*F;
a1s =
In the C++ backend tan funciton is compiled in the polymorphic std::tan that
actually uses the tanf (float) or tan (double) or tanl (quad):
https://en.cppreference.com/w/cpp/numeric/math/tan
Same for the C backend, so I guess this is correct?
Stéphane
> Le 20 déc. 2020 à 00:05, Julius Smith
Yes, tf2snp takes the same coefficients as tf2s and simply uses a
normalized ladder in place of direct form.
Building on Oleg's test:
import("stdfaust.lib");
F = 20;
w1 = 2*ma.PI*F;
a1s = -2.0*cos((ma.PI)*-1.0 + ma.PI/4.0);
// c1 = no.noise <: fi.highpass(2, F) - fi.svf.hp(F, 1/sqrt(2)) : abs <:
On 12/19, Dario Sanfilippo wrote:
>
> I was following this text:
> http://www.willpirkle.com/Downloads/AN-4VirtualAnalogFilters.pdf.
Thanks! I will read it later... may be ;)
> Julius, would you have a function to calculate the coefficients for
> fi.tf2snp?
Julius will correct me, but I think
Hi, Oleg.
On Sat, 19 Dec 2020 at 18:58, Oleg Nesterov wrote:
> On 12/19, Dario Sanfilippo wrote:
> >
> > > And this probably means that Dario was right, and the problem was
> caused
> > > by quantisation.
> > >
> > > Because IIUC in theory (and unless you modulate HPFfreq) these 3
> filters
> >
> Le 19 déc. 2020 à 18:58, Oleg Nesterov a écrit :
>
> On 12/19, Dario Sanfilippo wrote:
>>
>>> And this probably means that Dario was right, and the problem was caused
>>> by quantisation.
>>>
>>> Because IIUC in theory (and unless you modulate HPFfreq) these 3 filters
>>>
>>>
On 12/19, Dario Sanfilippo wrote:
>
> > And this probably means that Dario was right, and the problem was caused
> > by quantisation.
> >
> > Because IIUC in theory (and unless you modulate HPFfreq) these 3 filters
> >
> > fi.highpass(2, f)
> > fi.svf.hp(f, 1/sqrt(2))
> >
Hi, Oleg. :-)
On Fri, 18 Dec 2020 at 19:10, Oleg Nesterov wrote:
> Hi Dario,
>
> this motivated me to look at your library again ;)
>
I hope you found a couple of good things, and please do let me know if you
see anything that can be improved or fixed.
>
> On 12/18, Alik Rustamoff wrote:
> >
On 12/19, Alik Rustamoff wrote:
>
> Today I tested all three. With last two svf filters I don't see any
> difference (I use ardour's built in plugin analyser), no noise.
> The noisy fi.highpass (the first one) becomes closer to them as cutoff
> freq goes higher, but still has different phase
> That definitely sounds like "numerical stress" when the cutoff frequency
goes very low.
To be more clear, the numerical stress occurs in direct form when the poles
get too close together, especially near the unit circle in the z plane.
On Sat, Dec 19, 2020 at 1:13 AM Julius Smith wrote:
>
Today I tested all three. With last two svf filters I don't see any
difference (I use ardour's built in plugin analyser), no noise.
The noisy fi.highpass (the first one) becomes closer to them as cutoff
freq goes higher, but still has different phase characteristics in lowest
part of it's
Hi Dario,
this motivated me to look at your library again ;)
On 12/18, Alik Rustamoff wrote:
>
> Hi, Dario, I, btw, ended up using blti filter from your edge of chaos
> library. Good collection. No noises just does the job.
Then I think that fi.svf.hp() should work equally well. Can you try it?
Hi, Dario, I, btw, ended up using blti filter from your edge of chaos
library. Good collection. No noises just does the job. About precision, I
use default settings by running faust2lv2 script (I guess that runs with
single precision)
пт, 18 дек. 2020 г., 14:26 Dario Sanfilippo :
> Hi, Alik.
>
Hi, Alik.
Other people will be able to give you a more exhaustive answer but it might
be caused by quantisation of the coefficients making the filter a bit
unstable. Are you working in double precision?
Even in single precision, the biquad filter
Hi,
when I use fi.highpass in the following example I get weird noise at the
output if when offset parameters are not 0 and fighpass frequency is less
than 70hz. Removing the highpass filter of raising cutoff freq removes the
noise. Should it be like that? what is the reason?
declare name
27 matches
Mail list logo
