I'm sorry, a couple of things are not working in my test. First of all, the reference signal would be different so I don't it's a good way to test it. Then it looks like the binary generated with faust2csvplot can output a limited number of samples: if I run it ./test_hilbert -n 1000000 > test_hilbert.csv, only about 2^16 samples are written to the file.
I guess that I could just use the chirp and plot the outputs of the analytic filter to see how much it deviates from a circle as the frequency increases. Dario <http://dariosanfilippo.tumblr.com> On Fri, 5 Jul 2019 at 09:35, 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/ >> >
_______________________________________________ Faudiostream-users mailing list Faudiostream-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/faudiostream-users
