totally! there are a few approaches i’ve used to translate data generated in a M4L device into meaningful control over Live parameters, all of which require a bit of work with the Live API. the Live API essentially gives Max programmatic control over / access to elements in Live. the scope of what can be controlled via the API is summarized in this doc: LOM - The Live Object Model - Max 8 Documentation.
approach 1: in this example, @gregory_taylor employs a kinda ‘old school’ way of seeking and establishing control over a Live parameter, by querying different parts of the current Live Set and grouping those into dropdown menus to provide a pathway for your Max-generated data to find the right destination in Live. this isn’t as slick as the LFO device’s Map button, but it lays bare the fundamental mechanism in a really nice way.
approach 2: roll your own. this is the video linked at the bottom of the previous approach’s thread, which compresses the amount of time it’d take for you to learn the LOM/Live API, if you want a hands-on experience: Max for Live: Basic M4L MAP Button - YouTube. and here’s the second video in the series, which covers bug fixes: Tutorial 1.2 - Remembering Parameter id When Moving Device - YouTube
approach 3 (more complex): rip it out of the LFO device. generally, this is the rad thing about M4L – if you know your way around Max patches, you can pretty much find your way to a device that does what you want by copy-pasting from other devices. since LFO already has the thing you want (and likely how you want it), you can feasibly wholesale swipe it:
- open the LFO device for editing via the edit button:
- unfreeze it (the snowflake in the bottom bar)
- unlock it (the lock in the bottom bar)
- right click the Map UI element, hover over ‘Object’ and select ‘New View of MapButton.maxpat’ to open the original patcher:
- click the pencil in the bottom bar to ‘Modify Read Only’, unlock the patcher, and you should be able to copy/paste all of that into a new device:
heads up: this might not be immediately viable for your specific desired use-case, because this mapping functionality requires an audio-rate signal as an input. if you’re going to be triggering signals from the grid to send thru this mapping functionality, then this should be fine, but it sounds like you’re maybe hoping to do discrete values – in which case, i’d say go with one of the other two approaches.
the grid stuff is pretty agnostic to the mapping stuff – once you’ve chosen your mapping mechanism, you just need to pipe values into it. if you want to generate those values from the grid, you’ll want to check out the Max grid studies and/or do a deep dive into some of the grid-centric Max patchers from over the years.
hope that helps! i work part-time at Ableton as a User Research embedded in the Max for Live team, so this specific topic + use-case are deeply lodged in my brain as ‘this is basically what 80% of folks want to do, why is it so hard?’ if you have any additional q’s, please feel free to ask!