Forums > MaxMSP

Re-enable automation turning on randomly

August 24, 2013 | 4:11 pm


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.

August 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)

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

August 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?

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

August 30, 2013 | 6:23 am

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

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

March 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?

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

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

Forums > MaxMSP