So i managed to recreate a delay behaviour using tabwrite~ and tabread4~.

Tha main reason for using this objects instead of delread~/delwrite~ is that i need to "freeze" the buffer content from time to time (stop feeding it with new samples), and add chunks of new data into the array again after stopping some time ( haven't tried this yet, but it looks like this is possible by sending |start n( to tabwrite~ )

i've also seen a great solution for doing delays using tables by means of poke~, but i can't use this object as i need to be limited to vanilla for ofxpd integration purposes.

But now, i'm facing 2 problems:

1- in order to write and read simultaneoulsy the same table, the read header has to be slightly delayed to make sure it is reading data that has already been written. I accomplished this by adjusting phase of the phasor~ object with a message to the right inlet. I guess this is not the more accurate solution.... any hints on that?

2- I get a click at every end of the "loop"... how can i smooth that? maybe fading in/out at every start/end of the table writing?

I attach the actual patch, so you can see for yourself.

Thanks!

http://www.pdpatchrepo.info/hurleur/tabread_delay.pd

Hey,
I didn't took a look, but maybe it's because of the [tabread4~]. It needs some wraparound points at the end (& start) of the table. Does it click with [tabread~]??
..don't ask me why there is no "[tabread2~]". One can build it with [tabread~]s, but it's slow and I am generally missing some fundamental objects in pd-vanilla...
On the other side there are objects like [stripnote] or [change] that can be recreated with like 2 or 3 simple objects..

Still no reason to buy max/etc. ... so why is that?!?

@playmodes said:

1- in order to write and read simultaneoulsy the same table, the read header has to be slightly delayed to make sure it is reading data that has already been written.

You can fix this by forcing the execution order so that writing happens before reading. See 3.audio.examples -> G05.execution.order.pd.

2- I get a click at every end of the "loop"... how can i smooth that? maybe fading in/out at every start/end of the table writing?

There are a number of reasons why this might be happening, the main one being that [tabwrite~] snaps to block boundaries. You can try to fix it by making sure the table size is a multiple of the block size. You might also need to make a hacky version of [metro] using [bang~] and a counter to make sure the writing happens at the exact block you want it to.

The lack of guard points for the 4-point interpolation may contribute also, but there really isn't anything you can do about that.

@Flipp said:

..don't ask me why there is no "[tabread2~]". One can build it with [tabread~]s, but it's slow and I am generally missing some fundamental objects in pd-vanilla...

Linear interpolation isn't that great, anyway. It low-passes the signal more than 4-point interpolation does. At any rate, I've attached a version that hopefully isn't too slow.

http://www.pdpatchrepo.info/hurleur/tabread2~.pd

I think it's nice to have a selection of different types of interpolation. Sometimes you can get away with using something cheap without any real consequences.

Is there a version of vd~ that uses linear interpolation?

Thanks for your answers!

it's clean and working now... i will post results as soon it ends being a mess of boxes and cords...