recording in a buffer which size grows as the recording lasts
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.
sfrecord~???
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.
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.
Ok. Not overly complicated, yes, but...
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.
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
@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.
See if the example posted in this thread satisfies you.https://cycling74.com/forums/automatic-buffer-cropping-after-recording
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.
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?
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?
Ah, thanks for that insight. I will keep listening carefully, but so far I don't hear any problems.