tds2

I have a situation where I need to use the M4L device'Max Api Ctrl1LFO' controlling the azimuth in 'Max Api SendsXnodes', effectively creating an automated surround panner. The problem is it appears to constantly fill up Ableton's RAM usage until it crashes. This takes approx 12 hours on my current system (Live 8.4.1, OSX 10.8.3, 8Gb RAM) which, because it's the hub of an art installation that I would like to run for days without relaunching, is problematic.

I know that using live.remote~ as opposed to live.object should stop writing undo history, but I can't figure out where this is occurring.

Does anybody know what specifically I could do in this scenario to stop RAM usage building?

I know that using live.remote~ as opposed to live.object should stop writing undo history, but I can't figure out where this is occurring.
Does anybody know what specifically I could do in this scenario to stop RAM usage building?

how-to-stop-m4l-printing-undo-history

In Live 9.04 using max 6.13, the ’Max Api Ctrl1LFO’ device uses live.remote~, not live.object. I checked in Live 8.34 and the patching seems to be the same... Do you use [M4L.api.DeviceParameter] abstraction in your patch ? Did you have a look at this thread ? 

https://cycling74.com/forums/parameter-modulation-without-adding-to-undo-history/

In Live 9.04 using max 6.13, the ’Max Api Ctrl1LFO’ device uses live.remote~, not live.object. I checked in Live 8.34 and the patching seems to be the same... Do you use [M4L.api.DeviceParameter] abstraction in your patch ? Did you have a look at this thread ? https://cycling74.com/forums/parameter-modulation-without-adding-to-undo-history/


Hi Stephane - yes I did read that thread. I understand this conceptually, but I don't really have the knowledge to know how to get under the hood in the Max patch and alleviate the issue. Any ideas?

How to stop M4L printing undo history