[PD] ring buffer with an array

[Alexandre Torres Porres]

Hi there,

yeah, the way it was, I didn't see a way to not use [bang~], so I asked to
see if there was something new for me. But then I just started working with
buffers that are multiples of block size, which is fine. Check the Phase
Vocoder harmonizer I shared over here. I made it that way.

And you're right, [delwrite~] is the way out of this restrain. But the
phase vocoder was designed without it, with that sample location counter,
and I thought it had to be that way.

But then I saw that in the pdmtl phase vocoder abstraction they're using
delwrite~ instead of this counter! I just don't know yet how this new
structure actually works like. I'd have to think for a while in order to
adapt it with a delwrite~, or study the pdmtl patch a lot. I just didn't
have the time and tried to do it without it. But I mentioned I should try
and work on a new pvoc harmonizer with a delwrite~ later on.

The thing is that I'm working with this "super phase vocoder", with every
possibility, and not just a ring buffer. I also have a regular buffer for
recording that loops, scrubs and everything. So I made this multiples of
block size and I'm using [bang~]. I also load files into the buffer, as a
sampler... So I also needed to design a loop function for these files,
which I managed to pull off yesterday. Again, the normal way would be to
use something like phasor~, but I had to stick with the counter.

anyway, I do have to look into [delwrite~], it surely seems like a more
elegant way to solve this problem than with the way I did it. But try this
harmonizer I shared the other day.

Thanks a lot.
alex


===========

Hi Alex

On Sun, 2012-01-08 at 16:33 -0200, Alexandre Torres Porres wrote:
> Hi folks, I'm trying to implement a ring buffer with a table for a sampler
> patch based on an array.
>
> But I'm having the hardest time cause it always "clicks" when I start
> writing back on the beginning of the array.
>
> I made this simple test attached below using metro. But I'm figuring the
> flaw is because is not trivial at all to keep control data in sync with
> audio blocks

I see two flaws with the same cause in your patch.

Both objects, [tabwrite~ ] and [tabplay~ ], execute the incoming
messages at block boundaries. Thus, your patch suffers from the
limitation that you intended to avoid by not using [bang~ ]. It does not
matter whether you use [bang~ ] or not, either way you cannot start the
[tabwrite~ ] recording between blocks. It's not possible with the
current implementation to make it record exactly every 2000ms (unless
2000ms is an exact multiple of the block size).

The same applies to [tabplay~]. It does not take into account the
scheduling information of the incoming bang message and simply starts
playing at the next block start.

Because of above mentioned reasons I suggest to stick with [delwrite~ ]
and [delread~ ]. [delwrite~ ] is exactly what you are asking for: a ring
buffer. Is there a particular reason why you don't use those?

Roman
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20120110/691aa41d/attachment.htm>