[PD] Hilbert by fft; was: Re: On arrays

[Charles Henry]

>Yeah, I'm not getting much joy from that either :/
>But it's still instructive to follow your implementation from
>fft.  There is actually a [hilbert~] unit available, which is
>why I am interested.

I figured out why the error signal was wrong on the hilbert_test
patch.  I was computing the error between the original signal, when
the output was delayed from that by ~1024 samples.

So, now the error is computed in the right place, and you can see the
difference.

I also figured out there are some definite effects of the block size
on how well the patch performs on low frequencies.  I've modified the
transform to use an overlap factor of 8 which seems to help
(everything above 20 Hz looks pretty good anyway), and (the part of
this patch that was intended to demonstrate) when you mess with the
phase inlet of [osc~] you can see that the hilbert transform does in
fact trace the phase discontinuities very well.

I came back to this idea, because I wondered if I could make a phase
vocorder out of it somehow.  With the phase / amplitude decomposition,
you could differentiate the phase to get instantaneous frequency,
multiply by a signal (representing the frequency ratio to stretch by),
and integrate the result to get the new phase, [wrap~] it up (or not),
 feed it back to [cosine~] and multiply by amplitude

Chuck
-------------- next part --------------
A non-text attachment was scrubbed...
Name: hilbert_test.pd
Type: application/octet-stream
Size: 1345 bytes
Desc: not available
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20061101/e54e8da8/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: hilbert_by_fft.pd
Type: application/octet-stream
Size: 51109 bytes
Desc: not available
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20061101/e54e8da8/attachment-0001.obj>