Sorry for all the noise; the app Numbers was only displaying a limited number of values in the file.
These are the plots with the frequency going up to ~2k, ~5k, and 10k: https://www.dropbox.com/s/oipdannk3e1vqs9/analytic_plot_chirp2244.png?dl=0 https://www.dropbox.com/s/b0ye9amaxbpoej6/analytic_plot_chirp5087.png?dl=0 https://www.dropbox.com/s/0ol7mq8sxt35ihy/analytic_plot_chirp10827.png?dl=0 It seems to be fine until about 2k and then it deviates quite a bit. Cheers, Dario On Fri, 5 Jul 2019 at 15:16, Dario Sanfilippo <sanfilippo.da...@gmail.com> wrote: > 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
