> 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/
_______________________________________________
Faudiostream-users mailing list
Faudiostream-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/faudiostream-users
