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

[Alexandre Torres Porres]

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

Yeah, I wasn't really aware of this, and it seems to settle the whole doubt
about why do we have to divide all time values by the overlap with [vd~].

I surely had an idea that it made sense, but not exactly why, and now that
you've explained how time in ms is converted internally to sample number it
makes sense.

But then, I kinda think this is a bug! Not only a [vd~] bug, but also
[vline~] and [phasor~] / [osc~] (regarding frequency).

I still need to come back about the need to multiply for the window size in
order to back down an overlap, and wether using delay~ lines instead of
that is the exact same thing or wether is just not perceptually
different... just wait...

or, in the meantime, can you explain why using a delay~ line is different
as you understand it? I mean, what problems does it generate and all?

thanks


2015-09-11 15:38 GMT-03:00 Alexandre Torres Porres <porres at gmail.com>:

> Thanks for the detailed explanation. It was very clear. A couple of other
> remarks, in 1) and 2) you have an output that is 4 times greater because
> they add up. If I'd used delread~ in 2) I'd have thought it was ok :) - it
> was weird to me why it wasn't working but now I get it.
>
> I had an idea why 1) worked, as I was saying from the beginning and we
> know well, it does the overlapping fine without discontinuities. So I was
> saying it dealt fine with overlapping, we can say it does it
> "automatically".
>
> Now, back to my saying how [vd~] and [tabread4~] behave differently.
> Attached I have an oscillator that was recorded into a buffer/array. Then
> I'm reading it from overlapping subpatches. So, now, there are
> discontinuities. They don't work the same way, and that was my point.
>
> I'm reading it with [tabplay~] and [tabread4~] driven by [vline~] (which
> has to be 4x faster for it to work).
>
> But then, as we also know, the deal is how [vline~] drives it. It'll
> generate a line without discontinuities and on the way out they'll be
> overlaped and added, and this ruins things. Same happens automatically in
> [tabplay~], no need for vline~ to ruin it.
>
> On the other hand, we can force [vline~] to overlap and make it alright.
>
> But the point is, [tabread4~] won't automatically do anything, unlike
> [vd~]. At least that is how I see it.
>
> But again, that is not what's most important about sorting out my patch,
> and now that this seems fine, I should get back to trying to sort that from
> the beginning all over again. Hopefully with more idea of what's going on.
>
> cheers
>
>
>
>
>
>
>
> 2015-09-11 7:18 GMT-03:00 Christof Ressi <christof.ressi at gmx.at>:
>
>> Luckily I can offer you (hopefully) clear explanations for all three
>> cases :-). Here we go:
>>
>> First some background information: In an subpatch with overlap 4, the
>> input and output buffers are overlapping, but internally the calculation of
>> the 4 windows happens sequentially. This is why a [phasor~] from a parent
>> patch will pass the subpatch unchanged (only the amplitude is four times
>> because of the summing), while a [phasor~] inside will look messed up after
>> the outlet. Ok, I know you know all this. But all this also applies to
>> delay lines. Now let's examine the three cases:
>>
>> 1) the [delwrite~] is in the parent patch. Let's suppose we have a
>> blocksize of 8 and overlap 4 (thus hopsize of 2). Because the [delwrite~]
>> is in the parent patch, it is just treated the same way as something coming
>> from the inlet. [vd~] reads the index 1 of the ringbuffer at the following
>> points of time:
>>
>> window 1: ----- 0    1   2    3    4     5     6    7
>> window 2: ----- 2    3   4    5    6     7     8    9
>> window 3: ----- 4    5   6    7    8    9    10   11
>> window 4: ----- 6    7   8    9   10  11   12  13
>>
>> Window2 reads 2 samples later than window1, window3 reads 2 samples later
>> than window2 and so on... If you overlap and sum it at the outlets, you end
>> up with everything aligned in the right way. This is exactly the reason why
>> you don't get any discontinuties.
>>
>> 2) both the [delwrite~] and [vd~] are in the subpatch. The delay line
>> inside the subpatch is written the following way:
>>
>> 0 1 2 3 4 5 6 7 (,) 2 3 4 5 6 7 8 9 (,) 4 5 6 7 8 9 10 11 (,) 6 7 8 9 10
>> 11 12 13 (,) 8 9 10 11 12 13 14 15 etc... where the numbers again represent
>> points of time in the input buffer.
>>
>> So the 4 windows are written sequentially into the delay line, because
>> internally window calculation happens sequentially (as I've mentioned
>> above). So there are indeed discontinuities which you have to take care of.
>> Now suppose you reed the delay line at index 0 for each window:
>> Because the delay line is constantly running, window 1 might start from
>> 0, window 2 then starts from 2 (because it's calculated after window1, so
>> in the meantime the ring buffer has moved by 8 samples), window3 from 4,
>> window4 from 6 etc... If you do the overlap, the delay line is again
>> preserved.
>> But what if you don't read at the ring buffer at index 0 for all windows?
>> Suppose [vd~] reads from index 7, than the output for window1 would be 6 7
>> 2 3 4 5 6 7, window2 would be 8 9 4 5 6 7 8 9, so the output is messed up!
>> Now if you think of it, the condition for preserving the delay line is
>> setting the index of [vd~] to a multiple of the hop size. Only then each
>> window will read a sequence from the buffer that is continious.
>> But wait, why didn't it work for you? It's just because in your patch
>> [vd~] was set to 0, but it can't read from index 0, instead it will read
>> from index 1, which screws everything up because it's not a multiple of the
>> hop size. I added sum message boxes where you can try out some good and
>> some bad numbers.
>> BTW: this behaviour of [delwrite~] inside an overlapping subpatch is also
>> the reason why you have to multiply the maximum buffer size by the overlap
>> factor, because it needs four times as much samples. Additionally this
>> explains why for a spectral delay, the delay time must be a multiple of the
>> window size time and not the hop size time, because only that way
>> continuity is garanteed.
>>
>> 3) This is just as messed up as I predicted, because you're simply
>> 'reading along' the 'weird' delay line above. :-)
>>
>> Don't worry, it took me some time to figure this all out, because this is
>> nowhere documented explicitly, it just follows implicitely from the
>> behaviour of overlapping subpatches (which is also not documented properly
>> at all... the oversampling and sequential calculation should be mentioned
>> in the helpfile of [block~] at least --> possible bug fix?)
>>
>> Tell me if that makes sense to you. When I find some time I could make a
>> nice graphic visualizing these issues in a better way.
>>
>> Cheers
>>
>>
>>
>> *Gesendet:* Freitag, 11. September 2015 um 08:06 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: Re: Re: [PD] weird behavior of [vd~] in phave vocoder
>> (overlapping subpatches)
>> I had said
>>
>> "*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.*"
>>
>> And I was just wrong! I wasn't using a delay line in the same way you
>> were. I just confused.
>>
>> And the more I dig, the more my head hurts and the more confused I am...
>> I guess I'm back to square one...
>>
>> Or worse, I guess I have more doubts now than at first :)
>>
>> My first surprise was to see that if you had a delread~ in a parent patch
>> and a [vd~] into a subpatch with overlap is that it wouldn't generate
>> discontinuities... and I'm not sure why is that...
>>
>> Now, you say
>>
>> "*Having [delwrite~] and [vd~] in the same overlapping subpatch (as you
>> would in a spectral delay) is also not a problem. But having the
>> [delwrite~] in the overlapping subpatch and the [vd~] outside will cause
>> weirdness :-).*"
>>
>> And I tested it. And hmm, I'm not sure what you mean, cause it only works
>> when you have a delread~ in a parent patch and a [vd~] into a subpatch
>> with overlap. I do have spectral delay patches and they just work, but if
>> you are listening to what comes out of both delread~ and vd~ in a subpatch,
>> it's just bad.
>>
>> Check my attached patch. I don't really get why it works in the first one
>> and it doesn't in the other two. Maybe this is a first step before
>> venturing into the other implications of all this mess ;)
>>
>> cheers
>>
>>
>>
>> 2015-09-10 22:53 GMT-03:00 Christof Ressi <christof.ressi at gmx.at>:
>>>
>>> Thanks for testing! I was suspecting that the difference might only be a
>>> very subtle one. But I'll check as well in next days. BTW: Your 'speed'
>>> control looks very cool, I'm gonna try this myself.
>>>
>>> I think I understand your questions better now, so I'll try to give some
>>> more concrete answers again:
>>>
>>> > 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~]
>>>
>>> I don't understand what you mean here. [osc~] and [phasor~] also
>>> interpret the overlap as oversampling, as do all objects which rely on time
>>> information (ms, hz). In fact, overlapping is achieved by oversampling. The
>>> reason why there won't be any discontinuities with [vd~] is because it is
>>> only a reading object like [tabread4~] and the delay line itself is not
>>> affected by the overlapping. You only have to be careful when dealing with
>>> milliseconds and different sample rates. Having [delwrite~] and [vd~] in
>>> the same overlapping subpatch (as you would in a spectral delay) is also
>>> not a problem. But having the [delwrite~] in the overlapping subpatch and
>>> the [vd~] outside will cause weirdness :-).
>>>
>>> There are actual two 'problems' with [phasor~], [osc~] and [vline~] in
>>> overlapping subpatches:
>>>
>>> 1) looking from the outside they seem to run too slowly because they
>>> rely on a higher sample rate within in the subpatch, but contrary to
>>> deliberate upsampling, e. g. [block~ 64 1 4], the output doesn't get
>>> downsampled at the outlets. So with overlap 4 the sample rate is 176400 Hz
>>> instead of 44100 Hz. That means a [phasor~] with a speed of 44100 Hz has a
>>> period of 4 samples. When it goes through the outlets it still has a period
>>> of 4 samples but now the sample rate is 44100 Hz and its 'speed' is
>>> therefore interpreted as only 11025 Hz. You also have to be careful with
>>> milliseconds because they also depend on the sample rate.
>>> (Oddly enough, [samplerate~] always outputs the global samplerate and
>>> not the actual rate the subpatch is running at. This is why there is the
>>> [iem_samplerate~] object in iemlib, which always gives the actual
>>> samplerate.)
>>>
>>> 2) they run continously across blocks but because of overlapping they
>>> are not phase aligned after the outlet.
>>>
>>> The oversampling is the only reason for all the corrections you had to
>>> do in you patch. I attached a copy where I made some comments. I hope this
>>> helps. If you have any more questions you can ask me.
>>>
>>> Cheers
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> *Gesendet:* Donnerstag, 10. September 2015 um 23:00 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: Re: [PD] weird behavior of [vd~] in phave vocoder
>>> (overlapping subpatches)
>>> naaah, yeah, they're different.. oops... but doesn't really make any
>>> difference perceptually... let me check it some more...
>>>
>>> 2015-09-10 17:49 GMT-03:00 Alexandre Torres Porres <porres at gmail.com>:
>>>>
>>>> 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/20150911/cf8f4213/attachment-0001.html>