Forums > MaxMSP

Re-enable automation turning on randomly


Aug 24 2013 | 4:11 pm

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.

Aug 25 2013 | 6:01 am

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)

Aug 26 2013 | 10:56 am

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.

Aug 30 2013 | 5:13 am

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?

Aug 30 2013 | 5:50 am

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….

Aug 30 2013 | 6:23 am

hem, couldn’t you rename with a script to [thispatcher] or [universal] object or something ? :>

Aug 30 2013 | 7:24 am

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.

Mar 25 2014 | 12:26 pm

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?

Mar 25 2014 | 2:25 pm

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…

Apr 09 2015 | 3:48 pm

i’m having some luck with setting the "update limit" to 50ms too.

Apr 10 2015 | 1:55 pm

I wonder if the LOM (Live Object Model) permits, "repressing" the Re-enable Automation button automatically?

Apr 10 2015 | 4:26 pm

Yes You Can!

Download the attached M4L Device.

Attachments:
  1. Screen-Shot-2015-04-10-at-4.25.47-PM

    Screen-Shot-2015-04-10-at-4.25.47-PM.png

  1. fgc.AutoReEnableAutomation.amxd.zip

mvf
Apr 13 2015 | 1:49 am

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!

Apr 13 2015 | 2:35 am

Maybe we should do a ‘class action’ towards Ableton by sending multiple bug reports about this so that it becomes a priority ?


mvf
Apr 13 2015 | 3:34 am

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

Jun 01 2015 | 12:52 pm

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.

Jun 02 2015 | 1:03 am

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.

Jul 30 2015 | 3:37 pm

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


mvf
Aug 18 2015 | 2:41 am

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

Oct 31 2015 | 2:58 pm

I have the same problem. This is a big bummer. Any news on a fix? Many thanks.

Nov 02 2015 | 12:55 pm

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!

Nov 21 2015 | 5:05 pm

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

Nov 27 2015 | 4:09 pm

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.

Jan 04 2016 | 7:09 am

Ok, I updated the ableton forum post.

Mar 20 2016 | 11:18 am

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.


mvf
Mar 21 2016 | 3:22 am

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.

Mar 22 2016 | 1:59 am

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.

Apr 02 2016 | 5:21 am

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…

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

Forums > MaxMSP