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
