joshg567

I've been trying to use live.button objects in a M4L patch to MIDI map my foot controller to, such that I have control of Undo/Redo without my hands leaving my instrument.

However, I have found that for those commands in particular (I'm using M4L.api.Undo and M4L.api.Redo from 

http://www.samgreene.com/M4L-abstractions),

 which ultimately use live.object, each time I actually undo an action, changing the live.button (by using it) becomes the last undo-able editing action and with no corresponding Redo.

I've discovered that I can hide the live.button from automation through the inspector, which successfully keeps it from adding its changes to the Undo history, but unfortunately is no longer MIDI-mappable.

I've read that live.remote~ won't add to the editing history, but merely swapping that for live.object doesn't seem to work.

Is this matter truly impassable, or do I have a viable workaround to discover?

However, I have found that for those commands in particular (I'm using M4L.api.Undo and M4L.api.Redo from http://www.samgreene.com/M4L-abstractions), which ultimately use live.object, each time I actually undo an action, changing the live.button (by using it) becomes the last undo-able editing action and with no corresponding Redo.

Is this matter truly impassable, or do I have a viable workaround to discover?


live-button-tradeoff-midi-mappability-vs-not-adding-to-the-undo-history

How about getting the MIDI of your controller into the device via midiin in the track. You might need to change the controller to send notes so that you can get around the dreaded CC filter.

live.button tradeoff; MIDI mappability vs. not adding to the undo history