Topics

Currently there are 32 branches in the main ml repo - how about deleting the outdated branches?

They are dragged around with every fork which doesn't seem very clean & might create confusion as unified seems to be the only one being worked on... since there are so many ml working forks probably doing in-repo branches except for quick experiments isn't such a good idea at all, but create a full fork even if the person has write access to the main repo?

Currently with silent pics burst, I can decide if to save all or only the "best" (= in-focus shots, if I understand it correctly(?)).

My suggestion is to also mark the "best" if saving all, or add another option for this alternative, since then I could first looking among the "best shots" and if this fails to find the one I look for sort through the rest as a fallback option.

Possible ideas to mark the "best" when saving all would be a file name appendix or a keyword marker in the dng file.

Focus pattern unfortunately don't work on the 6D, the whole ml section has been removed. There is one regression though, which has a large practical impact for action shooting:

Problem: With my 60D & ml, I could quickly set the af to the center point by pressing SET (= *one* click = fast), with the 6D I need to press af select and then SET (= *two* clicks = slow). Yes, this might make the difference between getting the shot you want or not.

Suggestion: Simply re-enable the part of af patterns that ties SET to quickly setting the center af point... shouldn't be too problematic if the 6D af prop is already reverse engineered or the same as 5d2?

[max. x-sync]

Disclaimer: This might sound a bit outlandish to people not using flash(es), but let me ensure you this is one of the worst regressions from 5d2->6d and one of the main complaints about the 6d from portrait/wedding photogs. If this gets solved then it'd be one big brownie point for ml.

Problem: The 6D max. x-sync is only 1/180s, but it's not mainly the mediocre speed that's the problem, but the fact that you're not able to set it if "C.Fn I-1: Exposure level increments" is set to 1/3ev. The alternative 1/2ev is not practical, the interval is simply too large, esp. since the flash exposure compensation is also tied to this.

Suggestion 1 (optimal solution): Squeeze in 1/180s between 1/160s and 1/200s by intercepting the dial and force-set it in M/Tv on 1/160s->dial up & 1/200s->dial down

Suggestion 2 (a bit more usability hassle): Tie force-setting 1/180s in M/Tv to some button like SET or another less often used button ml can intercept.

This was buried in soem menu thread, I'm sure alex has noted it and it's not here to build pressure, but simply to move the request where it belongs:

Issue: The hard-coded defaults of ML sometimes are pretty arbitrary, plus they clutter the recent "Modified" menu. If some mis-configuration is done, resetting to ml defaults isn't a good option because a lot of carefully chosen settings are reset just to catch one problem. The current solution is to file-copy the config files on the card, but that cannot be done from the camera (quckly).

Suggestion: In addition to the ML base config, add an option to save a USER base config and base the Modified menu on this. Add a "Reset to USER defaults" option next to "Reset to ML defaults". This additional safety net would invite more feature tryouts over reboots and enable the users to fall back to their own working config in a panic situation.

Suggestion: With now 10 sticky threads the "general discussion" is getting rather cluttered, I suggest adding a "module support & discussion" subforum where - next to module-related threads - each module could have a sticky'ed support thread that's mentioned in the modules' readme files.

As more features get moved into modules, inter-module connections imho becomes more important as for example ettr using dual_iso's calls with "extern WEAK_FUNC(ret_0) ...". But what if I want to do these things w/o touching the other module:

1. detect if a module is loaded at all?

2. get or set other module's config vars?

Are there existing code samples anywhere? If not, it'd be great if there would be a core framework for these, for example module_check_enabled("ettr") and module_set/get_config("ettr", "auto_ettr", "0").

I like the option to look at focus peaking, Zebras, ... in play mode after pressing the appropriate button when setting "Global Draw" to "Quick Review" or "ON, all modes".

Problem: the overlays are *always* enabled _without_ button press in Quick Review right after taking a shot which draws too much battery power if I just want to have a quick look at the framing and not the exposure.

Request: Add an option "Quick Review GD -> Always on / On demand" for example in Display -> Advanced Settings" to let the user choose if the overlay is applied right away or if a button press is also required in quick review mode after taking the shot just like it is in play mode now.

The dng spec has the option to embed a raw file like cr2 in the converted dng for safekeeping if it should be required later on, for whatever reason. The embedded can be extracted or deleted later on.

Since the cr2hdr process is lossy and a newer version might have better results, I'm currently keeping all old DUAL cr2 around, resulting in quite a messy archival and tagging situation. It would be great if cr2hdr would have the option to embed the original cr2 in the dng so both are kept in the same place, though of course at the cost of a larger file - but if the original file is to be kept anyway this doesn't matter.

I couldn't find a request for this, so here it goes (again?):

It would be really helpful to have a raw histogram not only for the last shot taken, but added as an option to the ml picture viewer or to the Canon picture player. It doesn't have to be fancy at all, actually *any* hint, even a text message, if there were blown highlights in the cr2 would be really helpful to decide if to re-take a shot or not.

I cannot comment on bitbucket commits anymore, is this a bug or a feature, i.e. did the devs decide not to allow normal users to comment there but prefer this forum?

This was buried in some dev thread, but I'd like to add an "official" feature request for this:

Modules currently don't support multiplexing variables as arrays, which is unfortunate since it's an extremely useful function and it cannot be worked around easily. As soon as an author module wants to have different config or variable sets, this is the way to go - take for example different exposure curves in the autoexpo module. I also wanted to use this in a module of mine to tie variables to dial settings until I found out that copy/pasting my code that was working in the core was broken as a module

In modules, the user can add entirely new menu points with menu_add - but imho sometimes a small enhancement would be better placed under an existing menu point from the ml core. I suggest to add this to the function, so you could write something like this:

Code Select Expand


menu_add_children("Prefs", "Misc key settings", my_menu_children, COUNT(my_menu_children));


The file_man module and one of mine show the OldAPI warning with the latest trunk and won't work, strangely the other bundled modules work, even yet another one of mine.

I read that "just recompiling" should bring up the modules up to the new version (http://www.magiclantern.fm/forum/index.php?topic=7503.msg71712#msg71712), but obviously this isn't it - am I missing something here?

EDIT: I solved it myself, though "make clean" wasn't enough but I had to clean up some leftover files from the module directories manually.

Though older cameras like my 60d only have a *max.* autoiso range setting in the canon fw, I just discovered that the min part doesn't contain junk or zero, but actually the setting that is used - iso 100. Could it be that Canon uses this value in their fw, but just didn't provide an ui frontend for it? If so, exposing it would make a great addition for the ml expo menu!

Did anyone try to *set* this value yet (I'm a little hesitant to do something like this, even in C mode, since I cannot afford to brick my camera)? This is how it's read, the same as on 5d3/6d:

Code Select Expand


int canon_min_iso = auto_iso_range >> 8;


Is it possible to nest submenus, or is this a planned feature?

Some menus I have in mind with a lot of choices, for example for choosing hotkey functions, simply don't seem appropriately placed in the main menu hierarchy, and having submenu-submenus would allow splitting up large item lists into more logical pieces.

I would like to make some ml settings lens-dependent, i.e. auto-switch them when changing lenses. Question is: How to I tell one lens from the other the easiest way, ideally w/o comparing strings like name (do have all lenses this field?) and multiple properties like min/max aperture?

If there is no easy way atm, I'd like to request a lens_id field for the lens_info struct where all unique lens properties are distilled into one easy, unique hash or number you that can be quickly compared and saved in a config value. Rather than doing this in a module imho this should be so useful it'd be better done in the ml core and added to lens.h

The purpose is different from the existing bracketing, but it could be integrated nevertheless:

When taking long-time exposures at night often some things move and are blurred, an example would be a flag. If you want to prevent this you have to take another shot at high iso and blend both exposures.

I'd like ml to automate the shooting sequence, i.e. with a new option "same exposure" use the "0 + ++" pattern to take a bracketing sequence with the given EV spacing by raising the ISO value and modifying the shutter accordingly.

I could just do this in a module, usually 2 shots (one iso100, one high iso) are enough, but if it would be a real bracketing sequence with multiple shots it would allow the shot with the best blur/noise tradeoff to be isolated much easier.

Are there any ideas, plans or schedules for localized ml menus/strings other than patching the whole source code and (this is the bad part) adjusting this patch for every changeset?

To people accustomed to the Internet and participating in English forums this might be probably surprising, but at least in Germany there is a good part of the population in the east who did not learn English in school (and forgot their Russian :-)) and any non-localized user interface is a objective or at least subjective barrier that is not to be underestimated.

To some, modifying their camera with a "hack" sounds obscure enough, but it's worse when the hack speaks a language you barely understand :-p ... so imho the potential ml userbase is narrower than it could be.

Can we set the shooting_mode by software, i.e. w/o turning the dial and assign switching modes to a button like on the 1dx? Thanks!

Um, I'm trying to catch the MODULE_KEY_UNPRESS_SET event, but it doesn't work on my 60d (_PRESS_ works fine though). Is this supposed to work on every model? Are there any hidden catches when this event is called that I'm not aware of? Thanks!

Do you think it makes sense to add a function to the file browser that deletes all xmp files from ml deflicker that don't have a corresponding cr2/jpg anymore, i.e. these shots have been deleted by the user? Having tons of abandoned xmp files over the place is neither clean nor tidy when browsing the folder on the pc, but then again maybe I'm the only one with that impression.

I have to admit I'm a bit confused by the state of the discussion about the flash prop (http://www.magiclantern.fm/forum/index.php?topic=3920.0;all) ...

... but apart from setting/detecting specific flash functions, is it currently possible to detect if the pop-up / an external flash is enabled/attached _at_all_?

* Shutter: I know the raw shutter value doubles every 8, so for example 120 = 1/250s and 160 = 1/8000 ... but what the intermediary values, i.e. what is 1/180s and 1/200s?

* Aperture: What are the raw aperture values & what are the steps?

* As I read in the source code you cannot set any value but have to stick to 1/3 or 1/2 steps, but this is covered by the functions in lens.c, correct?

Thanks!

Afaik it's advised to just add PROP_HANDLERS in modules when needed - but can I predict in which order they are executed, for example the core PROP_HANDLERS before the modules?

In my current case I'd like to add a PROP_HANDLER(PROP_ROLLING_PITCHING_LEVEL) to auto-switch the af points from portrait to landscape and vice versa by reading the "struct rolling_pitching level_data" that is initialized in the core PROP_HANDLER.

I'm trying to use the method from hdr.c for array variables in my module, but it won't work - is it me or isn't this supported in modules (yet? if so, please do add :-)) ... this is part of my (abridged) module code:

Code Select Expand


static int8_t mymodule_var[2];
CONFIG_ARRAY_ELEMENT("mymodule.var.0", mymodule_var, 0, -1);
CONFIG_ARRAY_ELEMENT("mymodule.var.1", mymodule_var, 1, -1);

MODULE_CONFIGS_START()
    MODULE_CONFIG(mymodule_var)
MODULE_CONFIGS_END()


... and this is the compiler error:

Code Select Expand


[ CC       ]   mymodule.o
mymodule.c:6:1: error: '__config_mymodule_var' undeclared here (not in a function)
make[1]: *** [mymodule.o] Error 1
make[1]: Leaving directory `/ml/magic-lantern/modules/mymodule'
make: *** [mymodule] Error 2


The shiny new cameras have a fw option to switch the af point based on landscape or portrait position - is it possible to backport this to the older generation like 60d, i.e. can we read the level indicator position outside lv? If so, it'd be great to be able to save a af pattern for each position that is auto-recalled if you turn the camera.

EDIT: Doh, sorry, wrong subforum (was supposed to go into development general) ... maybe you could let users delete their own posts/threads? Anyway:

For the ml auto iso module, I'd like to use this...

Code Select Expand

        .children =  (struct menu_entry[]) {
            {
                .name = "Min. Av Shutter",
                .priv = &m42_aiso_shutter,
                [color=red].max = FASTEST_SHUTTER_SPEED_RAW/8-11,[/color]
                .icon_type = IT_PERCENT,
                .choices = CHOICES("OFF", "1/15", "1/30", "1/60", "1/125", "1/250", "1/500", "1/1000", "1/2000", "1/4000"),
                .help = "Preferred shutter for Av mode (+/- 0.5 EV result).",
                .help2 = "Selectable values starting from 1/15 in 1 EV steps.",
            },


... problem is that FASTEST_SHUTTER_SPEED_RAW is a model-specific constant and I have to grab it with a getter function from the core code.  But the menu struct stuff doesn't seem to accept any non-static values, any idea how to get around this?

I'd like to copy 400plus' EC on M approach (described here: http://www.magiclantern.fm/forum/index.php?topic=4514.msg49214#msg49214) ...

I had a look at the code, and it's completely different than my, thus my question: How do I get the measured ec in M mode when the user engages metering? Based on that, I then could calculate the required iso and apply ec on m on top of that.

Here's the relevant 400plus code, what I want from ml is this "status.measured_ec" value.

Code Select Expand


// M mode: set ISO to match exposure
ec = - (status.measured_ec - persist.ev_comp);

// Normalize an apply new ISO
if (ec != EC_ZERO) {
if (settings.autoiso_relaxed)
ec = (ec - 1) / 3;

newiso = DPData.iso + ec;
newiso = CLAMP(newiso, settings.autoiso_miniso, settings.autoiso_maxiso);
newiso = EV_ROUND(newiso);

send_to_intercom(IC_SET_ISO, newiso);


I'm trying to add "EC on M" to the auto iso module - so far so good, it's basically adding/substracting some shutter or aperture and setting it (thanks for figuring out round_shutter...), respecting some limits. Problem is:

If I modify aperture/shutter in M mode, it immediately shows as if the user would have set it and doesn't work as ec in tv/av. So I have to correct the exposure value before and after taking the shot. Is there a way to "wrap" the Canon shot with ml functions, i.e. hook before and after it? If not, I'd have to try half shutter as before and somehow shoot task as after, but I don't think I'd get this to be really reliable

What's this set_frame_shutter_timer/iso() that's apparently so hot...

* is this a 1:1 replacement for lens_set_rawshutter/iso on supported camera bodies so I can use them in the ml auto iso module?
* ... or are the new functions only for lv, might be since I found them used in the CBR_VSYNC_SETPARAM?

Thx.

Um, what's the prop again please to change how the camera starts af (by backbutton (=1) or half shutter (=6))? Is this the same across all models? Thanks!

I want to detect if the dial is on (one of the) C settings, but at least on 60D shooting_mode isn't detected SHOOTMODE_C but  the original mode saved as C, in my case SHOOTMODE_AV ... how do I manage tell C (i.e. AV saved as C) from real AV?

Btw sorry to be a bother but some things don't work as I expect and then you people who are more in depth with the code are likely to be able to help...

As it is now, the module "description" line is rather a "title" because it's so short and just one line. It'd be nice to have a real "description" line that pops up in a submenu-style box where the modules features & help text can be entered, now that we're not so tight on space anymore a few bytes more shouldn't matter? For modules that aren't self-explanatory or contain several features that'd be a great help.

Request: rename current "MODULE_STRING("Description", ...)" to "MODULE_STRING("Title", ...")" and add a "MODULE_BOX("Description", ...)" or something like that. Another option would be a multi-line ""MODULE_STRING("Description", ...)"  instead of the one-liner that is clipped now.

Not only seem to be some issues with ACR (nor) reading xmp files (see http://www.magiclantern.fm/forum/index.php?topic=5724.msg50383#msg50383) but I'm a big fan of tagging with keywords so I can quickly sort files in postprocessing.

Request: Add a "ML Deflicker" Keyword to the xmp files so you know which files have been ev-corrected by ml (so you can copy/past processing settings) and as a sideeffect you know your postprocessing software has read/processed them at all. Should be trivial to implement, as long as you don't juggle around with keywords it's just one added line.

I know there is a "Rebelized" C-Mode patch in the queue, but this is something else I'd consider important and easy to implement, though I don't know if this feature request has come up in the past (couldn't find it):

Canon C Modes (60d: 1, 7d/6d: 2, 5d3: 3) are about saving an entirely different config for quick access. While that might be not the most flexible approach ever, it certainly works, and in the summer I use my C mode for a action mode (high iso, fast fps, servo af, spot metering, ...).

Problem is: If I have something set in the ml config like handheld mlu the C mode is worthless because the enabled ml feature defeats the purpose. So after choosing C I'd have to either recall another ml config (though picoc or whatever) or disable the intervening features manually, that takes time and the shot is gone.

Request: Add an option that for each Canon C mode ml loades another config, so there are (number of C modes) +1 generic config file.

Implementation: Should be simple, if a C mode is selected and there's no existing MAGIC-Cx.CFG (i.e. MAGIC-C1.CFG, MAGIC-C2.cfg, ...) copy the current settings, otherwise load the appropriate MAGIC-Cx.CFG file. If the user wants to delete the MAGIC-Cx.CFG file it could be done by the "reset config" item (or manually on the card, of course). At least that's my first idea, certainly can be  streamlined, if alex or someone else is willing to adopt the idea.

Auto-ETTR is so nice I'm getting too lazy for proper manual or even semi-automatic exposure :->, and here's the way to get even lazier (and save some shutter cycles which are burned by auto ettr):

When Auto-ETTR fails, i.e. the scene has too much dynamic range, ml should give the user the option to do proper bracketing right away, capturing *only* the frames that aren't already taken (more or less). Otherwise doing a manual ml bracket afterwards takes time to initiate and it's likely the camera takes the *same* (more or less) frames again that auto-ettr already has.

The drawback is that the auto-ettr frames aren't "properly" spaced as real bracketing would, but personally I wouldn't care since +-1ev can easily be done in post before merging and tonemapping. It would just be nice if ml could add some frames with the spacing set in the ml bracket options, certainly better than simply failing auto-ettr.

Btw. adding a 2nd overexposed bracketing frame also makes sense when the result of auto-ettr is that there's much data in the deep shadows which might be affected by noise after postprocessing.

Recently my most used ml feature was axed: ml auto iso, it is supposed to be superseded by ettr and/or the dev(s) lost interest in it as far as I understand it. For me personally this isn't an issue because I re-patched it into my local build, so I'm fine as long as the patch applies more or less - but others might not be so lucky.

Request: re-add ml auto iso, as a module if it need be (maybe ml goes the modularized way anyway, probably not a bad idea)

Rationale: ml auto iso made two vital things possible that at least I have been missing as long as having a dslr and using auto iso: prevent the lens from going wide open in Tv and override Canon's shutter speed decision (either too fast for landscape or too slow for action) in Av mode. ETTR is completely different and does *not* replace this because it needs up to 2 junk shots to calibrate, while ml auto iso is/was a quick "good enough exposure" mode for action with selectable depth of field (Av with ml auto iso) for macro/landscape/walkaround with selectable motion blur stopper (Tv with ml auto iso).

Edit 1: Also if anybody is up to it feel free to implement smaller than full iso steps (though this seems to need some wizardry since ml currently uses Canon's algorithm as far as I understand it). But it was working as it was and a bit step up from bare Canon auto iso...

Plus: Also nice would be *upper* limits for either aperture (too small aperture = diffraction) and shutter (too high shutter = camera cannot use flash x-sync anymore) :-)

Edit 2: M mode also is no alternative, no only because it's slower but there is no "ec on m" and I ec on every other shot with the back wheel

The ability of ml to generate xml files is great, and I wonder: I usually pre-review and rate image in-camera thanks to the quick lv button shortcut. Would it be possible to add other tags to the xmp file like (custom) keywords that are then read into lightroom? If this is possible it would be a great timesaver because if I could pre-sort the images next to the very basic rating like now, for example decide which shots are good but slightly out of focus so they're only ok for web size.

I've come to like this feature with my non-IS 17-40L lens and the severe iso limit of the crop sensor - but imho the 1/2...1/125s limit is completely arbitrary, so it would make sense to let the user at least set the upper limit. Yes, I can set it to "always on" and enable it on a shot-by-shot basis, but if there's the auto shutter speed option it should be done right :-)

I've been trying auto-ettr a lot today, it's really a terrific feature, great work! The one real limit is the need to take one trash pic or enable lv, but of course than cannot be helped. I have some feedback since I feel this great feature deserves to be as usable as possible for as many people as possible:

1. the unavoidable request: Please add an option to allow ettr to open the aperture to user settable limit (so the dof doesn't get too small). Ideally there would be a priority option what to do in what sequence: raise iso (until Canon limit), lower shutter (until set limit), open aperture (fixed like now or until set limit). Rationale: If looking for a proper exposure for example on my 17-40L I'd rather go from f8 to f5.6 (wide open would be f4) then raise iso further, and if auto-ettr doesn't do it for me I have to do it manually.

2. DONE auto-ettr doesn't seem to work with "image review" off? If so, ml should set it to 2s to avoid confusion EDIT or at least give a warning message in the menu.

3 EDIT DELETED because you can overexpose the 1st shot, but have a 2nd to get the 3rd to ettr.

4. DONE option to prevent 2nd shot before ettr calculation: I stood at a very busy street in bright sunshine and could neither hear the ettr ready beep nor see the display. Sure I could just wait some, but it would be nice to have an option to block the 2nd shot until the ettr calculation is done, otherwise the 2nd is like the 1st... if blocking is not possible maybe an option to do the 2nd shot automatically once ettr calculation is complete?

5. EDIT DELETED because ml cannot re-load previous shots as raw and ettr them.

I can't help being curious: There is this lv_rec module that doesn't work on my 60d (yet?) due to undefined symbols that are only there (yet?) for digic5 650d/6d/5d3/eosm - what is this module? Will it be available on digic4 also - I got raw_rec working by now...

When telling people to check out ml I'm always wondering if there's a simple page that explains what ml can do for you (and the Canon fw cannot) with simple descriptions and sample videos and shots for the features.

When looking at the current website it's all about new ports, legal and tech considerations, a faq with lot of text, sample videos/shots but nothing to actually explain what the user did with ml and what the result was, or what usuability enhancements ml has over Canon. No, I'm not volunteering to add this to the site :-p but if anyone else has some spare time an "introduction" page would be a good idea.

The smaller camera models, and even the bigger ones like 60d are not very good at customization - Canon only allows for a very limited mapping like some functions to set. With ml it's generally easy to implement a more extensive system, I just added a non-lv meta key with timeout similar to the lv-shortcuts function.

The problem is that I can either hardcode some function mapping (what button does what), but with the current menu system is not designed to do a n:m mapping of one of all available functions to one of all available buttons that generate an event code. It's the same with the 600dplus Rebel ui in the recent pull request, there's no way for the user to choose what arrow keys do what.

Imho it would be a great step forward for ml if there would be a pretty ui that visualizes all available buttons, lets the user select them and then choose what functions should be mapped. There are plenty of Canon and ml functions that would be nice to toggle without going through the menu - either on/off functions (for example bracketing on/off) or binary toggle keys (for example toggle between one shot and servo af).

I'm not able to code such an ui, but I'd like to propose the idea to the people who are if the idea seems reasonable?

I just added the option to remember different af points/patterns to my sticky modes feature, it works fine.

* I am wondering if the afp_len is different for different points/patterns, or is it always the same on one camera model? As far as I see it, afp_len is always 7 on my 60d and thus wouldn't have to be saved for each mode or at all.

After much frustration, I realized the values in property.h for AF_MODE_AI_FOCUS & AF_MODE_AI_SERVO are wrong for my 60D ... imho something is completely wrong with short props like PROP_AF or it has model-specific values in platform/xyz - below are the values that are saved from the camera and work when setting it.

Doh, now I need some time off, I like taking pictures but this is frustrating - and I again realize your stellar work that has made the current framework possible.

Code Select Expand

diff -r db64fd3c5bdc -r 4e501b44d217 platform/60D.111/gui.h
--- a/platform/60D.111/gui.h Wed Apr 10 14:54:10 2013 +0200
+++ b/platform/60D.111/gui.h Wed Apr 10 15:38:04 2013 +0200
@@ -70,4 +70,7 @@

#define BTN_ZEBRAS_FOR_PLAYBACK BGMT_UNLOCK // what button to use for zebras in Play mode

+#define AF_MODE_AI_FOCUS 514
+#define AF_MODE_AI_SERVO 257
+
#endif
diff -r db64fd3c5bdc -r 4e501b44d217 src/property.h
--- a/src/property.h Wed Apr 10 14:54:10 2013 +0200
+++ b/src/property.h Wed Apr 10 15:38:04 2013 +0200
@@ -64,11 +64,9 @@
#define PROP_USBDEVICE_CONNECT  0x8004000a
#define PROP_MVR_MOVW_START0    0x80000020 // not sure?
#define PROP_MVR_MOVW_START1    0x80000021
-#define PROP_AF_MODE            0x80000004 // 0 = one shot, 3 == manual focus, 202 = ai (dumb) focus, 101 = ai servo (slightly better)
+#define PROP_AF_MODE            0x80000004 // 0 = one shot, 3 == manual focus, ai focus & ai servo are model-specific
#define AF_MODE_ONE_SHOT   0
#define AF_MODE_MAN_FOCUS  3
-#define AF_MODE_AI_FOCUS 202
-#define AF_MODE_AI_SERVO 101
#define PROP_MVR_REC            0x80030002
#define PROP_LV_LENS            0x80050000
#define PROP_LV_0004            0x80050004

I tried to add a 2nd level submenu to the sticky modes feature, but it didn't work - see near sticky_modes_display_values in https://bitbucket.org/hudson/magic-lantern/pull-request/72/sticky-modes-new-bracketing-sequence-delay/diff)

Did I do something wrong (certainly possible my these manual menu structures) or are 2nd level submenus simply not supported currently? Is there any other place in the menu structure where 2nd level submenus already exist so I have a template to copy/paste?

While adding some code I noticed one thing that doesn't make wading through the code easier: the PROP_HANDLER statements are all over the place and just happen to be near the feature they were originally intended for, not matter what happened in the meantime.

I know refactoring/relocating shared code generally causes a lot of confusion and merging problems, but for my 2 cents if you do anything like that sooner or later, imho concentrating all PROP_HANDLERS in one location would be a good idea, even if there are less static and more extern vars. The features would then integrate their hooks into the handlers, and this would make merging easier afterwards.

One example I just stumbled across was the PROP_HANDLER for PROP_AF_MODE that was taken by some obscure 5d3 feature, with just one line of code - and I didn't even realize that the whole handler was in a #ifdef and why the handler didn't respond

I can change drive, iso, metering, ae just fine - but the camera doesn't want to change the af mode ... any idea why?

Code Select Expand

lens_wait_readytotakepic(64);
new_af_mode = ONE_SHOT;
prop_request_change(PROP_AF_MODE, &new_af_mode, 4);
msleep(10);

I installed PROP_INT and PROP_HANDLER for drive, af, iso, metering and ae where they didn't exist - everything works fine (except af, see other question in thread). However in lens.c I saw that before changing the prop there is a lens_wait_readytotakepic() and afterwards a short msleep() - is this necessary or good practice for changing props in general like the ones I mentioned?

Code Select Expand

void lens_set_drivemode( int dm )
{
    lens_wait_readytotakepic(64);
    prop_request_change( PROP_DRIVE, &dm, 4 );
    msleep(10);
}