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

[Alexandre Torres Porres]

yeah, I have to sit again with some time and figure it out, I should do
some tests to better understand how many objects behave. But, in the
meantime, lets talk about something important here.

> Delaying the back window [z~] is a rather lazy trick and it won't
> give accurate results each time you change the pitch shifting
> factor, but after one fft-window it settles. The question is if you
> can actually here this error. When I find some time I'll make a
> comparison between our both solutions.

Are you really sure about this? Cause I've been testing it and thinking
about it and, in my opinion, both are exactly the same thing, equally
equivalent, and I can't hear any difference as well.

Lets sort this out ;)

I think that the second delay makes it a simpler patch and easier to
understand. I'm using [cyclone/delay~] by the way, which works with samples
- must be the same thing as [z~].

cheers

2015-09-10 14:23 GMT-03:00 Christof Ressi <christof.ressi at gmx.at>:

> Hmmm, since we basically agree on all these things I was thinking if I
> missed a point, because I simply don't believe that [vd~] behaves
> differently than [tabread4~] and there is any unlogical or 'special'
> behaviour with [vd~] within an upsampled subpatch. Maybe one thing: The
> input of [vd~] is a time in milliseconds which is interpreted according to
> the actual sample rate (because internally the delay lines work on samples,
> of course). In that way it behaves like [phasor~], [vline~], [osc~]. So
> when you send 1000 ms to a [vd~] in a subpatch with overlap 4, the delay
> line will be read at sample 176400 (supposing the [delwrite~] is in a
> subpatch with sample rate 44100). This is not an issue if both the
> [delwrite~] and [vd~] are in the same subpatch. But if they are in
> subpatches with different sample rates you have to make some adjustments.
> If you're also aware of this behaviour than I don't know what else we
> could've missed...
>
> Cheers
> *Gesendet:* Donnerstag, 10. September 2015 um 18:10 Uhr
> *Von:* "Alexandre Torres Porres" <porres at gmail.com>
> *An:* "Christof Ressi" <christof.ressi at gmx.at>
> *Cc:* Pd-List <pd-list at lists.iem.at>
> *Betreff:* Re: Re: [PD] weird behavior of [vd~] in phave vocoder
> (overlapping subpatches)
> yeah, it'll consider the signal input is 0 so it'll output the
> corresponding index - which is "1" because of the interpolation.
>
> and yeah, I'm aware they're both buffer readers, delwrite~ / vd~ being a
> circular / ring buffer. And my point was this difference between them,
> where delay lines will always read/output at regular speed.
>
> But that is not the core of the discussion, and we actually agree on it,
> so I'm not sure what we're talking about here.
>
> My point was just that [vd~] acts in a special way when in an overlapping
> subpatch, and that is it'll output the audio without discontinuities or
> pitch shifting because of interpreting the overlap as oversampling. That
> behaviour is special when compared to [osc~], [phasor~] and I also tried a
> buffer reader like [tabplay~] and got "bad" results. They all don't work
> well in it, and so does not [vline~] by the way. There might be other
> relevant objects to test but I'm just not thinking about it. Nevertheless,
> I have the idea most will have problems, while some, like [vd~], will be be
> fine.
>
> The thing about [tabread~] is that it solely depends on external sources
> to read the buffers, while [vd~] doesn't, and that makes quite a practical
> difference in my opinion. The deal with [tabread~] is that the issue is
> more about what object is driving it and how it behaves (such as [vline~]
> and [phasor~], which don't behave well with overlapping subpatches).
>
> But again, not a relevant discussion. But I do feel like making more
> tests, I just don't know if there is a possible to test to check how the
> behaviour or [vd~] and [tabread4~] could relate between themselves.
>
> > For me its sometimes a trial and error game to find all
> > those parameters which have to be divided/multiplied
> > by the overlap factor. But after a while of thinking
> > everything turns out to make sense.
>
> yeah, it was trial and error, but I'm still not 100% sure how it makes
> sense... hence this thread :) - but I guess I'll keep thinking more about
> it.
>
> > Delaying the back window [z~] is a rather lazy trick and
> > it won't give accurate results each time you change the
> > pitch shifting factor,
>
> that's important to note, and that's why miller's patch may not have been
> using this procedure.
>
> thanks
>
>
> 2015-09-10 6:39 GMT-03:00 Christof Ressi <christof.ressi at gmx.at>:
>>
>> "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."
>>
>> Again, I insist that the behaviour of [tabread4~] and [vd~] is equivalent
>> ;-). When you don't feed any input to [tabread4~] it outputs the value at
>> index 1. Now try to think of a delay line as simply a table which content
>> is constantly updated at a time interval of 1/SR (SR = the actual sample
>> rate of the subpatch containing the [delwirte~]). If you don't send any
>> signal to [vd~], it behaves just as [tabread4~], only that the value at
>> index 1 always changes, so it only appears that [vd~] itself is reading
>> along a buffer. (Note that both objects can't read index 0 because of the
>> 4-point interpolation algorithm. So with [vd~] you will never get less than
>> a one sample delay.)
>> To make sloppy analogy:  [tabread4~] would be a band machine where the
>> tape itself stands still why the tape head can be freely moved, whereas
>> [vd~] would be one where the tape runs at a fixed speed and additionally
>> the tape head can be moved too. Well, I don't know if this makes sense :-).
>>
>> Since you took the word "reading" in quotation marks you might be aware
>> of all this. In that case the confusion might arise from the fact that you
>> have to consider the relation between the 'speed' of the delay line
>> (depending on the sample rate of the subpatch containing the [delwrite~])
>> and the 'speed' of the object providing the input for the [vd~].
>>
>> Please anyone correct me if I'm wrong on these points!
>>
>> For me its sometimes a trial and error game to find all those parameters
>> which have to be divided/multiplied by the overlap factor. But after a
>> while of thinking everything turns out to make sense.
>> Delaying the back window [z~] is a rather lazy trick and it won't give
>> accurate results each time you change the pitch shifting factor, but after
>> one fft-window it settles. The question is if you can actually here this
>> error. When I find some time I'll make a comparison between our both
>> solutions.
>>
>> Cheers, Christof
>>
>>
>>
>>
>> *Gesendet:* Donnerstag, 10. September 2015 um 07:51 Uhr
>> *Von:* "Alexandre Torres Porres" <porres at gmail.com>
>> *An:* "Christof Ressi" <christof.ressi at gmx.at>
>> *Cc:* Pd-List <pd-list at lists.iem.at>, "Gerd Schuller" <
>> studio at gerdschuller.com>
>> *Betreff:* Re: [PD] weird behavior of [vd~] in phave vocoder
>> (overlapping subpatches)
>> >>> 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/88b1d568/attachment-0001.html>