Forums > MaxMSP

recording in a buffer which size grows as the recording lasts

March 11, 2013 | 5:12 pm


it’s all in the title.
I don’t know how to do this, and it’s a little bothering me ; the buffer~ seems too rigid with its size, especially when accessed through a record~. Can’t i, like, start a record~, let it flow, and when i want to stop it i press the stop button of the record~, well – the buffer stops to expand, and is full ? I know i can do this with sfrecord, but it’s not the same thing especially if you want to reuse on the fly your newly recorded sample.

March 11, 2013 | 5:18 pm


March 11, 2013 | 5:37 pm

yes, just as i said, i can do this with sfrecord, but it’s not in a buffer, it’s direct-to-disk, and the generated file is a little more complicated to access. I’ll use it if there is no other solution, but it’s not ideal.

March 11, 2013 | 5:48 pm

unless you create a buffer~ that has enough memory to hold the max amount of time you would ever want to record… no there isn’t a way. use sfrecord~, when you stop recording use the filename to load it into buffer~ if you need it in a buffer. It’s not overly complicated.

March 11, 2013 | 6:34 pm

Ok. Not overly complicated, yes, but…

March 11, 2013 | 8:21 pm

Here’s a patch someone posted to the forum a while back– it trims a buffer length to the amount of time you activate recording.

— Pasted Max Patch, click to expand. —
March 12, 2013 | 3:24 am

I’m not quie sure what you’re aiming for, but you could just use the endpoint of your record to set you max duration in a playback object:


— Pasted Max Patch, click to expand. —
March 12, 2013 | 10:11 am

@antialias and @mattyo : those don’t really help, as in both case the size of the buffer is fixed before recording has started. Sure there is a lot to do after, and you can as MIB said use a buffer long enough so that you never use more than its size. Maybe an expanding, non-initially-fixed allocation of RAM at a single adress is just not possible.

March 12, 2013 | 4:00 pm

See if the example posted in this thread satisfies you.
The example sets a maximum recording duration of one minute, but there’s no reason you couldn’t set a much longer time. 45 minutes of stereo audio (taking into account that Max stores the samples as 32-bit numbers) is still less than 1 GB of RAM.

MIB’s suggestion to record to disk and then load it into a buffer~ is entirely reasonable, and can be easily automated, too.

— Pasted Max Patch, click to expand. —
May 13, 2015 | 1:52 pm

Looks like I’m going to need to implement something along the lines of the patch posted by Chris. What I’m wondering is what downsides there might be to writing to disk instead of to RAM, in particular, would one anticipate a potential delay between the record command and the actual beginning of recording, resulting in files with a tiny bit clipped off the front?

May 13, 2015 | 7:10 pm

May 15, 2015 | 9:16 pm

Good information. Unfortunately for me the hard drive where I will be writing these files is not solid-state. So far in pursuing this, I have found that when the recording is ended and a 0 is sent to sfrecord~, Live freezes for a moment. This isn’t ideal but it may still work, as I’m assuming this pause is purely visual and doesn’t actually interfere with the audio or any other processing; there is no noticeable jump in disk usage, RAM or CPU according to Task Manager at those moments. Does this sound about right?

May 15, 2015 | 9:43 pm

May 15, 2015 | 9:47 pm

Ah, thanks for that insight. I will keep listening carefully, but so far I don’t hear any problems.

Viewing 14 posts - 1 through 14 (of 14 total)

Forums > MaxMSP