How does one implement a circular buffer in Pd?

[tabwrite~] seems unequipped for the job, and [tabsend~] is for a specific purpose not directly related to circular buffers. [delwrite~] must be circular, but as it doesn't use an array, then you can't use the recorded signal freely (so e.g. a grain delay effect would have to do some really fancy tap dancing).

The only thing I can think of is to make the array a multiple of the block size, and [bang( it exactly at the right time, every cycle. I'm not certain that Pd's timing objects can do this with sample accuracy...? At 44.1 kHz, a 65536-sample buffer is 1486.07709751 milliseconds. I can imagine that (single precision!) rounding error would eventually cause glitches.

hjh

@ddw_music Maybe use [expr~]? It can read and write arrays according to help.

Edit: nope, it won't write vector values

Edit2: but fexpr~ will.
circularBuffer.pd

@ddw_music [ipoke~] ........ https://forum.pdpatchrepo.info/topic/13234/tape-loop-effect/8 ..... but only 32-bit unless you compile it. There might well be some grateful souls if you do........ !!
David.

@ddw_music so you want a circular buffer you can pause writing to? Because if you don't need to pause writing then [delwrite~] is the way to go and if you do then [tabwrite~] is.

it might be helpful to know exactly what you need it for since as you say [delwrite~] is a circular buffer. If you want to pause writing then you might just need [cyclone/poke~] with a [phasor~]
@whale-av I have compiled a 64-bit [ipoke~] for osx (tho I think this case can use regular [poke~])

[cyclone/poke~] looks like it will suffice. If you are recording at sample rate, then there's no need for interpolation.

(I'm assuming the "i" in ipoke~ means interpolation...? Unclear, as there's no description in the linked thread, and no readme in the zip.)

@seb-harmonik.ar

Because if you don't need to pause writing then [delwrite~] is the way to go and if you do then [tabwrite~] is.

Yes, [tabwrite~] can pause writing, but then how does it wrap around if you don't pause before the end? AFAICS there is no reliable way to make it do that.

it might be helpful to know exactly what you need it for since as you say [delwrite~] is a circular buffer.

Suppose you want to pull a grain from a delay buffer, but at 1.5x speed.

If it's a regular array, this is easy.

If it's a delay buffer, where you don't have direct access to it and can only access "x ms ago," then you need to calculate the right rate of change in the delay time to feed to delread4~... which... right now I'm lazy and I'm not going to go grab a pencil and paper to work that out (especially since with poke~, I can just do it in a clear and logical way)... my typical annoyance with Pd: time spent figuring out how to work around a limitation in the core object set (or waiting for someone to tell me which external provides a core feature) is time not spent making a cool sound.

hjh

@ddw_music I think whichever's easiest depends on if you're (over)writing the circular buffer continuously or not. If you are then [vd~]/[delread4~] with some kind of [samphold~] & [phasor~] combo to keep playing the same grain might be easier than managing your own but maybe the case is specific enough that it's worth making your own delay line that can pause writing.

but then how does it wrap around if you don't pause before the end? AFAICS there is no reliable way to make it do that.

you would have to make sure the array is a multiple of 64 samples and schedule the [tabwrite~] to start the next pass using message-rate (probably [delay]). granted, it might be far messier than the [poke~] object solution. But that would be the vanilla way to do it, and it may be more efficient since you don't have to provide your own [phasor~] (and things may be vectorized better by the compiler).
going that route might be more complicated in coordinating the exact delay time when stopping recording anyways though. (bc signal/message rate interaction).
But the thing about pausing writing is that when you move off of that grain the next time frame won't be available yet, the stuff in the array will be behind by however long you were playing that grain for, so you would have to wait for the entire array to fill up again in order to guarantee consistency in delay time.

What we really need is an object like max/msp's [stutter~] (which copies from a delay-line to another play buffer) with interpolation. I've been meaning to get to making a near-clone..

it may be possible to somehow do the same thing that [stutter~] does with complicated logic, but keeping track of what needs to be played from the delay line vs. what's already been copied to the play buffer (and therefore which should be read from for any given sample) would be even more of a headache in pd than it would be in c imo.

Yes, [tabwrite~] can pause writing, but then how does it wrap around if you don't pause before the end? AFAICS there is no reliable way to make it do that.

I'm still not sure what you're after:

1. write $tabsize samples to an array starting at $offset and wrapping around the end as necessary (could probably be done by adding a second arg to the start method of tabwrite~)
2. write $arbitrary number of samples to an array starting at $offset and wrapping around the end as necessary (similar to above)
3. continuously write blocks to an array, incrementing the offset of the next block and wrapping around the end when necessary (probably need a different class for this)