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@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
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@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@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
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@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@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@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
-
Alexandre Torres Porres