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

[Alexandre Torres Porres]

>>> 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 at 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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20150910/7ddc5928/attachment.html>