[4.63] resizing buffer while recording into it
this maybe a stupid quest:
can i dynamically resize a buffer while recording into it from adc?
instead of setting a specific buffer length upon patch load i would rather depend the used buffer length on the length of pressing a record button, to save RAM initially, or to allow for any buffer length needed.
how would i approach this best, preferrably without interrupting reading from a buffer, that is currently as well being recorded into?
thank you very much for any hint!
Resizing a buffer~ automatically clears the buffer~ no matter what. You may need to set up a system whereby the user sets the size prior to recording and then records(making sure to record only after resize). One way around this is to use two buffer~ objects and crossfade between them as necessary(while one is playing, the other is resized and then recorded into, when it is ready for playback, it’s faded into making the first buffer~ available for resizing/recording). Hope it helps.
…one more thing, the double-buffer~ method can either be achieved with one
single playback object or two: for all the playback objects,
groove~/play~/wave~/etc. there is the "set" message which allows you to set
which buffer~ is referred to, so if you don’t need an
uninterrupted-crossfade, you could use a very quick amp-envelope to ramp the
volume down, set the playback object to a different buffer~ and then ramp
the volume back up again.
Best of luck.
On Fri, Jan 2, 2009 at 8:39 PM, raja
> Resizing a buffer~ automatically clears the buffer~ no matter what. You may
> need to set up a system whereby the user sets the size prior to recording
> and then records(making sure to record only after resize). One way around
> this is to use two buffer~ objects and crossfade between them as
> necessary(while one is playing, the other is resized and then recorded into,
> when it is ready for playback, it’s faded into making the first buffer~
> available for resizing/recording). Hope it helps.
Thank you RabidRaja,
i had the double buffer method in mind also and found a thread hinting to a working method here:
Excuse me for not having checked properly before, thank you again,
Ah, cool, i hadn’t seen that thread before. Hey, in that case, you should also look into mxj, particularly [mxj buf.Op], might help with copying from one buffer~ to another:
check out Ben@C74‘s patch further down in the thread at #150335.
when i record into a recbuffer for later looping, then it would be crucial, that the loop starts running as soon as i stopped recording. This works as along as i record into the same buffer that i loop from. If i use a file to record in first, i’d have to open this file in a buffer dedicated to playback, which would take some milliseconds at least i suppose. someone recommended copying a buffer in RAM with peek~. didn’t try it yet, but the idea seems faster to me than having to open a file from disk.
happy new year, by the way, stay healthy and clever in 2009!
Quote: stefantiedje wrote on Fri, 09 January 2009 03:37
> jayrope schrieb:
> > i had the double buffer method in mind
> The solution I came up finally was to record first with sfrecord~ into a
> (temporary) soundfile and then load that into the buffer~.
> Its called recbuffer~. There is also a recbuffers~ which will record
> cyclic into multiple buffers…
This recbuffers~ looks like something i could use in a project im working on. I did a search of the forum/list but couldnt find it. just found recbuffer~ abd puffer~ abstractions. could you point me in the directiion of this download?