Thomas

For Ableton Live 9.5, I am interested in creating a "shift" button on a controller which does not have a built-in control surface. The "shift" button will change the meaning of other buttons or sliders etc. on the same controller, perhaps by remapping them to a different midi code. I'm beginning to think I cannot really do this without delving into undocumented and unsupported Ableton Python scripting.

I initially looked into basic Ableton MIDI mapping and that doesn't seem to do it. It only offers simple mapping which allows controller-sourced midi codes to be mapped to Ableton UI parts such as tracks, clips, effects, etc. There is also no concept of monitoring a toggle, or using such to customize subsequent midi messages.

I then took a dive into programming with Max for Live 7 which, while amazing and really cool, seems to not have access to filtering midi messages *prior* to Live getting them. This means I cannot create a M4L MIDI effect which monitors a toggle that affects MIDI messages *prior* to Live ever seeing those messages. If M4L were to have such an ability, I'd envision that I would be able to monitor a toggle affected by a controller-sourced key up/down (or some variation of that, it doesn't matter, the point is a toggle), where the toggle would remap subsequent controller messages depending on the toggle's current on/off state. After that customized and simple M4L mapping, I'd then want Live to see the MIDI message for the first time prior to its custom MIDI Mapping. This would allow me to use CTRL-M mappings to map both default controller MIDI messages along with M4L remapped messages. But, sigh...

... That doesn't seem to be where M4L fits in. It seems that M4L fits in at the track level, where the best I can do is create an M4L component which uses messages to drive Live via the LOM which would then mean much more complexity than should be necessary. I could simplify such a solution by hard-coding LOM for my specific immediate needs but it would break as soon as I wish different behavior lest I make the M4L mapping configurable via some config settings which brings me back to a complex M4L solution... which may still have further limitations.

Then I looked at the Python route but it's unsupported and undocumented... not sure if I'm up for all that if it might change in future releases. I can write Python if necessary but at first glance it just seemed like so much for a simple pre-Live-Midi-mapping shift behavior. I don't like the idea of working with community hacked decompiled pyc files... it would be nice if Ableton supported that sort of robustness, or if M4L allowed modification at that early point in time.

That's where I'm at with my knowledge and understanding. Am I close to understanding this, or am I missing some easy solution here? :) Sorry if I'm missing something.

It seems like Live and Max are so close to allowing this but both seem to fall short here... Live doesn't offer such toggle monitoring mapping, and Max seems to get Midi at the track effect point in time, well after Live Midi mapping. Live Midi mapping is nice... would be great if it could be augmented with pre-mapping scripting of some sort (as well as Max-like post-mapping scripting which we already have via Max).

For Ableton Live 9.5, I am interested in creating a "shift" button on a controller which does not have a built-in control surface. The "shift" button will change the meaning of other buttons or sliders etc. on the same controller, perhaps by remapping them to a different midi code. I'm beginning to think I cannot really do this without delving into undocumented and unsupported Ableton Python scripting.
Here is what I think I know...

... That doesn't seem to be where M4L fits in. It seems that M4L fits in at the track level, where the best I can do is create an M4L component which uses messages to drive Live via the LOM which would then mean much more complexity than should be necessary. I could simplify such a solution by hard-coding LOM  for my specific immediate needs but it would break as soon as I wish different behavior lest I make the M4L mapping configurable via some config settings which brings me back to a complex M4L solution... which may still have further limitations. 

Then I looked at the Python route but it's unsupported and undocumented... not sure if I'm up for all that if it might change in future releases. I can write Python if necessary but at first glance it just seemed like so much for a simple pre-Live-Midi-mapping shift behavior. I don't like the idea of working with community hacked decompiled pyc files... it would be nice if Ableton supported that sort of robustness, or if M4L allowed modification at that early point in time. 

create-a-shift-button-for-controller

Max (standalone) can also be the input for Ableton Live (it is called "from Max 1" and "from Max 2"). So park a Max standalone between your controller and Live and have it function as a translation layer. Live will be oblivious about all that and you can use standard MIDI mapping mode. Your implementation of the shift button must be understandable to Max. If you use an Arduino with a B64 shield you can have 64 shift states! Good luck and have fun!

Create a "shift" button for controller?