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

[Alexandre Torres Porres]

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/0f78b327/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: bad-tabread.pd
Type: application/octet-stream
Size: 1443 bytes
Desc: not available
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20150911/0f78b327/attachment-0001.obj>