<div dir="ltr">Dear list, long ago I made a live sampler where you can start recording into an array and right away start phase vocoding on the fly - based on the "I07" example, so I was using a regular buffer/array. So I wanted to make it run with a circular buffer, and once in january 2012, someone here on the list told me to try using [vd~]. Well, I never really could do it, and it's only these days that I was able to sit down and finally nail it. I made it happen, but I can't really understand it and I hope you can help me.<div><br></div><div>I have patches attached so it'll help point out what I say. In the same file I have a regular granular pitch shift + time stretch and the same patch adapted to use the phase vocoder "phase accumulation" procedure.<br><div><br></div><div>I know there are issues that come up with the way overlapping works in Pd. For example, if you are doing a pitch shifting with a granular engine using [vline~] to read the grains, you'll have to increase the reading speed of [vline~] times the overlapping. So, in an overlap of "4", time will have to be 4 times faster (so divide time in ms by 4).</div><div><br></div><div>Other issues related to overlapping besides this "oversampling" is that some objects won't make it right, they'll chop the blocks with discontinuities, such as the case with [osc~]. But as it turns out, unlike [osc~], [vd~] will get the continuities between blocks right!</div><div><br></div><div>So I'm reading grains out of a delay line with [vd~] using [vline~]. For a regular buffer/array I know I have to get the time of [vlaine~] faster, but with vd~] 'm having to divide EVERYTHING by the overlap number, that includes the starting point, the end point, and the difference in ms between the front and back FFT window...</div><div><br></div><div>It might have something to do with the way I described [vd~] works in an overlapping subpatch, but I just can't get it - it makes no sense to me.</div></div><div><br></div><div>And even more weirdly, in the Pvoc patch I have to multiply the difference between the front and back windows to the ratio of transposition. This is even crazier than the last issue, and I have no idea why that has to be this way... </div><div><br></div><div>So I have these two adaptations I had to make, divide by overlap and multiply by the ratio, they're marked with "*" in the phase vocoder subpatch, hopefully it'll be quite clear. Besides this, both patches I have attached are about the exact same.</div><div><br></div><div>cheers</div></div>