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