[PD] Phase Vocoder issues

[Alexandre Torres Porres]

oops, it went to the list as well :-)

nothing actually embarrassing, nevertheless, so please feel free to discuss
the issues here.

cheers and happy holidays to everyone


2011/12/14 Alexandre Torres Porres <porres at gmail.com>

> 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
> equally fine.
>
> 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
> phase.
>
> Anyway, I'm updating that into my computer music examples with Pd, and any
> remark you should have is welcome.
>
> Thanks
>
> Hope you have a well deserved holiday's season of rest and peace.
>
> alex
>
>
>
> 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.
>>
>> Thanks
>> Alex
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20111214/0ad6acc4/attachment-0001.htm>