Matias

How does MaxForLive handle the undo history in Live? I made an "intelligent" controller for Lemur, (

 I noticed that if I'm using the controller for a bit, and I undo in Live, it undoes *everything* the controller has done. The MaxForLive device is utilizing live.object to cause changes within Live, so I thought any action should become a new instance in the undo stack. Is there any thing special that needs to be done to live.object to commit an action into the undo stack? Thank you for your help peeps :)

How does MaxForLive handle the undo history in Live?  I made an "intelligent" controller for Lemur, (https://cycling74.com/project/mixer/).  I noticed that if I'm using the controller for a bit, and I undo in Live, it undoes *everything* the controller has done.  The MaxForLive device is utilizing live.object to cause changes within Live, so I thought any action should become a new instance in the undo stack.  Is there any thing special that needs to be done to live.object to commit an action into the undo stack?  Thank you for your help peeps :)


undo-history

anyone? should I contact support for this one?

anyone?  should I contact support for this one?


hi. not sure I'm afraid, but I'd like to know also....

I don't get what the question is. Actions on objects through the live.object API interface are added to the undo stack in Live. You don't need to do anything special for this. Most people are trying NOT to have that happen, so they use live.remote~ in various places.

There is quite a lot of discussion about this in this forum.

Thank you for your response, and I apologize for my lack of clarity. It is true that something will be recorded into the undo history when I use live.object. The issue is that if many things are done to live.object without doing something else with the mouse / keyboard in between, all of the actions are consolidated into the same undo.

so in practice, if I'm using my MaxForLive device to make many changes to the Live project, when I hit undo, everything is undone. The only way to get things to go into "new" undos is if I use the MaxForLive device for one action and then I use the mouse / keyboard for the next action.

Thank you for your response, and I apologize for my lack of clarity.  It is true that something will be recorded into the undo history when I use live.object.  The issue is that if many things are done to live.object without doing something else with the mouse / keyboard in between, all of the actions are consolidated into the same undo.

so in practice, if I'm using my MaxForLive device to make many changes to the Live project, when I hit undo, everything is undone.  The only way to get things to go into "new" undos is if I use the MaxForLive device for one action and then I use the mouse / keyboard for the next action.


I have the opposite problem where introducing 

 will cause an event at every time the device does it's randomizing function. So if I have this on and do something else in live, I have to hit undo a bunch of times till I get whatever action I actually want to undo, as opposed to the device functions. This question in fact is an area of confusion and I don't think that should be minimized esp since two people already posted how they were confused about this.

I have the opposite problem where introducing M4L.bg.10.SteadyRandBeats will cause an event at every time the device does it's randomizing function. So if I have this on and do something else in live, I have to hit undo a bunch of times till I get whatever action I actually want to undo, as opposed to the device functions. This question in fact is an area of confusion and I don't think that should be minimized esp since two people already posted how they were confused about this.

I'm having a similar issue with a patch. Undo is clogging up the Ableton Undo feature... is there a solution?

7 years later andthis problem stil exists...l this problem still exists...

7 years later and this problem still exists.....

At 10 years old this thread might deserve a cake !

Haha I'll be back next year ;) 
At 10 years old this thread might deserve a cake !

I guess we can start cooking that cake... 

It's really frustrating... My MaxForLive patching is basically 90% of solving undo history related problems... the rest 10% is the actual device. 

There's a lot of inconsistencies like for example if I send an "automated and stored" dial a "set 0" message that's let's say has a current value of 1 It'll sucessfully set the dial to 0 without sending out it's value. 

However as soon as I press the undo button in Live the dial will send out the "New" 1 value it's been changed to.

Then if I press redo it'll send out 0... : ) 

And it's just one thing that drives me crazy... Honestly the current implementation is absolute garbage.

I guess we can start cooking that cake... 

It's really frustrating... My MaxForLive patching is basically 90% of solving undo history related problems... the rest 10% is the actual device. 

There's a lot of inconsistencies like for example if I send an "automated and stored" dial a "set 0" message that's let's say has a current value of 1 It'll sucessfully set the dial to 0 without sending out it's value. 

However as soon as I press the undo button in Live the dial will send out the "New" 1 value it's been changed to.
Then if I press redo it'll send out 0... : ) 

And it's just one thing that drives me crazy... Honestly the current implementation is absolute garbage.


One other thing that I can't get a good solution for: 

the {mousefilter] object creates an additional undo step if there's any parameter after it that's not hidden (Or a Live.object, basically anything that's change is stored.) 

For example I have a patch which is unusable if I don't filter out the main dial's output messages. 

But If I use mousefilter it'll create an additional undo step which makes the patch unusable again... 

(Without mousefilter both the main dials turn, and the live.object's change after it takes up only one undo step.) 

Also mousefilter doesn't work from push, or if the Dial's midi mapped. 

I tried the [t b stop] --> [ delay 300] method which is less elegant because it can let some messages through, but it at least works from push. But with the same undo history 2 step problem. 

One other thing that I can't get a good solution for: 

the {mousefilter] object creates an additional undo step if there's any parameter after it that's not hidden (Or a Live.object, basically anything that's change is stored.) 

For example I have a patch which is unusable if I don't filter out the main dial's output messages. 
But If I use mousefilter it'll create an additional undo step which makes the patch unusable again... 

(Without mousefilter both the main dials turn, and the live.object's change after it takes up only one undo step.) 

Also mousefilter doesn't work from push, or if the Dial's midi mapped. 
I tried the [t b stop] --> [ delay 300] method which is less elegant because it can let some messages through, but it at least works from push. But with the same undo history 2 step problem. 

Do  anyone have any recommendations? 

Happy birthday ! 

The cake is in the oven...

Undo History