>>> unlike [osc~], [vd~] will get the continuities between blocks right!"

> You can't really compare these two objects.

Sure I can :) i'll insist on it by the way. Again, [vd~] will not generate discontinuities with the overlaps, unlike other objects such as [osc~] and [phasor~]. Moreover, and as a logical result, it won't change the pitch because of the oversampling. It'll just work fine.

> [vd~] is actually the same thing as [tabread4~]

Oops, now I'm the one to say you can't compare them as equal. You see, [tabread~] needs to have an audio input to read through the array, but [vd~] is always "reading" the buffer at normal speed - so this makes them quite different. Since [tabread~] only react if some signal is feeding it, then it depends solely on that incoming signal; and thus the object who's outputting it, which could be [phasor~] or [vline~]. So it's more about which object who's driving it than itself.

When it comes to [vd~], the pithc shifting and time stretching also depends on the object that's driving the input, which could be again [phasor~] or [vline~] and need to deal with their behaviour.

> 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

yeah, sure, I've pointed it in my 1st message. I get that.

But as I asked, I don't really get how ALL parameters need to divided by 4, not only the [vline~] time, that is not clear yet. Sorry.

And by the way, my patch does also time stretching, so it's different than yours and is dealing with more parameters and issues than you. So you are addressing the [vline~] issue only (replaced by [phasor~] in your patch) - but that was the only parameter that I really understood anyway.

> When using [z~] to delay the back window simply by the

> fft hop size you don't have to care about window sizes

hmm, my problem was more why were my two patches different, the one with fft needed to care about it, but the other one didn't. I actually get why that thing needs to be done to properly phase align the windows.

So I was thinking and then thought that the other patch was working because it wasn't a phase vocoder, so the phase alignment was not important. But now that you say this and showed your patch, I can see that you need not worry if you are using a delay. And I was actually using a delay in my non fft patch.

In the end my patches were different but equivalent and now I get why. It's cool to know and learn that if you are using delay you don't need to care about it.

thanks

ps. I'm still curious on sorting out the behaviour of [vd~] though

2015-09-09 7:54 GMT-03:00 Christof Ressi <christof.ressi@gmx.at>:

Hi Alexandre,

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:

"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!"

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

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

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.

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!

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

Cheers, Christof

PS: Ignore the right half of [pd read-windows] with the two [tabread4~], this is only needed for the freeze effect.