Messages

Heh, I can't let go.

I see, and understand your frustration if a concept that has been put up with a lot of love and work doesn't receive instant approval.

However for the sake of matter of fact discussion you might want to put things a little in perspective here - we're all ml enthusiasts and interested in improving it. That's why I'm not a fan of "habituated pattern shared by ML users" or "habit-skewed thought experiments" arguments: if you simply deny the willingness or ability of others to come up with valid assessment in the first place and dismiss them as "platitudes", that's immunization against critique and doesn't allow for any exchange in good faith at all. I would really like to ask you please cut back a little here?

As for "My core proposal has not been tried": Well, implement it and give us a pull request or find a dev that is enthusiastic enough for it to do it, otherwise the discussion has to be centered on your (very nice!) mockups

I caution people about what "expert" or "pro" product implies regarding usability. Well designed professional products should be harder only for the power and control they provide. Unfortunately the refrain, "this is for experts" is used to excuse unnecessarily cryptic design.

Either you misunderstood or wanted to misunderstand: Where exactly did anyone say that a cryptic ui is fine because we're experts? I'm really having a hard time to comment at this at all, but again the difference is that for "pro" shooting speed is imperative even at the cost of a required higher familiarity with the ui - that's why pro camera bodies have buttons all over the place and a Rebel has a touchscreen, another example would be the single-function button layout of "entry" 60d/6d vs. the multi-button layout of "pro" 5d2/5d3.

These two needs cannot be met 100% at the same time, though there are ways to do something like qick access to features otherwise hidden deep in menus.

On the other hand, new users must give the current UI a chance because they have no choice. They/we are certainly confused.

Just out of interest: Who's "we"? Afaik the current ui is only in the latest trunk and there hasn't been a chance for a wider beta testers group to return their experiences, or am I mistaken since I didn't folllow everything here?

You're focused on 2nd order problems. By taking such a strong position on full-screen (sub)menus, it trades away core benefits of a UI platform that must then be explained away as "we don't need that". I'm confident ml users are smart enough to use full-screen submenus.

You're confusing cause and effect - I don't hate fullscreen submenus and am fishing for reasons to support my position, it's the other way around. I see a drawback in speed that has to be overcompensated by a large gain by full screen submenus - and in search of that gain I asked how much 3rd level menus are required, that's not "explaining away".

The other potential gain of full screen submenus is more space, so I was wondering how this gain is used in your mock up - and imho the left/right icon is nice, though imho not vital since it's very intuitive to figure it out. If you're stating that smart users can use full screen submenus, I guess you're not trying to be insulting but are missing the entire point: it's not about smartness, but about speed - and as I stated that my experience with full screen submenus is negative - and not in theory, but in actual practice on my very own camera just as you want it.

BTW I understand that the current left-hand icons do more than show toggle state, but I feel (well, I know) that those icons are vastly, grossly overloaded.

I am absolutely not against improved icons, though of course limited space calls for more integration. However I don't really feel like isolating the matter of fact arguments from your last post to endorse them because for example the "one hand navigation" seems to be mixed with personal sentiments. Reading back the entire thread is a suboptimal option, because many former ideas seem to have been cancelled to it's hard for me to figure out the current proposal except for the latest mockup - and I commented on this.

Not possible to access the top display, Fast ML item toggle is a thing on my to do list for dialog options, it will require two click but will be more configurable (with more item to toggle instead of just one.

Certainly an improvement and I'm looking forward to trying your source pull, though this feature request is about *one* click access really - when shooting an event in full m you don't want to use *any* menu but simply press a button (i.e. most conveniently SET or maybe even DOF PREVIEW ) to switch a binary preset, so it'd be nice if there was...

... req: a ml option to put any on/off toggle enabled menu item to a selectable button plus an option for confirmations on/off (but as written above I'm still most interested in switching expo lock with a button):

So maybe like "Prefs->Quick access buttons" with submenu
-> binary option to allocate
-> button to allocate to (SET/DOF/...)
-> toggle confirmation (none/beep if on/add. double beep if off)

I've did a pull request for adding 5 c-modes to ML, you can see the code in the main tree. Also you can find a build in the new UI thread (but works only for 600D until someone port it to other models)
Here and here more topic about it

Well, my idea would be not only to save select values like but the whole thing just like the Canon c modes - if that's not possible I'd like to add some variables to the list I think should be integrated in the save/restore procedure. The current expo presets with limited variables are nice and should be kept, but imho they don't replace more full fledged c modes (that's why Canon is so "economical" with the number on cheaper camera bodies).

The code currently only available for 600d looks interesting though, I hope it'll be ported soon so I can try it on my 60d!

RED: For now works only in M mode (for safety reason).

What's the catch here? If the problem is overwriting Canon variables, restoring the ml c modes could be reserved to the cx main dial position(s) where variables are never saved to nvram?

[auto iso]

In Manual I don't think this is necessary as changing the shutter speed or aperture basically gives you the same result.

Please read again - it's for m with auto iso so t/av are locked but the camera picks the iso sensitivity - great setting for example for sports where a fixed depth of field and shutter speed is wanted but you don't want to waste iq by using a too high iso setting.

You could gain a somewhat similar effect by using the current ml auto iso in tv/av, but it's not really the same and as I wrote many pros want to shoot full m ... but on reflection the "ec on m" option might even be added to the "ml auto iso" submenu.

pico C is mainly about binary size. add it and see if your camera boots.

Ok, didn't know that - so I enabled "CONFIG_CONSOLE = y" and "CONFIG_PICOC  = y" and it boots ... I'll look trough the thread http://www.magiclantern.fm/forum/index.php?topic=4362.msg25677#msg25677 and hope I'll figure it out :-o

comment out things in features.h in the platform directory

Yes, I did, and that's what I'm talking about ... my 60d has 39k+1239k free memory - is this enough for picoc?

If not another feature macro for a/v would be nice so I could "#undef COMPILE_AV_STUFF" to save further ram because I expect the whole video recording/bitrate/... code should take quite a lot of space.

Even if I'm potentially introducing a case for 3rd level menus (which I wouldn't like that much, see ui thread) :-p ...

... the current Handheld Shutter customization from 1/2...1/125 obviously is very static, it needs at least an option to set the upper limit. But the really interesting addtion would be to to add a dependency on the lens focal length (or zoom position), since that's what causes handheld shake. So I'd propose an additional "auto" option that enables handheld mlu when the shutter speeds drops say 1 stop under 1/focal length, which is the standard criteria for "hand holdable ". But of course some further intelligent behavior or customization would be nice since IS lenses can handle even slower speeds w/o mlu. What do you think?

60D I think is stuck with what its got.

Doh, I've got a 60d :-p ... so your call if it's reasonable or too much a hassle.

The recent Expo Lock is a great feature and might even draw pro shooters to ml because with it you can quickly set the dof while shooting full manual. The problem is that when shooting an event you don't have time to flip through the ml menu - to req #1: please add the option to toggle the feature through SET when outside ml. As a follow-up req #2 there would have to be a fool-proof confirmation if expo is locked or not (I'm fresh out of ideas here, can ml access the top lcd or the viewfinder bar?) - when in doubt a beep when locking (and maybe a double beep when unlocking) might also do.

Like "ec on m" this falls into the category "potential ml killer features": Most cameras have a much too limited number of C settings on the dial (or no one, doh), for example 60d has 1x, 6d 2x, 5d 3x. It would be a very great, stunning and stellar (did I mention great?) feature if ml could read the Canon settings from a C position and restore them though the ml menu. Afaik the settings in the C modes aren't saved to the camera, so I assume restoring a C set through ml in C mode should be safe?

The 6d & 60d are low on memory, it'd be nice if there'd be a compiler switch to turn off the audio and video (recording, not live view) features for people who never do video (i.e. me :-)) and want more ram. I'm posting this as a feature request since I guess a seasoned dev can identify the source code to wrap in a switch in no time, while it'd take me a long time to find it. I don't know how much memory would be saved tough & thus if it'd be worth the hassle.

A feature in constant high demand though still absent from eos1 cameras is exposure compensation in full manual mode. The problem is that with the current behavior, when using auto-iso in m you're stuck with the camera's metering, even if you know the camera will get it slightly wrong or even constantly wrong to one side (for example the 6d is said to underexpose, so you're loosing dynamic resolution and you cannot ettr). Do not underestimate this, this is a big issue for pro event and esp. pro sports photogs who usually use full manual.

Request: new item "Expo -> EC on M" settable in 1/3 iso stops, only applies to full m mode and the ec is simply added/subtracted, the two dials keep functioning for setting aperture & shutter speed. If this is implemented it'd need some safety net though (like "Warning for bad settings") to prevent people setting the ec and then forgetting about it, potentially resulting in mis-exposed shots.

cant we make two appearance types?  beginner/poweruser
the one will open submenus/options with set and follows some of stevefal proposed usability guidelines
and the other is more like the current style as we know it.

I didn't look at the current menu code, and some more seasoned dev could tell how much code complexity would rise - and size, since it'd probably be a runtime switch and not a compiler one. But I'd advise more time trying to find a compromise or a decision, it's not like the current ui is broken, so no need to rush?

Concerning the latest proposal: I really took the time and compared it step by step with the (very nice) current trunk ui. Please forgive me for not reading the entire thread since multiple proposals seem to have been tried and withdrawn, and I don't want to backtrack that - so please correct me if I've got some intention wrong.

Again sorry I'm very late to this, I really do applaud any effort to make ml more accessible and open it to more user groups - though imho the people ml should aquire next are pro shooters.

* Q button for enabling/disabling and SET for menu: Yes, the old behavior is not consistent with the global draw item. however, the action I do most is enabling/disabling and the SET button is much easier/faster to reach than Q, so I'd opt either for the other way around (some change to the global draw switching to match the rest) or just for a way in the ui to make the current behavior most clear.

* full screen submenu: I commented on this above, and you won't be surprised that a new "back to menu" icon doesn't make such a large difference for me :-o ... I'd definitely vote for the current trunk menus and I'm confident ml users are smart enough to figure that left/right changes the value w/o an additional <> icon.

* menu key for back: I take this is meant to enable 3rd level submenus? First off, I switched menu with trash, so the "<menu" icon is confusion for this case. And is there really a pressing need for nested submenus? Afaik it's a usability fact that unrolled menus are faster to recognize, at least in web pages. My real issue with the q/menu proposal is that it eliminates the right hand only control, which is one of the few reasons I like my 60d over the Nikon d7000 and the 6d over the 5d3 :-o ... I seldom switch Canon settings (set to trash on my 60d) since these are accessible though the camera's button controls, but I often use the ml menu (set on menu).

Did I overlook any other vital changes you are proposing to implement over the current trunk ui?

Btw: If you could compress the gif as non-progressive it'd be easier to step though it, the tool I found (Animated GIF Frame Extractor) only shows the delta images ... or is there any better tool to manually step through the gif?

@Marsu42 I don't see the problem with full screen submenu, there is a bigger title with more words telling you where you are and an icon to show you that it's a submenu. And to get there you have to be in the main menu item before so how can you "lost" yourself?
Instead we get a lot of space were cropmarks, focus patterns and other thing can be bigger, more and more clear.

Ok, I'll try once again for peace and understanding's sake :-) ... as I wrote above, I do acknowledge the benefit of more space. But to reiterate the drawback: If the submenu is laid over the opaque main menu, I still have the same visual cues at the top, it's just some added information (the submenu). With full screen submenus, the whole screen is replaced and I have to gather new information (the title bar) to see where I am, and this costs time and causes some confusion because I cannot see that I'm say in the movie main menu (Alex' latest build fixes that problem).

I'm 99% sure that the result of a usability test "change these 10 settings in the shortest amount of time" would be that full screen submenus are slowest.

Also full screen submenu are more clean, don't have problems with the icons and they just work good.

I see your rationale, that's why I mentioned GNOME. Not that a full screen (aka Win8) couldn't make sense on a small screen device - it's about either "function follows form/design" (GNOME) or "form/design follows function" (Bauhaus). Personally and from my experiences while shooting in the field, I don't want the "cleanest"/most stylish look, but the most usable - which is in my case the fastest.

This behavior is implemented in current trunk (4f4cf19c3177). Any objections?

No objections from me, actually looks really good & usable and I feel at home again, thanks :-)

Hi all,

Disclaimer: I admit I didn't follow the recent ui threads, but often compile the ml trunk to get the latest features. So it might be seem a bit like nagging if I only post if I dislike something, but imho either the GNOME ("You don't need/want that feature") is the way for ml nor the Windows8/GNOME ("People get confused by windows, you want full screen") submenu commit https://bitbucket.org/hudson/magic-lantern/commits/31c81a3d8fead31693417ee826299e852f213f12 ... I repeat what I wrote elsewhere because I was told this is the correct place.

First off there probably is a different usage style between amateurs/newbies and professionals, just look at the camera bodies Rebel vs. 5d3/1dx with more buttons - less complexity eases the way into using a dslr and ml, but quickly limits you when it slows you down achieving your goal. Since I have been using ml for quite some time, I'm in the latter group, and I'd wish ml would gain more appeal to pro and advanced photogs now that the code is more stable.

So here it goes: Imho the full screen submenus are a major slowdown for navigating ml - I have to re-think "where am I?" every back & forward because all of the screen changes. I see the rationale to gain space for more verbose settings & descriptions, but imho it's too large a regression. Ml recently has gained great features that could be used for pro shooting like exposure lock, but here a fast and non confusing navigation is everything - either with many unrolled menus like on the 6d, or with submenus like on the 5d3 but with a navigation bar that tells you exactly where you are.

My issue is not with debugging/"set once and forget" stuff but with the usual shooting settings because you need to be able to change the latter quickly in the field, having two Canon/ml menus is already an (acceptable) complication, but I'd avoid anything that complicates flipping through and setting things like bracketing, exposure lock and so on. I'm looking forward to the ml "My Menu" for the same reason...

Btw: As for the rest of the newer ui appeal in the current trunk: Well done, the colors and greyed out option make navigating much easier (until using a submenu that is...).

i'd rather it not do full page so you know its a submenu.

+1 and just my 2ct: Just tried the new menu & ui (commit 31c81a3) and think the full screen submenus are a major slowdown for navigating ml - I have to re-think "where am I?" every back & forward. Actually it looks like ml is now Windows 8 tile-infected

I see the rationale to gain space for more verbose settings & descriptions, but imho it's too large a regression. As for the rest of the newer ui appeal: Well done, the colors and greyed out option make navigating much easier (until using a submenu that is...).
   

The included phi cropmark for the se corner should be accompanied by the "missing" 3 others for sw, nw & ne - with just one it looks more like a tech demo, or am I missing something here and the bmp can be mirrored inside ml?

They should be pushing their hardware/software for every model. They aren't in competition with ML, they are in competition with everyone else. It was all fun and games while others were playing catch up.

Correct, and every second post I do on the CR forum is complaining about this, the current Canon execs deserve to get fired. But do you think ML is here to influence or change Canon corporate policy, do you feel ML even could?

So how are you going to feel if Canon releases a 5DC that  is twice the price of the mark iii and records 2k but it has the same exact hardware? Then I guess going by your logic ML should not touch it since if one can afford a mark iii they can afford a 5dc

My logic is different from what you understood, so I'd like to explain it, sorry for the lengthy post :-o

Imho it is absolutely legit to differentiate software by features/price, on computers this is often done: You can "unlock" different versions of a software by entering different keys, though the software itself is the same. Do you feel cheated if there is "Software X basic" and "Software x pro" for different prices? Would you feel less cheated if "Software X basic" was physically missing some software components, even if it doesn't make a difference to you at all?

Canon is differentiating the 1dx/c products for general - though pricy - use as the 1dx and with a feature set that is clearly targeted for professional use with the 1dc. And if you buy Canon, you buy their cps support with it, a feature often overlooked, so it's not just Canon vs some other manufacturer that has good features, too.

A dslr is basically a computer, the the same logic applies. It's crazy people feel bad because the hardware is the same. I own a laptop, and it would run $500 Photoshop (with features I'll probably never use or even discover), but I can only afford the $90 Photoshop Elements. Do I feel cheated by Adobe?

The whole 1dc hack issue is just an excuse for saving money and legitimating it with "The manufacturer rips us off". This has been done n times over, even software cracks ("games are too expensive) destroying whole platforms like the Amiga line of computers. Believe me: I do like to simply save money in less-than-ethical ways too, esp. at big companies' expense - but at least I'm clearly saying so.

And ML (well, if I'm contributing at least) should be there to accompany Canon, not fight it because...

• * the 1dc hack is only saving money for rich people that can afford a 1dx and
• * it's strategical madness because we'd surely like more corporation from Canon like the ability to control non-lv mode - but they can make life much harder for ml like voiding warranties. And a dslr doesn't run user code, you cannot root it by exploits, so if Canon decides to encrypt their firmware & disable the main ml boot hook that's it.

Let's stick to the "modding" that ML is best at, adding new great features while backporting non-key elements like "3+ bracketing" to the lesser models like 5d2 while Canon obviously thinks only the 5d3 should have it - there are enough new features on the 5d3 left. I know the differentiation between "key element" or not is fuzzy, but "cracking" and obsoleting a whole camera model is clearly beyond it.

I'd like to grab the current aperture value (Tv mode) or shutter value (Av mode) or iso (M with AutoISO), but while focus stack is running the camera doesn't measure these values until the next pic is actually taken. How do I get them - simulate half-shutter press, and with what command?

Background: I'll fill my own feature request again :-> and am adding an auto-cancel if lighting changes too much while running the stack.

1. Um, to make extra-sure because I understand this can really screw up things (and I'll try it in C mode): Where do I get the correct "size_t len" for prop_request_change from? Since the range for image review seems to be "0, 2, 4, 8, ff" I guess the lenght might be "1" byte, but all other values in the source code are either 2 or 4 - argh...

int new_image_review_value = 0;
prop_request_change(PROP_IMAGE_REVIEW_TIME, &new_image_review_value, 2);

# --

2. _get_prop is disabled in property.c as "not reliable" ... but there is an exact duplicate function in prop-debug.c? So does this mean that I can save values like the old image review time and restore them after some time or isn't this safe?

- Let's say user puts the card into another camera. ML will read from config file that it has to change something, and it will try to do that.
- Let's say the config file gets corrupted somehow, and as a result, ML will attempt to set an invalid value. Of course, most things have range checking in ML, but still, I don't like the solution.

You could tie the config file to some singular camera specific value (like the serial number if it can be read) or something ml-generated (like combination of camera type + shutter cycles) to prevent setting being shared between cameras. As for the corruption problem as you said a range check would solve the problem. Still, doesn't matter to me anymore since I now know what ml is doing.

If you shutdown the camera normally, the shutdown handler will restore this setting before telling to dryos "ready to shutdown". If you take the battery out, the AF remains moved to back button.

Ah, I didn't realize that yet, should be sufficient, too ... maybe it's a recent implementation - because I remember always ending up w/ the af setting changed :->

It can - with prop_request_change. The problem of doing this is that those settings are permanent. So if you take the battery out in the middle of the operation, you end up with the setting changed.

Thank, sorry asking really basic things - is there a faq on these basic functions (if not, this question should go into it)?

* And the settings being changed by ml is really irritating when you don't know what's going on, I know this myself. Maybe a wrapper around prop_request_change would be a solution that saves it & sets a dirty flag on the card (drawback: many write operations). That would enable ml to restore the old setting after the battery was taken out. There could be an option for seasoned users to disable it like "write config file"), but for newbies it would be a good thing.

* I still think there should be a standard method to cancel whatever ml is doing, that would defeat the need to take the battery out and give the user more subjective control (like help! I've forgot to reset the hdr exposure shots from 7 to 0, and now my focus stack is taking 200 pictures instead of 50!).

I know that ml cannot control focus w/o liveview (doh!), but is there a way to start liveview w/o the camera turning on the screen? That would at least simulate a quieter operation, I'd like to prevent focus stacking to constantly flicker between shots...

If "Image Review" is set focus stacking is slowed considerably... I guess because there is this loop with get_out_of_play_mode() there is no direct way to set Canon variables, i.e. disable "Image Review" before starting the stack and re-enabling it afterwards?