Forums > Max For Live

setting id from notifications triggers undo steps

January 18, 2013 | 4:50 pm

In this example i am attempting to observe the devices on the selected track. I have inserted a deferlow between the middle outlet of [live.path live_set view selected_track] to [live.observer devices].
The deferlow object is triggering an Undo step called ‘Change’ in the Undo History of Live whenever I select a new track, which is undesired, however when there is no deferlow object it doesn’t report the devices whenever I select a track due to the ‘Setting the ID cannot be triggered by notifications.
Is there any way around this?

– Pasted Max Patch, click to expand. –

January 19, 2013 | 7:34 pm

I recently came upon this issue, and have a solution (possibly a workaround, you decide)

The ‘change’ that is registered in Live’s undo history is in fact the ‘change of id’ that the live.observer object is observing, i.e. every time you send an ‘id x’ message to live.observer, an event is added to the undo history

You can prevent this by opening the inspector for live.observer and unchecking the ‘Use persistent Mapping’ option under the ‘live.observer’ tab. Without using persistant mapping, you can send ‘id x’ messages without generating entries in the undo history

The problem with this, however, is that you lose live.observer’s ‘persistant mapping’ functionality, i.e. the live.observer object won’t remember what it was observing if you close/reload your set…. In your example patch, however, this isn’t an issue as you are dynamically generating an ‘id x’ message from the live.path object when the patch loads.

Finally, the reason you are not seeing an undo event generated when the patch does not have the deferlow is that the ‘id x’ message is ignored by live.observer ( ‘Setting the ID cannot be triggered by notifications’), i.e. no undo event is generated because the ‘persistant id’ of the live.observer is not changed

Hope that makes sense/helps


Viewing 2 posts - 1 through 2 (of 2 total)