<div dir="ltr">yeah, it'll consider the signal input is 0 so it'll output the corresponding index - which is "1" because of the interpolation.<div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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).</div><div><br></div><div>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.</div><div><br></div><div>> <span style="font-family:Verdana;font-size:12px">For me its sometimes a trial and error game to find all </span></div><div><span style="font-family:Verdana;font-size:12px">> those parameters which have to be divided/multiplied </span></div><div><span style="font-family:Verdana;font-size:12px">> by the overlap factor. But after a while of thinking </span></div><div><span style="font-family:Verdana;font-size:12px">> everything turns out to make sense.</span></div><div><br></div><div>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.</div><div><br></div><div>> <span style="font-family:Verdana;font-size:12px">Delaying the back window [z~] is a rather lazy trick and</span></div><div><span style="font-family:Verdana;font-size:12px">> it won't give accurate results each time you change the</span></div><div><span style="font-family:Verdana;font-size:12px">> pitch shifting factor,</span></div><div><br></div><div>that's important to note, and that's why miller's patch may not have been using this procedure.</div><div><br></div><div>thanks</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">2015-09-10 6:39 GMT-03:00 Christof Ressi <span dir="ltr"><<a href="mailto:christof.ressi@gmx.at" target="_blank">christof.ressi@gmx.at</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div style="font-family:Verdana;font-size:12.0px"><div><span class="">
<div>"<span style="font-family:Verdana;font-size:12.0px">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."</span></div>
<div> </div>
</span><div><span style="font-family:Verdana;font-size:12.0px">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.) </span></div>
<div><span style="font-family:Verdana;font-size:12.0px">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 :-).</span></div>
<div> </div>
<div><span style="font-family:Verdana;font-size:12.0px">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~].</span></div>
<div> </div>
<div><span style="font-family:Verdana;font-size:12.0px">Please anyone correct me if I'm wrong on these points!</span></div>
<div> </div>
<div>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.</div>
<div>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.</div>
<div> </div>
<div>Cheers, Christof</div>
<div> </div>
<div> </div>
<div> </div>
<div>
<div name="quote" style="margin:10px 5px 5px 10px;padding:10px 0 10px 10px;border-left:2px solid #c3d9e5;word-wrap:break-word">
<div style="margin:0 0 10px 0"><b>Gesendet:</b> Donnerstag, 10. September 2015 um 07:51 Uhr<br>
<b>Von:</b> "Alexandre Torres Porres" <<a href="mailto:porres@gmail.com" target="_blank">porres@gmail.com</a>><br>
<b>An:</b> "Christof Ressi" <<a href="mailto:christof.ressi@gmx.at" target="_blank">christof.ressi@gmx.at</a>><br>
<b>Cc:</b> Pd-List <<a href="mailto:pd-list@lists.iem.at" target="_blank">pd-list@lists.iem.at</a>>, "Gerd Schuller" <<a href="mailto:studio@gerdschuller.com" target="_blank">studio@gerdschuller.com</a>><br>
<b>Betreff:</b> Re: [PD] weird behavior of [vd~] in phave vocoder (overlapping subpatches)</div><div><div class="h5">
<div name="quoted-content">
<div>
<div>>>> <span style="color:rgb(80,0,80);font-family:Verdana;font-size:12.0px">unlike [osc~], [vd~] will get the continuities between blocks right!"</span></div>
<div> </div>
> <span style="font-family:Verdana;font-size:12.0px">You can't really compare these two objects.</span>
<div> </div>
<div><span style="font-family:Verdana;font-size:12.0px">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.</span></div>
<div> </div>
<div><span style="font-family:Verdana;font-size:12.0px">> </span><span style="font-family:Verdana;font-size:12.0px">[vd~] is actually the same thing as [tabread4~]</span></div>
<div> </div>
<div><span style="font-family:Verdana;font-size:12.0px">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.</span></div>
<div> </div>
<div><span style="font-family:Verdana;font-size:12.0px">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.</span></div>
<div> </div>
<div><span style="font-family:Verdana;font-size:12.0px">> you have to divide by the overlap factor, because then</span></div>
<div><span style="font-family:Verdana;font-size:12.0px">> you read less samples and therefore virtually slow the</span></div>
<div><span style="font-family:Verdana;font-size:12.0px">> [vline~] down.</span><span style="font-family:Verdana;font-size:12.0px"> </span><span style="font-family:Verdana;font-size:12.0px">In a subpatch with overlap 4 everything </span></div>
<div><span style="font-family:Verdana;font-size:12.0px">> happens</span><span style="font-family:Verdana;font-size:12.0px"> 4 times as fast because instead of only 1 block</span></div>
<div><span style="font-family:Verdana;font-size:12.0px"> </span></div>
<div><span style="font-family:Verdana;font-size:12.0px">yeah, sure, I've pointed it in my 1st message. I get that.</span></div>
<div> </div>
<div><span style="font-family:Verdana;font-size:12.0px">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.</span></div>
<div> </div>
<div><span style="font-family:Verdana;font-size:12.0px">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.</span></div>
<div> </div>
<div><span style="font-family:Verdana;font-size:12.0px">> </span><span style="font-family:Verdana;font-size:12.0px">When using [z~] to delay the back window simply</span><span style="font-family:Verdana;font-size:12.0px"> by the</span></div>
<div><span style="font-family:Verdana;font-size:12.0px">> fft hop size you don't have to care about </span><span style="font-family:Verdana;font-size:12.0px"> window sizes</span><span style="font-family:Verdana;font-size:12.0px"> </span></div>
<div> </div>
<div><font face="Verdana"><span style="font-size:12.0px">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.</span></font></div>
<div> </div>
<div><font face="Verdana"><span style="font-size:12.0px">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.</span></font></div>
<div> </div>
<div><font face="Verdana"><span style="font-size:12.0px">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.</span></font></div>
<div> </div>
<div><font face="Verdana"><span style="font-size:12.0px">thanks</span></font></div>
<div> </div>
<div><font face="Verdana"><span style="font-size:12.0px">ps. I'm still curious on sorting out the behaviour of [vd~] though</span></font></div>
<div> </div>
<div> </div>
</div>
<div class="gmail_extra">
<div class="gmail_quote">2015-09-09 7:54 GMT-03:00 Christof Ressi <span><<a href="http://christof.ressi@gmx.at" target="_blank">christof.ressi@gmx.at</a>></span>:
<blockquote class="gmail_quote" style="margin:0 0 0 0.8ex;border-left:1.0px rgb(204,204,204) solid;padding-left:1.0ex">
<div>
<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><span> </span></div>
<div><span>"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!"</span></div>
<div><span> </span></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><span>"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..."</span></div>
<div><span> </span></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>
</div>
</blockquote>
</div>
</div>
</div>
</div></div></div>
</div>
</div></div></div>
</blockquote></div><br></div>