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 <por...@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 <por...@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 <por...@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 >>> >> >> >
_______________________________________________ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list