Jeff Thompson

I'm working on a patch that will run either in Max or as a standalone (depending on if one works better than the other) that will record audio continuously for one year. The patch will run on a dedicated computer and will basically just record audio (no signal processing), though it will use jit.uldl to periodically upload an html progress file for remote monitoring.

The patch will break up the recording into 1-hour chunks, something I've done before to record long performances with no problems. All my short-term tests seem just fine.

Has anyone had experience with this before? I seem to remember a post a few years ago about this but couldn't find it - the only thing I found was this post about send/receive (

https://cycling74.com/forums/memory-leak-in-receive-object)

Should there be some kind of built-in reset for patches that are meant to run continuously for a long time? If so, what?

As in the send/receive patch mentioned above, anything to avoid using? I plan to strip the patch of all number boxes, etc, though it needs a little of that to monitor progress.

I'm working on a patch that will run either in Max or as a standalone (depending on if one works better than the other) that will record audio continuously for one year.  The patch will run on a dedicated computer and will basically just record audio (no signal processing), though it will use jit.uldl to periodically upload an html progress file for remote monitoring.

The patch will break up the recording into 1-hour chunks, something I've done before to record long performances with no problems.  All my short-term tests seem just fine.

Has anyone had experience with this before?  I seem to remember a post a few years ago about this but couldn't find it - the only thing I found was this post about send/receive (https://cycling74.com/forums/memory-leak-in-receive-object) but not sure it applies.

Should there be some kind of built-in reset for patches that are meant to run continuously for a long time?  If so, what?

As in the send/receive patch mentioned above, anything to avoid using?  I plan to strip the patch of all number boxes, etc, though it needs a little of that to monitor progress.

problems-with-long-running-patches

one thing you should avoid is making a lot of different symbols ("strings") since these expand the internal max symbol lookup table and are a possible "memory leak"

still it is useful to restart it every now and then, maybe using something like Keep It Up (

still it is useful to restart it every now and then, maybe using something like Keep It Up (http://users.skynet.be/keepitup/)


Thanks Timo. Any idea if either prepend/append or sprintf are better than the other? I'm formatting a good bit for html and monitoring messages. Is there an internal Max symbol lookup table reset?

Keep It Up looks like an interesting solution - my hope is to avoid ever restarting since it will interrupt the audio recording, though I may run two computers side-by-side as backup and to allow periodic restarts.

I'm sure this varies by the complexity and specs of a patch, but any idea how often a restart might be needed? Once a week, month?

Thanks Timo.  Any idea if either prepend/append or sprintf are better than the other?  I'm formatting a good bit for html and monitoring messages.  Is there an internal Max symbol lookup table reset?

I'm sure this varies by the complexity and specs of a patch, but any idea how often a restart might be needed?  Once a week, month?


I don't know how to reset the symbol table other than restarting max,

btw, what you could do is having 2 record patches running on different instances of max (quite easy to do, just copy and rename the app file) and 5 minutes before nr 1 is done recording his our it starts patch nr 2 on the second instance of max (for example using command line commands with the [shell] object) which will record with 1 minute overlap or so. And patch nr 1 will close itself after it's done, patch 2 will start nr 1 again later etc

I don't know how to reset the symbol table other than restarting max, 

btw, what you could do is having 2 record patches running on different instances of max (quite easy to do, just copy and rename the app file) and 5 minutes before nr 1 is done recording his our it starts  patch nr 2 on the second instance of max (for example using command line commands with the [shell] object) which will record with 1 minute overlap or so. And patch nr 1 will close itself after it's done, patch 2 will start nr 1 again later etc


Problems with long-running patches?