[PD] Phase Vocoder issues
Alexandre Torres Porres
porres at gmail.com
Wed Dec 14 03:08:14 CET 2011
Hi there, how's everything?
I sent this other remark to the pd-list the other day, no replies, maybe I
should insist with you. It's about the time parameter for [line~], which
doesn't need to be that, and just seems to have to not be too slow, windows
and overlap will reconstruct it, and even if that parameter is ridiculously
fast, it doesn't matter.
Now I also found other issues on the implementation in I07; you perform a
normalization at a first stage on the previous FFT output. I thought about
it and assumed it's not necessary. So I took it out, and it still sounds
And on the normalizaion section, "salting" the signal with a small amount
(such as 1e-15) in the case of zeroes, prevents division by zero, and gives
a magnitude of 1, but will give you a phase shift that is not "zero". So I
thought of another way with [expr~] that outputs magnitude of 1 and 0
Anyway, I'm updating that into my computer music examples with Pd, and any
remark you should have is welcome.
Hope you have a well deserved holiday's season of rest and peace.
2011/12/11 Alexandre Torres Porres <porres at gmail.com>
> Hi there. I've been opening the guts of the phase vocoder patches for a
> while now, and rewriting them, having it in new forms, etc...
> And... today I had this doubr. You see, lets have the regular I07 example.
> Now, we feed [line~] objects with where to start and where to go in a time
> specified as the FFT analysis Hop size in ms.
> I was wondering if that wasn't just too fast. And why wasn't the time for
> [line~] the actual window size in ms. That is because I assumed this
> [line~] controlled somehow the speed playback we hear.
> So I put a number box and started messing around with it, making it a
> bigger time lenght and hoped to listen to some sound change (maybe speed),
> just for fun. To my surprise, nothing happened!!! That is until I reached
> two overlaps (1024 points instead of 512).
> So instead of making anything clearer than it was, it got pretty much more
> weird. I decreased the values until reaching a supidly small time inteval
> of micro ms, something like 2.26e-07, and it still worked!!!
> I now have the clear idea that this length in ms is not that important at
> all. But that it has to be fast just to make line output the audio so it
> gets in the FFT. If it takes to long (2 overlaps or longer) it ruins
> everything. But what really controls the thing is the time interval defined
> by the counter which is controlled by the speed parameter.
> [line~] needs to feed the [tabread4~] output at a rather free way.
> Anyway, some nerdy remark. I'd like to understand this better, and explain
> this better in my rewriting of the patches.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Pd-list