Max for Live automation and pattrstorage
Hi. I've got a bit of a niche Max for Live question - don't know if anyone will be able to help!
I'm using pattrstorage in a Max for Live plugin - it's very handy to have presets as there are a lot of parameters. However, it's also sometimes really useful to automate said parameters.
My problem is this: if I recall a preset slot from pattrstorage, and this is storing any of the automated parameters, those automation lines get greyed out and ignored until I click the magic orange arrow. Is there any way round this?
I understand this isn't a bug, and this behaviour makes sense. But it'd be really handy for my purposes if I could get the best of both worlds! They way I'd envisage it is that automation always takes priority, so if a value gets set by a preset but then an automation value comes in it would immediately set to that. Not that I intend to use both at once, I'd just love to have both options in the plugin - if that makes any sense!
I have a hunch my solution might be somewhere in the more obscure flags at the bottom of the inspector for pattrstorage, but not sure what magic solution might work!
One possible solution is to monitorautomation_state for each parameter and and set their active state to 0 in pattrstorage when automation_state is 1 (automation active), or to 1 when it is 0 (no automation) or 2 (automation overrident).
This way, automated parameters won't be changed during a preset recall.
To change the active state of a parameter, just send a active param_name $1 message ($1 being 0 or 1) to your [pattrstorage] .
Thanks TFL, sounds promising and I'm kind of half following...! The bit I'm stumped by so far is - how to ascertain the automation_state for a parameter?
Actually the easiest thing for my purposes would be just to be able to re-enable automation from my patch. There's a plugin in this collection that does it - https://abletonkurse.gumroad.com/l/TempoControlCollection
but I'd prefer not to buy something, and to know how to do this for myself. So, can anyone tell me how to re-enable automation from Max for Live?
As usual, the answer is in the LOM: there is a DeviceParameter function called re_enable_automation which does exactly what it says.
Here is a basic example to set up an observer for automation_state of a given parameter, and disable it in pattrstorage. If you don't want to go with the observer solutions, I also added a re_enable_automation button if you want to re-enable automation for that parameter manually (like by listening for recall messages being output from pattrstorage)
Getting somewhere, but not quite there yet. I presume for the method suggested by TFL I'd be using [live.object] and querying/setting automation_state there, but I haven't quite worked out the details.
For just re-enabling automation (which I could build in as a nice easy hacky fix, just do this after a preset is called - would work for my purposes), I assume I need live.remote~, but I've no idea what I'd need to send it, or where to find out!
I use M4L quite a lot but generally manage to avoid this API stuff, which still seems a bit opaque to me!
Thanks again TFL, somewhat crossed posts there as I was still typing mine while you'd already answered some of my questions! That patch is v helpful - many thanks.
If you or anyone knows how to just re-enable all automation (ie exactly the same as clicking on the orange arrow), that would also be useful, since it would allow me to make a quick hacky solution while I work on a better version based on your patch!
I realise this (the latter) should be quite simple, but I've not quite got my head around the LOM yet..
Re-enabling automation for all parameters is the simplest method (example below) since you don't need to set up one observer for each parameter, but I'm a bit afraid of the result since it could result in fast value jumps when recalling parameters value from presets while those same params are automated. The observer + active message approach, although a bit cumbersome, prevents values from being recalled, so no value jump at all.
I agree the LOM might not be the easiest piece if the documentation to understand at first, but it is definitely a must have for M4L devices interacting with the Live environment, and its logic isn't that hard to grasp after carefully studying the graph. What might help you is to remember the global structure: song > track > device > parameter
In the LOM, parameters are represented by a DeviceParameter object, so if you go to that section of the LOM page, you'll see anything you can query, set or observe for parameters (including the automation_state property and the re_enable_automation function).
Thanks for all your help TFL. I think you've got me started on my LOM journey!
Have a nice trip!
I just realized I forgot to paste the patch in my previous post, this is now fixed.