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
