Forums > MaxMSP

recording in a buffer which size grows as the recording lasts


March 11, 2013 | 5:12 pm

Hello,

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.


MIB
March 11, 2013 | 5:18 pm

sfrecord~???

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.


MIB
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:

M

– 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.
http://cycling74.com/forums/topic.php?id=23259
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

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?

traditionally, writing to disk has always been slower than RAM(RAM is volatile memory an application(like Max when you create a buffer~ with a certain size) creates for immediate access while its running). but i wonder these days what the real difference is if you have a solid-state-hard-drive(these are much faster than the older ‘disk’ style; now a chip similar to RAM).
to reduce latency as much as possible, you’d want a write-operation that would start/write sample-accurate anyways(in the audio thread; sfrecord~ can only start/stop with event-based toggle). so using buffer~ with a sample-accurate controlled write(like poke~ or within gen~) would be fastest and most accurate. drawback of RAM is that there’s a much smaller limit than on your hard drive(and Max might need RAM for other things). but then again, if your comp has 2-4GB of RAM, there’s quite a bit you can do("it is estimated that one minute of stereo audio at 16-bit 44.1 kHz has a file size of about 10.5 megabytes" <-i found that on the internet real quick, didn’t actually do the calculation myself :p so i guess that might be 21 or so MB for Max’s 32-bit audio storage in buffer~). and you could tell buffer~ to write its contents to file when you’re done.

Edit: but i have no suggestion either way – it depends on whether you care you’re using a ‘toggle’ to start recording or not. if using a toggle or event-based control, then you’ll get latency anyways, so maybe sfrecord~ would be good enough and the hard-drive speeds these days are pretty fast(for both solid-state and disk style).

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

(should be fine as long as you don’t hear any audio probs, sfrecord~ is probably just writing/closing the file in a lower-priority thread where the visual UI stuff is also running, causing just the visual to get sluggish… i don’t have Live though so i’m not sure what the regular behavior is.)

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