<div dir="ltr"><div style="font-size:12.8000001907349px"><font face="Verdana"><span style="font-size:12px">I had said</span></font></div><div style="font-size:12.8000001907349px"><font face="Verdana"><span style="font-size:12px"><br></span></font></div><div><font face="Verdana"><span style="font-size:12px">"</span><i><font size="1">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.</font></i></font></div><div><font face="Verdana" size="1"><i><br></i></font></div><div><font face="Verdana"><i><font size="1">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.</font></i><span style="font-size:12px">"</span></font></div><div><font face="Verdana"><span style="font-size:12px"><br></span></font></div><div><font face="Verdana"><span style="font-size:12px">And I was just wrong! I wasn't using a delay line in the same way you were. I just confused.</span></font></div><div><font face="Verdana"><span style="font-size:12px"><br></span></font></div><div><font face="Verdana"><span style="font-size:12px">And the more I dig, the more my head hurts and the more confused I am... I guess I'm back to square one...</span></font></div><div><font face="Verdana"><span style="font-size:12px"><br></span></font></div><div><font face="Verdana"><span style="font-size:12px">Or worse, I guess I have more doubts now than at first :)</span></font></div><div><font face="Verdana"><span style="font-size:12px"><br></span></font></div><div><font face="Verdana"><span style="font-size:12px">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...</span></font></div><div><font face="Verdana"><span style="font-size:12px"><br></span></font></div><div><font face="Verdana"><span style="font-size:12px">Now, you say</span></font></div><div><font face="Verdana"><span style="font-size:12px"><br></span></font></div><div><font face="Verdana"><span style="font-size:12px">"</span></font><span style="font-family:Verdana;font-size:12px"><i>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 :-).</i>"</span></div><div><span style="font-family:Verdana;font-size:12px"><br></span></div><div><span style="font-family:Verdana;font-size:12px">And I tested it. And hmm, I'm not sure what you mean, cause it only works when you </span><span style="font-family:Verdana;font-size:12px">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.</span></div><div><span style="font-family:Verdana;font-size:12px"><br></span></div><div><span style="font-family:Verdana;font-size:12px">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 ;)</span></div><div><span style="font-family:Verdana;font-size:12px"><br></span></div><div><span style="font-family:Verdana;font-size:12px">cheers</span></div><div><font face="Verdana"><span style="font-size:12px"><br></span></font></div><div><font face="Verdana"><span style="font-size:12px"><br></span></font></div></div><div class="gmail_extra"><br><div class="gmail_quote">2015-09-10 22:53 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>
<div>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.</div>
<div> </div>
<div>I think I understand your questions better now, so I'll try to give some more concrete answers again:</div><span class="">
<div> </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</div>
<div>> without discontinuities or pitch shifting because of interpreting the overlap as oversampling. That behaviour is special</div>
<div>> when compared to [osc~], [phasor~]</div>
<div> </div>
</span><div>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 :-).</div>
<div> </div>
<div>There are actual two 'problems' with [phasor~], [osc~] and [vline~] in overlapping subpatches:</div>
<div> </div>
<div>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.</div>
<div>(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.)</div>
<div> </div>
<div>2) they run continously across blocks but because of overlapping they are not phase aligned after the outlet.</div>
<div> </div>
<div>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.</div>
<div> </div>
<div>Cheers</div>
<div> </div>
<div> </div>
<div> </div>
<div> </div>
<div> </div>
<div> </div>
<div> </div>
<div> </div>
<div>
<div style="margin:10.0px 5.0px 5.0px 10.0px;padding:10.0px 0 10.0px 10.0px;border-left:2.0px solid rgb(195,217,229)">
<div style="margin:0 0 10.0px 0"><b>Gesendet:</b> Donnerstag, 10. September 2015 um 23:00 Uhr<span class=""><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>><br>
</span><b>Betreff:</b> Re: Re: Re: [PD] weird behavior of [vd~] in phave vocoder (overlapping subpatches)</div><div><div class="h5">
<div>
<div>naaah, yeah, they're different.. oops... but doesn't really make any difference perceptually... let me check it some more...</div>
<div class="gmail_extra">
<div class="gmail_quote">2015-09-10 17:49 GMT-03:00 Alexandre Torres Porres <span><<a>porres@gmail.com</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>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.
<div> </div>
<div><span><span style="font-family:Verdana;font-size:12.0px">> Delaying the back window [z~] is a rather lazy trick and it won't</span></span></div>
<div><span><span style="font-family:Verdana;font-size:12.0px">> give accurate results each time you change the pitch shifting </span></span></div>
<div><span><span style="font-family:Verdana;font-size:12.0px">> factor, but after one fft-window it settles. The question is if you </span></span></div>
<div><span><span style="font-family:Verdana;font-size:12.0px">> can actually here this error. When I find some time I'll make a </span></span></div>
<div><span><span style="font-family:Verdana;font-size:12.0px">> comparison between our both solutions.</span></span></div>
<div> </div>
<div><span style="font-family:Verdana;font-size:12.0px">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.</span></div>
<div> </div>
<div><span style="font-family:Verdana;font-size:12.0px">Lets sort this out ;)</span></div>
<div> </div>
<div><span style="font-family:Verdana;font-size:12.0px">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~].</span></div>
<div> </div>
<div><span style="font-family:Verdana;font-size:12.0px">cheers</span></div>
</div>
<div>
<div>
<div class="gmail_extra">
<div class="gmail_quote">2015-09-10 14:23 GMT-03:00 Christof Ressi <span><<a>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>
<div>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...<br>
</div>
<div>Cheers</div>
<div>
<div style="margin:10.0px 5.0px 5.0px 10.0px;padding:10.0px 0 10.0px 10.0px;border-left:2.0px solid rgb(195,217,229)">
<div style="margin:0 0 10.0px 0"><b>Gesendet:</b> Donnerstag, 10. September 2015 um 18:10 Uhr<br>
<span><b>Von:</b> "Alexandre Torres Porres" <<a>porres@gmail.com</a>><br>
<b>An:</b> "Christof Ressi" <<a>christof.ressi@gmx.at</a>><br>
<b>Cc:</b> Pd-List <<a>pd-list@lists.iem.at</a>></span><br>
<b>Betreff:</b> Re: Re: [PD] weird behavior of [vd~] in phave vocoder (overlapping subpatches)</div>
<div>
<div>
<div>
<div>yeah, it'll consider the signal input is 0 so it'll output the corresponding index - which is "1" because of the interpolation.
<div> </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> </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> </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> </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> </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> </div>
<div>> <span style="font-family:Verdana;font-size:12.0px">For me its sometimes a trial and error game to find all </span></div>
<div><span style="font-family:Verdana;font-size:12.0px">> those parameters which have to be divided/multiplied </span></div>
<div><span style="font-family:Verdana;font-size:12.0px">> by the overlap factor. But after a while of thinking </span></div>
<div><span style="font-family:Verdana;font-size:12.0px">> everything turns out to make sense.</span></div>
<div> </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> </div>
<div>> <span style="font-family:Verdana;font-size:12.0px">Delaying the back window [z~] is a rather lazy trick and</span></div>
<div><span style="font-family:Verdana;font-size:12.0px">> it won't give accurate results each time you change the</span></div>
<div><span style="font-family:Verdana;font-size:12.0px">> pitch shifting factor,</span></div>
<div> </div>
<div>that's important to note, and that's why miller's patch may not have been using this procedure.</div>
<div> </div>
<div>thanks</div>
<div> </div>
</div>
<div class="gmail_extra">
<div class="gmail_quote">2015-09-10 6:39 GMT-03:00 Christof Ressi <span><<a>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>
<div><span>"<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></span></div>
<div><span> </span></div>
<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 style="margin:10.0px 5.0px 5.0px 10.0px;padding:10.0px 0 10.0px 10.0px;border-left:2.0px solid rgb(195,217,229)">
<div style="margin:0 0 10.0px 0"><b>Gesendet:</b> Donnerstag, 10. September 2015 um 07:51 Uhr<br>
<b>Von:</b> "Alexandre Torres Porres" <<a>porres@gmail.com</a>><br>
<b>An:</b> "Christof Ressi" <<a>christof.ressi@gmx.at</a>><br>
<b>Cc:</b> Pd-List <<a>pd-list@lists.iem.at</a>>, "Gerd Schuller" <<a>studio@gerdschuller.com</a>><br>
<b>Betreff:</b> Re: [PD] weird behavior of [vd~] in phave vocoder (overlapping subpatches)</div>
<div>
<div>
<div>
<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>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</blockquote>
</div>
</div>
</div>
</div>
</blockquote>
</div>
</div>
</div>
</div></div></div>
</div>
</div></div></div></blockquote></div><br></div>