I've simplified the patch a lot so many things can be discarded. The window size shouldn't affect anything as the reading point in the delay line is fixed. Now I don't have [vline~] or anything, just a steady signal fed to [vd~], when we get close to the end of the delay line it just gets ruined, and that's all that there is to it. There's no flaw in the patch, nothing I didn't think of. It's really something very mysterious or perhaps a bug.
The patch is now simpler and also vanilla compatible. I tried it in the new Pd Vanilla 0.46-7 and I got the same weird behaviour. Check attachment please cheers 2015-09-21 14:12 GMT-03:00 Christof Ressi <[email protected]>: > Well, I just think you're hitting the limit of the delay line. Your window > size is 2048 samples, so inside the subpatch that's 2048/(44,1*4) = 11,6 > ms. But one window is one hop size (2,9 ms) behind, therefore 11,6 ms + 2,9 > ms = 14,5 ms and 1000 ms - 14,5 ms = 985,5 ms --> that's pretty much the > limit you were experiencing. Hope that helps. > > Cheers > *Gesendet:* Montag, 21. September 2015 um 18:27 Uhr > *Von:* "Alexandre Torres Porres" <[email protected]> > *An:* "Christof Ressi" <[email protected]>, "[email protected]" < > [email protected]> > *Betreff:* Re: PVoc patch "bug"? > my patch has a little issue, I'm saying the delay line is 60000 ms (this > is for the wrapping objects) when it's only 4000, but that is not a problem > for what I'm asking here as the wrapping doesn't influence anything. It's > just something weird that happens even without the wrapping. > > I wonder what's the principle you'd have for not using cyclone :) > > 2015-09-21 12:32 GMT-03:00 Christof Ressi <[email protected]>: >> >> Hey, >> >> the first thing I noticed: your [delwrite~] is at 4000 ms, but [s >> $0-buff_size] is still fed with 60000 ms... Is this on purpose? >> The second thing: Even if you got the range for [pong~] right, my guess >> is that this will create a sudden jump from the end of the delay line to >> the beginning. You'd need some kind of enveloping to mask the >> discontinuity. Maybe this won't be noticeable if you pass the 'problematic' >> area quickly, but might sound terrible if you stay there. In your case, >> however, it seems that the delay line is simply clipped since you've sent a >> wrong value to [pong~]. >> This is just some remote diagnostics, though, since I don't use any >> cyclone objects as a matter of principle :-D. >> >> Cheers >> >> PS: I didn't put this on the list on purpose, because it's only about a >> specific patch and not something more general. >> >> >> *Gesendet:* Montag, 21. September 2015 um 06:48 Uhr >> *Von:* "Alexandre Torres Porres" <[email protected]> >> *An:* "[email protected]" <[email protected]>, "Christof Ressi" < >> [email protected]> >> *Betreff:* PVoc patch "bug"? >> Hi there, still struggling with my circular buffer Phase Vocoder, now >> I've found an issue that has no apparent reason. >> >> Check the attached patch please >> >> the speed is 100% and pitcnh shift is "0", so the signal from vline~ >> stands still in one particular point in the buffer (read from [vd~]). >> >> buffer size is 4000 ms, into the PVoc subpatch is supposed to be "1000" >> for it does oversampling with the overlap of 4 (we've discussed this >> before). Anyway, I'm using sampstoms~ and mstosamps~ to convert in a way >> that works for the patch. >> >> The point is, when getting close to the end of the delay line, things get >> ruined for no reason! The end of the buffer is 1000 ms, not 4000 ms as >> pointed above. You can check my patch and see how that goes. >> >> If the reading point is at somewhere just after the buffer size less a >> window size plus a hop size (around 985 ms) things get bad. >> >> I can't find a reason for that in a million years. Please help >> >> thanks >> >
Pvoc-Vanilla.pd
Description: Binary data
_______________________________________________ [email protected] mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
