[PD] Phase Vocoder issues

[Alexandre Torres Porres]

Hi there, well, I checked back on the book, and the original example, and I
see that the phase lock works by checking the neighboring amplitudes of the
back window. So, although it sounds the same on the sound example I tried.
I can see that it is a different process, and that you need to normalize it
first so you have the amplitudes of back window intact.

Guess that what's left is the issue about the time for [line~], and this
new way I did with [expr~] to operate on zero values.

Cheers


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

> 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/31040ecd/attachment.htm>