Parameter Modulation...without Adding to Undo History
Hi all,
So I've created a bunch of MaxForLive devices that modulate Live parameters in different ways. I use either live.remote~ or m4l.api.DeviceParameter to do the modulations. One thing that has been a real problem with both methods is the fact that all adjustments made to live parameters with these objects add adjustments to the undo history in Live.
Does anybody have a solution for this problem?
The two things I found that might be useful:
1. https://cycling74.com/forums/live-remote-and-track-mute
2. http://www.ableton.com/articles/buffer-shuffler-generates-lots-of-undo-steps
Many thanks,
Mike
hi mike.
[M4L.api.DeviceParameter] uses [live.object] exclusively. this means that every change will be written to the undo queue. you need to use [M4L.api.DeviceParameterRemote], which controls using the [live.remote~] object, which does not write to undo history. best way is to roll your own.
live.object == for single parameters, undo queue
live.remote~ == use for lfo's / crazy mangling - no undo history reported.
hth.
Thank you! That was what I needed.
For future users...
If you are still getting the same problem, do the following:
- use the device
- after the device has changed the value of some parameter, click "edit" in the Live window, (next to "file") and make sure some other parameter isn't getting save to the live history
- if it is, you'll see something like "Undo Change live.button"
- next, find that object in your max patch, right click and open the inspector
- find "Parameter Visibility" and set to "Hidden"
Thanks! This is really helpful.
Question on this - what if you have a live.numbox that you are automating to control something like DMX - you want the automation lanes in live, but don't want a million undos to appear in live everytime a parameter is automated - any way to avoid that? thanks!
As suggested, live.remote~ should do the trick.
@stephane - thanks for the reply - but i am not automating a live parameter - i am sending the automated value to a dmx object.
Something like this will do the magic for you and you will see all automated parameters in live but without undo history.
The only problem here is if you want to map it to another max device.
I still try to figure this out... :/
But what if you need to SEE the data that fills the automation lanes? Is there just no way to avoid filling the undo history? I tried live.remote~ and giannis's suggestion of using the pattr system, but both leave the lanes empty.
From what I can recall I fixed this issue using M4L.api.DeviceParameterRemote. Read its documentation.
It is the ONLY way of controlling automation in M4L without it getting written to undo and hangs everything :)
Correct - live.remote doesn't store undo history, live.object does - there's been a number of requests out for some time to allow updates via live.object to not store undo history (via some kind of option) but so far this is not possible..
i have the same issue
is it possible to set visibility to hidden and midi map this object ?
its not possible for me now.
thanks
Yes, it does work, just replace the sliders with live.slider and arm automation in live. simple as that :)
thanks for the answer,
but i use a live.button and i want to control this with a midi controller via ableton midi map without writing things in the undo history.
hmm dont work for me.
when i press that button i see "live.button" oder edit -> undo in ableton.
when i change it in inspector to "hidden" it works.
but i cant map it...
Ressurecting a thread here.
"Something like this will do the magic for you and you will see all automated parameters in live but without undo history. The only problem here is if you want to map it to another max device."
I Can't figure out how and where to patch the pattr object for it to not stack undos in the undo history.
as a warning to others and a plea to any cycling 74 people reading, I spent more than an hour today going through a large patcher step by step to figure out what was filling up live's undo history, and learned that even setting a live.object or live.observer's ID gets added. in what situation does that help or make any sense? the way i see it, undo is for substantive changes to your project, not incidental things like selecting a different track or clicking a UI panel. setting the id seems so clearly in the latter category that it never occurred to me to check and i wasted a lot of work. the observer case is especially confusing since it's literally incapable of modifying your live set :(
> the observer is ... literally incapable of modifying your live set
Not quite right I think.
Changing the observer ID changes its output and thus may modify the live set.
thanks for the reply.
I came to the same conclusion about the observer because I wanted to check the Browser And session states.
But what about the remote object?
[live.remote]
Did you checked it out?
I am still figuring out how to not get a massive amount of Undos
@salsa I don't normally use the remote but I did a quick test and it seems to work the same way
@broc sure, if you connect the output of live.observer to some other object that's capable of changing the set, then a change may result, but observer could just as easily be part of an internal process that you want to keep out of the end user's experience (at least i assumed it could)
i might be a little off topic but it seems that my only option would be to reverse engineer a Midi Remote Control script and control it via OSC with Lemur.
Well my goal is to control tracks and the live session, so using the basics of the APC 40 sounds like a good start.
Anyone ever tried that to control Ableton without getting tons of UNDOS
reverse engineer a Midi Remote Control script and control it via OSC with Lemur
that's a little over my head but good luck and i'd love to hear how it goes.
just don't get your hopes up too high because i don't think setting the IDs is the only source of my problem. even if i cut most of that out of the process, i still have a ton of undos coming from somewhere. i'm still working my way through, disabling one part at a time to see if it makes a difference. will let yall know if i learn anything useful.
so this is embarrassing, but my problem mostly disappeared and i have no idea why. i cut out this one chunk of code that shouldn't have made any difference, tested the device, and the same action that used to create like 100 undos now only creates one or two. i patched that chunk back in, tested it again, still just a couple undos.
i went back and checked that i wasn't hallucinating about changing the id. that does create an undo step for me when i test it by itself. i can't explain why it no longer does as part of my bigger program. i'm guessing the problem will come back at some point so maybe the timing of that will provide a clue
what are you trying to control within Live?
it's a program that controls different things depending on what device is selected in live, so it has to reconfigure itself (and set a lot of IDs) every time i select a different device, and that's when my undo history used to get flooded.
We are in 2021 and this is the worst thing in M4L, and Ableton never did anything about this ...
Have a patch that need to be automated and have lfo the undo history is no more usable.
Such a shame
Same problem here, undo history overflow when using M4L objects, including parameter enabled pattr system objects. It's a shame.. I can't publish devices that will avoid someone to use undo on his set..
…are we really 10 years after the original date of this post and Cycling 74 / Ableton have not introduced a standard way to avoid undo history flooding.
I purchased a handful of devices recently where all I want to do is have a generic MIDI CC controller with a couple knobs and faders and be able to control the volume, panning, and sends of the _currently selected_ track. Every single one of them are unusable due to undo history flooding.
this feels like an extremely bizarre feature gap in 2022.
Alas, same problem with a note trigger I need to MIDI map...
Also, happy 10 year anniversary this thread :D
I really think that the integration of m4l could be updated in a lot of ways ...
This one is in the top 5
Goddamn it. Part of me is glad this thread is still alive but otherwise it a shame that it is still isn’t fixed.
🤓
still waiting for tempo changes that don't fill up the undo... hurry up :)
Same here...
There’s a lot of upgrade that could be done in the implementation of max in live
like undo ….
we can say maxforlive is not a priority for cycling is a shame
still waiting for tempo changes that don't fill up the undo... hurry up :)
You can control live_set -> mastertrack -> mixer -> song_tempo with a live.remote~. But you still have these undo steps when setting the id of a live.remote which is indeed annoying. Also there's inconsistency because setting id of live.object creates an undo step but creating a live object in JS does not add one..
@11olsen maybe you could check my device : https://ctrlz.gumroad.com/l/tempodivider
what's wrong with it ? Like I wrote I also don't see a way to change tempo without undo step creation until we can silently change ids of live.remote~
It was just a sharing pacth, all the problem remains
Actually setting the id of live.remote~ doesn't create an undo step, only resetting with "id 0" creates one. So there might be a way..
Tom gives a very good explanation of how to fix this:
https://www.youtube.com/watch?v=fN5ouATKvPk
Hmm i think that's what most people already know..
Yep this not a solution
I noticed that you can avoid the undo steps for just setting the ids if you switch persistent mapping off.
Works for .remote~ .observer and .object. The downside is obviously that the objects loose the id when the device is moved to another track or you save and reload the LiveSet.
So I have experimented a lot today with various workarounds to "solve" the annoying problem of automated max UI elements writing into undo history and the key is to have an extra "automation" object (numbox, slider etc.) that is automation enabled and then with it automating objects that are set to "hidden". This way there is no write into undo history .
No pattr workaround needed as I suspect it's a total placebo, based on my tests.
It is absolutely crucial to not modify the values of the automation enabled objects by any other object (even "set $1" does not work), otherwise you will get the undo history spam. The workaround is clumsy but it works. So I have created simple "automation" abstractions that I open as pop up on demand and assign automation to them. This means that if you want to save the state of the "hidden params" objects, you will have to use "manual" pattrstorage solutions and manage your presets carefully.
EDIT:
I will eventually probably create my own bespoke automation solution that would be nested exclusively in the M4L device itself - meaning no external automation needed. I just have to figure out the best practice for following the Ableton's timeline/transport so that the results are consistent.
Looks like potential improvements are coming? Cannot test the beta to verify.
From the latest Ableton Live beta 12.1.5b2 Release Notes:
Max for Live Parameters: improvements to Stored Only parameters and undo/redo
Max for Live Parameters: only changed parameters get added to undo
you have several options here:
to use the m4l api objects for maxmsp
if you are using m4l to modify the source of the m4l lfo and envelope followers, and getting them to work inside a maxmsp abstraction, or otherwise to use them straight inside maxmsp
if you are using maxmsp in standalone mode, you can use these devices, among many others (such as this fluid dynamic simulator thing, which is available for purchase somewhere on the internet
to code something like schema, java, node.script, python, haskell, or any other language, to work straight inside maxmsp
if you are in maxmsp to use an external analogue synthesizer, using a cv.2midi thing and controlling a midi parameter mapped straight by the UI of the overall thing