[PD] weird behavior of [vd~] in phave vocoder (overlapping subpatches)

[Alexandre Torres Porres]

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.

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.

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).

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!

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...

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.

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...

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.

cheers
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20150907/a316582f/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Pvoc_delay.pd
Type: application/octet-stream
Size: 31653 bytes
Desc: not available
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20150907/a316582f/attachment-0001.obj>