<html><head></head><body><div style="font-family: Verdana;font-size: 12.0px;"><div>Hi Alexandre,</div>
<div> </div>
<div>I'm new on this list, but I think I can help you on this because recently I tried to do the same thing. I can't fully test your patch because I'm missing the cyclone library (and don't bother to install it :-p). I try to give an answer to the following questions:</div>
<div> </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> </div>
<div>You can't really compare these two objects. [vd~] is actually the same thing as [tabread4~], only that it reads from a ring buffer rather from a table. So the critical thing is only which object you use as the input for [vd~]. You are using [vline~] whereas I'm using [phasor~]. Both are equivalent. For the reading index for [vd~] you have to divide by the overlap factor, because then you read less samples and therefore virtually slow the [vline~] down. In a subpatch with overlap 4 everything happens 4 times as fast because instead of only 1 block, 4 blocks have to be processed - in the same time!). My approach is to have a [phasor~] run from 0 to 1 (or 1 to 0) for every block so I have to multiply it's speed by four. Than I multiply the output by the windows size. Note that in my patch I get the second window one hop size behind by simply delaying it with [z~] whereas you've chosen to use a second [vd~] with a wrapping object. (I guess you're way actually saves some memory as you don't need a second delay line). </div>
<div> </div>
<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> </div>
<div>When you're transposing you're actually reading more samples for upwards pitchshifting and less samples for downwards pitchshifting. So you basically stretch or compress the window size. This means also that the time difference between two windows changes if you want them to be phase aligned. If the window gets larger, the time difference to the last window also gets larger and vice verca. You might be aware of this: The window in the back has to be phase aligned with the front window because you need it as a reference to calculate the difference from the actual phase of the previous output window.</div>
<div> </div>
<div>When using [z~] to delay the back window simply by the fft hop size you don't have to care about window sizes and time differences at all. It is, however, also a bit incorrect for the first analysis window after a change of pitch so I might change it and try it your way!</div>
<div> </div>
<div>You can have a look at my solution and compare it to yours. From what I've seen both work the same way though I couldn't test your patch. However, I think that my patch could be conceptually easier to understand, but I might be wrong :-).</div>
<div> </div>
<div>Cheers, Christof</div>
<div> </div>
<div>PS: Ignore the right half of [pd read-windows] with the two [tabread4~], this is only needed for the freeze effect.</div>
</div></div></body></html>