How to create a persistent buffer/recording inside an M4L device?
I'm wanting to build a device that keeps its own persistent buffer internally such that you can record material to a file, and it stays there permanently until written over.
The paradigm is supposed to be like a handheld dictaphone thing where you can record snippets to a "tape" and it stays there permanently. So I want to be able to add small recordings here and there, and have it play back "old" bits too.
My thinking was to use [sfrecord~] + [sfplay~] inside a Max Project file, so that it would refer to a fixed duration file inside the /media folder, but this doesn't appear to work inside a M4L device.
I'm not interested in any interaction with Live, or "collect all" or anything like that, as I know that stuff can be really complicated (or impossible in some cases), but being able to do it via a [buffer~] would be even better/easier.
Does anyone know a way to do this? Even if using some kind of hacky work around like dumping all teh audio into a [coll] or something like that. I guess it would also be ok to have a separate .wav file "next" to the M4L device, but that doesn't always work with where people keep their project files and such.
Hi, what should always work is to write the wav into the user folder which exists on Windows and MacOs. Use a path starting with tilde. I think ~/documents exists on both OS.
Hmm. Is that "safe" to do? I guess it can have an internal "tape" that load it loads with by default, then writes/reads one like this thereafter.
You could check if your uniquely named file is already present and act accordingly. That location is safe afaik. But who knows if Apple has another security concern in latest Os versions.
Olsen‘s idea is what I would
do as well.
I am not live user. but Max accepts ~/Documents/myfile.wav
path on both mac & win
Your only problem could be rewriting of that file if it got loaded into sfplay~
I would use buffer~ based objects instead.
After new recording, message
crop $1, write ~/Documents/...
would do.
New recording would need buffer~ size set again to max
recording length
I'll give that a spin.
My idea is to keep it as a fixed-length buffer where each recording appends on before (assuming you don't "rewind") and just writes as it goes. I guess I would worry about potentially jamming things up if there's a lot of "write" messages in a row if the recording buffer is kind of big (say 30-40min of stereo audio), which is why I was thinking [sfrecord~] so you can just write as you go. I guess you can't record from an offset doing that though.
Sure it is possible to start recording from any buffer position, but it would need good bookkeeping of allready recorded takes.
Do you need to set markers to be able to
play each take ?
I did not know that sfrecord can append new recording to
allready recorded file ?
record start is allways rewriting the file, and without any warnning when full path is specified