live.adsrui~ and automation

m501's icon

Hello,
I am creating a Max for Live device and it has a live.adsrui~ in its presentation mode.
I noticed that manipulating the ADSR parameters during automation recording does not register as an automation param change. How can I "expose" this parameter so that Live knows it should record value changes for automation?

If I associate it with a knob as an input to one of the ADSR params, then manipulating the knob registers as a param change. Unfortunately, then if I manipulate the handle directly, then the knob does not update (since the parameter is not setup as an input to the knob, and if it is, then it destroys automation for that parameter).

Here is a video:


Thanks in advance.

Namakemon's icon

Maybe the "tethering" example in its Help works for your case?

m501's icon

NAMAKEMON, thanks for the reply. Maybe I have a different version of Max. I'm on 8.2.2 and I can't find the tethering example in the Help > Examples menu nor in the documentation. I'll keep poking around. Thanks again.

Namakemon's icon

I meant the Help when you right-click an object like live.adsrui, and select "Open live.adsrui Help" option.

That Help is different from Reference documentation or Help in the menu.

m501's icon

Ah! Thank you for clarifying. I found the example and I'll be looking into it. Really appreciate your help.

m501's icon

Just reporting back for future developers that the live.numbox suggestion from the Tethering example did not solve the problem. This seems to be a long-running problem as seen in these threads from 2016 and so on:
https://cycling74.com/forums/re-enable-automation-turning-on-randomly/

The problem, of course, is that the control can't tell if the change is from automation or manual (or scripted, for example). The solution probably lies in the adsrui implementation itself exposing the parameters somehow, OR, exposing a way for a control to output if the change is due to some UI manual change (instead of value set) so that a node further down the graph can then decide if it should patch it back into the patch or ...something.

Other knobs and widgets can do this, so the live.adsrui should as well. Probably should be a Max feature request for some later version. For my purposes, I think I'll just make the adsr ui read-only and expose the params as knobs.

m501's icon

Another possibility to explore is the pattr and its `thru` attribute. Maybe there's a way to toggle the thru attribute depending on the state of the LOM: https://docs.cycling74.com/max8/refpages/pattr?q=pattr

Langdon Crawford's icon

solution i'm using for now....

add a gate subpatch between the live.adsrui and the live.number driving the ADSR parameter. the gate is set to close for 1000ms when the live.number is sending numbers. after 1000ms with no numbers, the gate opens again.

automation-gate-live.adsrui.maxpat
Max Patch

tyler mazaika's icon

FWIW I recently reported a bug to Cycling74 about this feedback problem with live.adsrui + live.numbox automation in Live. Basically, live.adsrui seems to erratically throttle / batch updates being sent out and is liable to stream older value changes well after the live.numbox value has stopped changing.

I suppose the 1s window heuristic used in the workaround patch above is long enough to prevent this from breaking automation. But doesn't this break (or make very unresponsive) normal user mouse interaction with the live.adsrui itself?

m501's icon

Hey thanks for both of your replies. I'm going to hunt down that bug report and keep an eye on it.
Will try the delay window and report back on how it feels.

m501's icon

I gave the gate a try and it didn't work (see how it didn't work below) but maybe I authored it incorrectly.

Now the automation is not saved at all whether I modify the ads ui or the knob.

I've created a smaller patch with the ADSR ui and two knobs. One uses the gate patch idea and the other just straight passes it to the ADSR ui but does not feed it back into the knob (for debugging).

Appreciate the help!

adsr-automation-bug.amxd
amxd 15.63 KB
debug patch

Exit Only's icon

just wanted to chime in and say i'm running into this issue too. would be great for a built in fix. I tried using mousestate to gate the data from adsrui into the numboxes but that does work if you are doing other tweaking while automation is running. i'm probably going to end up buffering the output of each adsrui setting in a float and then banging manually to sync
it seems like a simple "only output on mouse change" setting in the inspector would solve this issue or add an additional outlet to bang when edited, similar to function.

Matt Smart's icon

I’ve also been having frustrations with this issue for a while. I got around it by coding my own JSUI object that works and looks just like live.adsrui (it also has a few extra features like double clicking handles to reset default values). I’ve uploaded it to my GitHub if anyone wants to check it out: https://github.com/MattS6464/MS_UI_TOOLS/tree/f6dc94f19c965b3d3c6a55eecd5426e75aa9b636/MS_UI_TOOLS/MS_ADSRUI

I’ve also made a help file to explain how to customise and initialise it with loadmess objects.

tyler mazaika's icon

Just FYI, Max 8.6 (I think) added @outputmode and @tethering attributes to live.adsrui. You can check out the helpfile. I haven't tested it out in Live yet, but I believe they're made to address this issue.