Hello guys.

can we as a community come up with an efficient way of continuously updating an audio buffer. Rather than the method commonly used that is to simply overwrite the entire last buffer.

So what I mean is that we have a table of say a minute worth of samples, and, from fresh, it is constantly recording into that minute (until a minute has passed we have blank space in front) then once it reaches the end, it starts again at the beginning replacing the sample that was there exactly a minute ago.

The only way I can think of doing this is by splitting the 'minute buffer' into many smaller buffers, so they are dealt with in chunks (or blocks), like 60 one second each tables. Then have a system for recording into each table in time ([metro 1000]-_x[+ 1]?) and then either have a way of importing the data from every table (ordered correctly) into the larger minute table and have your player read from that, or have a pseudo buffer that is just the system of playing through the tables in order (or not, if you so wish).

but that doesn't give a very high resolution.

is there maybe a neater solution with [block~] that I'm simply over looking?_

why not just make a really long delay line with delwrite~ ??

i'm not sure how that compares for computational efficency with a table writing method though.

>>So what I mean is that we have a table of say a minute worth of samples, and, from fresh, it is constantly recording into that minute (until a minute has passed we have blank space in front) then once it reaches the end, it starts again at the beginning replacing the sample that was there exactly a minute ago.<<

that is basically what happens with delwrite~. however, the index point for each sample also changes as time passes. as long as you compensate for the delay in your calculations, then most things you can do to audio from a table, you should be able to do to a delayline as well.

when i wanted to create a stutter fx a while ago, i first used a delayline. but the problem is if u reduce the delaytime (to reduce the length of the looped sound) you will not be able to make it longer again, because the shorter audiomaterial fed back into the buffer overwrites the buffer... this might be a restriction of using a delay for some things.....
my pd skills a not good enough to find an elegant solution, but maybe the attached patch could be a beginning!? let me know what you think about that...

edit: damn it....... i'm afraid, i gave the phasor a wrong creation argument, should be 1 instead of 0...
attached the new patch!

http://www.pdpatchrepo.info/hurleur/buffer.zip

here's a delayline stutter.

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

Holy shit, that's a simple stutter approach! You know what kind of crazy math and [timer] configurations I've been doing on those delay lines? Apparently nothing a simple [phasor~] and [samphold~] can't handle. Nice patch, hardoff.

yeah i went through all those hoops last time this thread came up. not sure why i got it easy this time. maybe lack of sleep helps.

here's a bit more with pitch and reverse

http://www.pdpatchrepo.info/hurleur/delaylinestutter-fx.pd

note that if you don't hit reset within the buffer time of 60seconds, the playback position will reset. however, for usual applications, i think 60 sec would be more than enough.

wow, cool and simple patch. but this only works well because of the long buffersize of a minute. that's the reason, why the read position resets after a minute.

yes. well my assumption was that for normal applications, you would reset the stutter far more often than that.

if you adjust teh length of the delayline it could go as long as you want.

as long as my machines memory reaches.......

edit: what i just wanted to say is, that there are still some advantages of having one buffer u can write in and read out as you want to, and i could imagine that it could be possible to get something like this to work in pd with an array. my attempt was to use an array and if you want to read it out immediately you could use a delay of one block size to start tabread. still there are clicks sometimes, but not really disturbing most of the time.

Good stuff everyone,

In toxonic's patch you can scrub back and forth through the input (that was the goal I was aiming for) by playing with the phase of the Phasor~ however the clicking that is incurred by changing phase sounds like an artifact, and not simply a click of an non-smooth waveform. Could the hamming window help here? (i wouldn't know how to implement it). Also the index position changes over time. Could that defeated by some kind of maths between phase of player and a phasor~ going in reverse, then subtracting the two, or something?

Speaking of poor maths,

last night I managed to get a buffer to read in continuously, like a delay line, and without the index changing (the big goal I was hoping for!) In this patch however, I've set it to a second's length, so that playback can be nearly instant and check-able. it doesn't sound good. like there's downsampling going on. you can see in the table that there are chunks of samples simply missing, but evenly spaced!

the buffer is at 44, so that one block gets processed exactly every millisecond, meaning i can use a [metro 1] to jump through the table and write, every individual block. but perhaps my maths is wrong somewhere. and it no work ((

If any genius can help me figure it out, let's do it!!

either way, playing with the values makes some fantastic sounds!

http://www.pdpatchrepo.info/hurleur/minute-buffer.pd

i just took a short look at your patch (i'm at work... ...) but i don't really know, if it's possible to use blocksize of 44, as far as i know the blocksize hast to be a power of 2 or somethin'?

yeah, but 2 goes into 44, though doesn't it.

I'd love some others to work on it for experimental purposes... i.e. not to achieve the initial desire because... needless to say, I have fulfilled my initial desire, and seen it for all it's glory!

Working brilliantly, with the 60 tables approach, looky in this thread for the patch: http://puredata.hurleur.com/viewtopic.php?pid=13458#p13458

@arif said:

yeah, but 2 goes into 44, though doesn't it.

I'd love some others to work on it for experimental purposes... i.e. not to achieve the initial desire because... needless to say, I have fulfilled my initial desire, and seen it for all it's glory!

Working brilliantly, with the 60 tables approach, looky in this thread for the patch: http://puredata.hurleur.com/viewtopic.php?pid=13458#p13458

but 44 is not a power of 2. 64 (the default blocksize) is 2 by the power of 6 (i hope that's spelled correctly) and 2 by the power of 5 would be 32.

btw, i guess i found out, how to use the patch i attached to my last post without these disturbing clicks. the trick is to use a bufferlenght that is exactly a multiple of the blocksize, for example 44096 and adjust the reading speed to this buffersize. this works pretty fine!
just take a listen to the attached patch... on my way, i built in a little scratching feature, for scratching audio inside the buffer....

http://www.pdpatchrepo.info/hurleur/buffer.zip

none of my zip expanders are happy expanding that shit.

i don't know the problem, i downloaded the archive again and tried it out, no problem here. compressed with 7z.
ok, let't give it one more try, i attached a new one - i made some slight modifications, so now, the reading position will be blocked while scratching with the "scratch" slider. i made this by using a [MouseState], hope this is the same on other resolutions... you'll have to maximize the patch window for proper function i guess.

edit: i tried this one too, unzipping the file is no problem on my machine.

http://www.pdpatchrepo.info/hurleur/buffer.zip

well, I just tried it with Ez7z (gui version of 7z) and no luck either.

I wonder if it's an OS thing. It opens fine on my Windows computer, but OSX hates it. I've found other archived files uploaded here have done the opposite.

Edit: It might be worth mentioning that I'm not trying very hard, though. Just using the Windows Extraction Wizard and Stuffit Expander.

ok, then just try the main patch and replace the sample with a loop of your choice, something melodic would be the best to find out, that there don't occur click sounds.

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