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 christof.ressi@gmx.at:
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" porres@gmail.com *An:* "Christof Ressi" christof.ressi@gmx.at, "pd-list@lists.iem.at" < pd-list@lists.iem.at> *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 christof.ressi@gmx.at:
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" porres@gmail.com *An:* "pd-list@lists.iem.at" pd-list@lists.iem.at, "Christof Ressi" < christof.ressi@gmx.at> *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