> How else would you test the accuracy? I like to look at the dB magnitude and phase (in degrees) of the frequency response. So feed 1-1' to analytic instead of a sinusoid. The ideal response is 0 dB for the magnitude at all frequencies, and 90 or -90 degrees for the phase, depending on whether the frequency is positive or negative.
If you do a "cd libraries && git checkout master && git pull" in your faust master-dev clone, you can also compare to fi.pospass(filterOrder). You appear to have four biquads in series for your filter, so filterOrder == 8 would be a reasonable comparison. - Julius On Fri, Jul 5, 2019 at 12:36 AM Dario Sanfilippo <sanfilippo.da...@gmail.com> wrote: > > With that, it's not looking great. I'm cascading two analytic filters feeding > the first one with the chirp and the second one with the imaginary part of > the first filter. Then I'm summing the real part of the first filter and the > imaginary part of the second one. Shouldn't they be shifted by 180 degrees? I > changed the octaves per second to .5 to having an even slower test signal. > > This is the error: > https://www.dropbox.com/s/xtqwvk4ar0daz8c/analytic_plot.png?dl=0. > > How else would you test the accuracy? > > Dario > > > On Fri, 5 Jul 2019 at 03:14, Julius Smith <j...@ccrma.stanford.edu> wrote: >> >> Thanks! A more complete test is to feed it a slow chirp: >> f0 = 20.0; >> fMax = 0.5 * ma.SR; >> octavesPerSecond = 1.0; >> fRatio = 2.0^(octavesPerSecond/ma.SR); >> chirpFreq = 1-1' : *(f0) : + ~ *(fRatio); >> freq = min(fMax, chirpFreq); >> process = os.osccos(freq) : analytic; >> >> On Thu, Jul 4, 2019 at 5:13 PM Dario Sanfilippo >> <sanfilippo.da...@gmail.com> wrote: >> > >> > Hello, everybody. >> > >> > Here's yet another design to obtain analytic signals, taken from Olli's >> > post: >> > https://dsp.stackexchange.com/questions/37411/iir-hilbert-transformer/59157#59157. >> > >> > analytic(x) = real, >> > >> > imaginary >> > >> > with { >> > >> > re_c = (0.47944111608296202665, 0.87624358989504858020, >> > 0.97660296916871658368, 0.99749940412203375040); >> > >> > im_c = (0.16177741706363166219, 0.73306690130335572242, >> > 0.94536301966806279840, 0.99060051416704042460); >> > >> > tf(c, y, x) = c*(x+y')-x''; >> > >> > real = mem(x) : seq(i, 4, tf(ba.take(i+1, re_c)) >> > >> > ~ _); >> > >> > imaginary = x : seq(i, 4, tf(ba.take(i+1, im_c)) >> > >> > ~ _); >> > >> > }; >> > >> > >> > process = os.osccos(1000) : analytic; >> > >> > >> > Attached the outputs plotted as coordinates. It is fairly close to a >> > circle, at least with a 1k cosine. Eventually, I'll try to make a >> > comparison between all the designs. >> > >> > Cheers, >> > Dario >> > >> > >> > >> > On Sun, 23 Jun 2019 at 23:52, Julius Smith <j...@ccrma.stanford.edu> wrote: >> >> >> >> > I interpreted your email as if the new fi.ssbf is always "better" than >> >> > hilbert = _ <: H(a1)', H(a2) with ... >> >> >> >> I did not mean to imply that. You can use whatever bandpass filter >> >> you want, and that choice should of course be adapted to your >> >> anticipated input signal(s). If you know the input is a sinusoid at a >> >> known frequency, for example, then you can get by (perfectly) with a >> >> quarter-cycle delay at that frequency. Many people use this >> >> approximation for narrowband signals (such as in microwave >> >> engineering). >> >> >> >> I would strongly object to the name "hilbert" as defined, however, >> >> because it has two outputs instead of one. >> >> >> >> - Julius >> >> >> >> On Sun, Jun 23, 2019 at 2:34 PM Julius Smith <j...@ccrma.stanford.edu> >> >> wrote: >> >> > >> >> > > Agreed, but I was talking about fi.hilbert. Ideally it should turn >> >> > > cos() into sin(), at least according to its name/documentation, not >> >> > > into sin/2. >> >> > >> >> > I suppose a name change such as "half_hilbert" could be helpful to >> >> > avoid confusing "engineering" and "mathematics" definitions of >> >> > "hilbert". However, I cannot think of a good name. >> >> > Instead, I suggest we move "hilbert" into a comment in the pospass() >> >> > doc (see latest filters.lib). >> >> > >> >> > As you pointed out earlier, no finite-order filter can be The Hilbert >> >> > Transform. Even being sampled in time makes that impossible. >> >> > Therefore, avoiding the name entirely makes good sense. However, note >> >> > that there are few complaints about "Fast Fourier Transform", which is >> >> > not the Fourier Transform, and FFTs are similarly (un)scaled according >> >> > to engineering principles (avoid gain terms until they are required in >> >> > the application). >> >> > >> >> > - Julius >> >> > >> >> > On Sun, Jun 23, 2019 at 8:30 AM Oleg Nesterov <o...@redhat.com> wrote: >> >> > > >> >> > > On 06/22, Julius Smith wrote: >> >> > > > >> >> > > > Maybe clearer now? See latest filter.lib. >> >> > > >> >> > > Thanks, the new doc matches my understanding ;) >> >> > > >> >> > > > I presently vote against a scaling by 2, but I am open to arguments. >> >> > > > Right now, pospass simply passes only positive frequencies, and >> >> > > > hilbert is the imaginary part of pospass. To me this is the >> >> > > > simplest >> >> > > > view. >> >> > > >> >> > > Agreed, but I was talking about fi.hilbert. Ideally it should turn >> >> > > cos() >> >> > > into sin(), at least according to its name/documentation, not into >> >> > > sin/2. >> >> > > >> >> > > > None of these filters is ideal. By considering lowpass, pospass, >> >> > > > hilbert, etc., in Faust, you are considering practical filters, >> >> > > > nothing ideal. >> >> > > >> >> > > Of course. But as for fi.hilbert, I simply can't imagine any practical >> >> > > usage of it... >> >> > > >> >> > > >> >> > > And in fact there was another reason why I was confused. I interpreted >> >> > > your email as if the new fi.ssbf is always "better" than >> >> > > >> >> > > hilbert = _ <: H(a1)', H(a2) with { >> >> > > a1 = 0.6923878, 0.9360654322959, 0.9882295226860 , >> >> > > 0.9987488452737; >> >> > > a2 = 0.4021921162426, 0.8561710882420, >> >> > > 0.9722909545651, 0.9952884791278; >> >> > > H_sect(a) = f ~ _ with { f(y, x) = a^2 * (x + y') - >> >> > > x''; }; >> >> > > H(as) = seq(i, outputs(as), H_sect(ba.take(i+1, as))); >> >> > > }; >> >> > > >> >> > > I showed to Dario, at least for frequency shifting. AFAICS, this is >> >> > > not >> >> > > necessarily true, this depends. Consider the naive implementations, >> >> > > >> >> > > freq_shift_yehar(f) = hilbert : *(os.oscrc(f)) - >> >> > > *(os.oscrs(f)); >> >> > > >> >> > > and >> >> > > >> >> > > freq_shift_ssbf(f) = fi.ssbf(8) : *(os.oscrc(f)) - >> >> > > *(os.oscrs(f)); >> >> > > >> >> > > iiuc the first one will work "better" unless the input frequency is >> >> > > "close" >> >> > > to SR/4. >> >> > > >> >> > > Right? >> >> > > >> >> > > Oleg. >> >> > > >> >> > > >> >> > >> >> > >> >> > -- >> >> > >> >> > Julius O. Smith III <j...@ccrma.stanford.edu> >> >> > Professor of Music and, by courtesy, Electrical Engineering >> >> > CCRMA, Stanford University >> >> > http://ccrma.stanford.edu/~jos/ >> >> >> >> >> >> >> >> -- >> >> >> >> Julius O. Smith III <j...@ccrma.stanford.edu> >> >> Professor of Music and, by courtesy, Electrical Engineering >> >> CCRMA, Stanford University >> >> http://ccrma.stanford.edu/~jos/ >> >> >> >> -- >> >> Julius O. Smith III <j...@ccrma.stanford.edu> >> Professor of Music and, by courtesy, Electrical Engineering >> CCRMA, Stanford University >> http://ccrma.stanford.edu/~jos/ -- Julius O. Smith III <j...@ccrma.stanford.edu> Professor of Music and, by courtesy, Electrical Engineering CCRMA, Stanford University http://ccrma.stanford.edu/~jos/ _______________________________________________ Faudiostream-users mailing list Faudiostream-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/faudiostream-users
