Re-enable automation turning on randomly
Hi,
This keeps happening in my patch for no apparent reason, it turns on the live automation re-enable button, when I automate a dial. There is nothing else controlling this dial. Its just a normal dial, controlling an lfo, but live just decides at random to deactivate it. I can see on the timeline where it happens and sometimes it does not happen, sometimes it does. Also I duplicated the device/track that its happening on, so could it be that the duplicate is somehow interfering with the original? Does anyone know why this might happen? It seems completely random in this case and possibly a rather large bug in the handling of automation.
After testing this extensively, it seems that max for live automation has a bug, where when two of the same devices are used in a liveset, the automated parameters become deactivated. This happens quite randomly throughout the timeline.
Is anyone looking into this? Its quite a fundamental problem for anyone creating a max for live device really.
Is it possible for someone else to test it? Put one device on a track, automate a dial for 4 bars, duplicate the whole track, press play on loop (within 5 or 6 cycles the parameter will become deactivated)
Any 1 ?
This even seems to be happening with the simple pitch drop max plugin released with max for live essentials, so it seems to me a problem with max itself rather than with any specific patch.
Granted I'm using live 9.1 but would be grateful if others could test it to prove this bug.
I have since found out from ableton that this is a bug that is not being prioritised/worked on.
Kind of brings into question the whole use of Max for live. Of course you want to automate devices. That's the whole point of integrating live and max surely?
Ive found a solution. There is a setting for the live objects called "defer automation output"
This seems to fix the problem completely.
Thanks for all the help in figuring this out.
Now Im off to rename around 180 live objects with this setting. Manually....
hem, couldn't you rename with a script to [thispatcher] or [universal] object or something ? :>
Unfortunately, it is a "hidden" attribute and cannot be changed dynamically.
I managed to change it in a text file, but I couldnt do this directly in maxforlive for some reason. I had to save it as a maxpat, open with textedit, change and then copy/paste from the maxpat into an amxd. Rigmorol, but got there in the end.
There are still errors with the automation issue above, but theyre slightly more bareable with defer automation output enabled.
I was having this issue too, attempting to automate some faders of the Max4Live device - DMaX Dimmer Pack in Ableton Live 9.1. I opened the device in MAX and turned ON "defer automation output" for all the faders. Saved the patch. But, still get the Re-Enable automation kicking in when my custom automation comes to the play head, thus not playing my automation. Is there something I'm missing here?
The only thing I can think of is that if youre already moving/automating those parameters with something and then you try and draw in some automation for them, you will get the re-enable automation coming on. Essentially, you cant move a dial, or fader twice, otherwise live cant tell what your trying to move, so it disables it. Might not be the answer youre looking for...
i'm having some luck with setting the "update limit" to 50ms too.
I wonder if the LOM (Live Object Model) permits, "repressing" the Re-enable Automation button automatically?
I experienced the same bug and would be glad, if it was fixed.
Kind of brings into question the whole use of Max for live. Of course you want to automate devices. That’s the whole point of integrating live and max surely?
Yes!
Thank you NEWTFISH for your findings.
@furiousgreencloud: Pressing the button automatically is a kind of dirty option, but thanks for the device. I'll give it a try!
Maybe we should do a 'class action' towards Ableton by sending multiple bug reports about this so that it becomes a priority ?
Edit 2: Hi Stephane. That's a good idea. I just started to prepare a bug report, but I first couldn't provoke the error in the manner, NEWTFISH did some time ago:
Put one device on a track, automate a dial for 4 bars, duplicate the whole track, press play on loop (within 5 or 6 cycles the parameter will become deactivated)
But suddenly it came up again. So my discovery is, that the bug occurs only with the 64 Bit Version of Live 9.
Please try the attached set.
I use OSX 10.8.5, Live 9.2b5 64 Bit (Beta) and Live 9.1.7 32 Bit. Max 6.1.9
Working with Live 9.2b10 (32Bit) I'm experiencing the same problems. The problem persists even if I remove the MaxForLive objects. I filed a bug report as Beta tester and will post any responses here.
Ableton gave me the suggestion to disable control surfaces. This didn't help, but disabling "remote" on my "Output IAC Driver (Using Mac)" did make the problem go away for me. My guess is using remote on the Output generates a data feedback loop, hence the automation override. Maybe this helps some of you guys.
I have been having the same problem. I use Ableton 9.2 64bit.
It happens with both vst plugins and Ableton FX. It's only recently started doing it so I don't yet know if it does it with any of the M4L devices. However due to this problem I am unable to work in the arrangement view.
The same thing was happening in session view the other day, although it's not happening at the moment.
Has anyone found a solution yet? It seems to be a very common problem. Anyone heard anything from tech support?
Sharon
Hi Sharon, do you have new findings on the issue? It would be great, if you send your experiences as a bug report to Ableton. They are very low-key in terms of bugs in Max4Live, but very interested, if the bug concerns Lives own internal devices. So if you could send them a live-set producing the behaviour, they will look at it and give it a high priority. Send your mail at: support@ableton.com
I have the same problem. This is a big bummer. Any news on a fix? Many thanks.
the max for live device, really does help with this. I've had max running in a gallery for 3 months with this and it keeps the automation engaged!
The device just saved my life.... Just linking this here for backreference: https://www.ableton.com/answers/loading-presets-via-program-change-disables-clip-automation.
I added the device at maxforlive.com to prevent it from disappearing. Hope that's ok. http://www.maxforlive.com/library/device/3345/automatically-re-enable-automation
Anytime (saving your life ;) ), but just for the record i'm the author of this (furiousgreencloud or fgc) not mvf.
so that's
https://cycling74.com/author/9112/,
now also at:
http://www.maxforlive.com/library/device/3351/fgc-reenableautomation
Much Love, thanks for the kick to upload this.
Ok, I updated the ableton forum post.
It's 2016, I'm using Live 9.6, and these automation bugs are still horribly present and need to be fixed. It has gotten really bad in my recent projects. It is almost to the point of giving up using any standard clip automation in my Live projects.
"I have since found out from Ableton that this is a bug that is not being prioritized/worked on."
Really Ableton? Please tell us that you're attempting to fix this almost 3 years later.
In a recent project this came up again with its full madness. I tried speed limitations and "defer automation output", but nothing helped.
It's kind of impossible to record any automation then.
I have the impression, that if I duplicated a track with a device, the bug appears very fast. If I'm adding a new track instead and drag the device in, it's better. Does anyone have made such an experience as well, or do I imagine this? I even thought about building copies of a device like device1_01 to device1_10. In "manage devices" you can reassign an already automated device to a new one. So I could reassagin one copy for every track. But I don't know if that would make sense.
This worried me as I have put allot of work into a device that had not tested running multiple instances.... rushed off to test.
Duplicated track and my device was blank...hmmm .... that is another problem try again.
Loaded same device onto two tracks automated the same dial on both tracks 20 min both of playing and the re enable automation is behaving.
I mention a working device because I use max ui objects with pattr no live objects. My experience seems to suggest its a live object bug.
FWIW, this happened to me on imacs running 10.9.5 used for workshops, with sets containing no M4L device. An automation recorded in arrangement using a track volume fader in Live GUI auto-deactivates itself when reading the arrangement. If you re-activate it, its gets inactive as soon as it plays over a value change of the parameter.
Never seems to happen to me with 10.8.5 on my laptop. So this could be related to Live alone...
Hey, same problem here ... automated live.numberbox will go grey in only few seconds(defer and speedlim not changing anything). Is there any solutions except the api thing ? This totally ruins max4live. Thanks !
Experiencing the same problem: I want to automate more than one instance of a M4L object, and it's impossible.
Is this considered a niche thing that I'm trying to do here?
If there was ever a clue that M4L is really not taken seriously by Ableton, it's this.
Anybody with any proper advice is still welcome to chip in here.
thanks! - t
I just tested this again after a long time away from M4L, and I do not seem to be having the issue anymore. Live 9.7.1b4 and latest version of M4L.
Has the bug been fixed?
To test, I used Newtfish's repro steps above: "Put one device on a track, automate a dial for 4 bars, duplicate the whole track, press play on loop"
Thank you!
I've been doing this in Ableton Live 9.7 and the latest version of M4L. Had the problem persist, not consistently, but once every couple of minutes another parameter falls off the automation bandwagon.
I'll download the newest Ableton, but it's probably unlikely that this specific bug got fixed specifically in 9.7.1
I'll let you know...
I was having this problem with Max Api SendsXnodes in Live 9.7.1 and resolved it by updating to Max 7.3.3.
So far so good.
I'm having this issue and it's driving me utterly insane.