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