Author Topic: Button manager  (Read 8855 times)


  • Member
  • ***
  • Posts: 166
Button manager
« on: August 21, 2013, 12:13:48 PM »
Well, I want to implement to autoexpo module "attach button to" feature. But for future there could be some conflicts with other modules so I think there could be some button manager.

Some example:
if ((screen is off OR info screen) AND autoexpo_running) map speed dial to autoexpo exposure compensation
if (lv AND video mode) map left button to some custom defined action
if (lv AND raw_rec_enable) map set to raw_rec

I thing we should define these states:
lv - photo / video mode
info screen
screen off
play mode
not menu (we do need remap menu buttons ?)

send me you feedback and could you suggest some API? is this good idea?
Above that users can remap it to whatever.


  • Global Moderator
  • Hero Member
  • *****
  • Posts: 3657
  • Blunt and to the point
Re: Button manager
« Reply #1 on: August 22, 2013, 04:14:10 AM »
This is a great idea imo, as I might gain a better understanding on how to map buttons myself.


  • Just arrived
  • *
  • Posts: 1
Re: Button manager
« Reply #2 on: August 27, 2013, 07:07:05 PM »
I also think this is a great idea.

In fact i was recently checking the code to see if I could remap some button myself but having no experience with the magiclantern code I could not find how to do it so far.

I would be very interested in using this feature and perhaps in helping to develop or at least test it.


  • Senior
  • ****
  • Posts: 339
Re: Button manager
« Reply #3 on: August 28, 2013, 09:40:26 AM »
Oh please make this happen. There are so many things I'd love to map to a specific control.

Right now for one particular kind of shot I manually perform 10 or so button presses/wheel turns the same exact way every single time. This is an affront to the digital age.


  • Contributor
  • Hero Member
  • *****
  • Posts: 1557
  • 66d + flashes
Re: Button manager
« Reply #4 on: September 29, 2013, 08:08:47 AM »
send me you feedback and could you suggest some API?

This is my rough outline for an API, though it could be ammended idea about different states (lv, non-lv, ...):


  • Senior
  • ****
  • Posts: 319
  • 7D
Re: Button manager
« Reply #5 on: October 01, 2013, 08:45:26 PM »
Question, is it possible to add the functionality for example that a TV remote can send keypresses and map that to a certain button or command??

I say TV remote, but the idea is to make a free-positioning button device for easy access to the camera functions.. more and more the rigs that use an evf and are moved to the side (Letus MCS), while the camera sits on your shoulder are getting more popular.. So they lack a proper placement of the buttons..

Could it be possible?


  • Senior
  • ****
  • Posts: 263
Re: Button manager
« Reply #6 on: October 05, 2013, 11:03:49 AM »
I did it with a android tablet once for the same reason. (under water housing)
Sadly the android part isn't supported at the moment. I guess, if scripting would work and andriod support you could achieve this with a script and without touching the firmware.


  • Administrator
  • Hero Member
  • *****
  • Posts: 12564
Re: Button manager
« Reply #7 on: October 05, 2013, 01:18:43 PM »
Proof of concept code for intercepting remote control signals:!msg/ml-devel/bsZyPX2kEZ4/mtmlUL-WGcoJ


  • Senior
  • ****
  • Posts: 339
Re: Button manager
« Reply #8 on: October 08, 2013, 02:36:41 AM »

1) There are a thousand functions in ML and more being added constantly. They are beginning to conflict with each other when set to the same physical control. Right now there's no central way to reconcile these conflicts.

2) Nobody uses more than a small subset of functionality for a given photographic task. So while there are numerous functions, we only need a small subset of them available via the buttons/controls at any given time for maximum efficiency.

3) Since many of the controls are locked to a specific function, they aren't useful for photographic tasks that don't make use of that function. (I never use the wheel near the screen on my 5D2 when shooting real estate, for example.) This is a waste of precious buttons and dials.

4) Just being able to trigger a script with a particular button offers a huge amount of functionality. Things like the type of output message or beep confirmation can be customized in this case. I think this would actually be the primary use for the button manager.

(Not sure about the status of scripts atm--haven't tested in a while. But button availability was very limited. I'd hope this would result in more controls being available more of the time for customization. Also, it didn't seem like buttons were very responsive with scripts either. A button manager might solve this problem just because the script wouldn't have to do the polling--I don't know, you tell me.)


Without knowing much about how ML works internally, it's kind of hard for me to talk about how this should be done because I don't know what's impossible or too difficult to be worth implementing. Probably everything I say here will be little more than a masturbatory fantasy.

That said, there are a couple button press variations like normal press, press & hold, double-click, dial up/down. Then there are different camera states such as LV, non-LV, info, Canon menu, ML menu, playback that could potentially have configurable button assignments. However, it might not be worthwhile making configurable buttons for most of those modes. I can't even think of why we'd need to distinguish between LV and non-LV. When would you need to use a key to do something in LV and the same key to do something else outside of LV without just changing the current configuration? A script could handle this logic if someone really needed it.

It might be advantageous to think of usage in the framework of "photographic tasks". You pick up your camera to shoot a specific kind of thing and you usually only need stuff relevant to that. Even when you are just walking around with your camera somewhere, there's a limited subset of functions that you'd want to access that are generally useful. (Dual-iso is more generally useful than HDR bracketing.) When you're doing something more narrowly defined, you want a limited subset of functions that are specific to that task. What we can get from this I think, is that we really don't need states when we already have configs. Tell me if I'm wrong.

So for a GUI, I envision a separate top-level menu section for Controls. Each configurable button would listed right there, along with various types of event and action. Maybe a tree:

  toggle on click
  toggle on d-click
  toggle while pressed
  something else/better?

If we did want to define states I guess we'd need another layer of menus.  (I do not know how to make a mockup.)

Clicking one of these would pop up a list of available functions and scripts from which to select. The core of ML and modules could register a function instead of trying to grab a key. These functions would be available to choose in this GUI. This is a lot of work, but even a couple keys would be a big deal, and perhaps they can be slowly added.