Messages

I just installed the new ML firmware 2.3 into my 5DMKII.  The green screen says install complete.  However, when I turn the camera off and remove the CF card with that had the ML firmware update on it and turn the camera back on, the ML firmware update does not show.  It shows the latest Canon firmware update that I had installed just prior to doing the ML update.  When I put the CD card back with the ML firmware file on it back in the camera, then the firmware shows up in my menu as the ML update.
For some reason, the ML update does not seem to stay in the camera software when I remove the CF card with that file on it.
Any ideas what could be the problem.

There is no problem; this is correct behavior.

You have a misconception about what the firmware update actually does.  All it does is turn on the boot flag, which tells the camera to go to the CF card if it is bootable and boot from the autoexec.bin file.  That is the only change to the camera itself, and no Magic Lantern code is actually installed to the camera.

To be able to run Magic Lantern, the camera needs to boot with a CF card that has autoexec.bin and the ML directory, otherwise it has no access to the custom code.  If the CF card lacks those files, or if you leave the CF-card slot empty, then your camera will simply boot the stock firmware.

Yesterday I updated ML to magiclantern-v2.3.NEXT.2014Jan15.5D3113 on 5D3 - earlier i used an September20-build with dualiso and rawvideo - and it works perfectly for me.
Then I want to test the DotTune-module - I never tried this (except with the old September and now this version).

Am I too stupid, is something broken (and I don't find it), or ..?

Hmm, your procedure sounds correct (thanks for being so explicit in your description!).  I've just recently played a bunch with the DotTune module on builds from last week, and I'm pretty certain that the automatic scanning works on my 50D.  Here are some thoughts:

• The menu for the DotTune module should display the current AFMA setting.  Does it look like it's reading the value you set through the Canon menu?
• If, instead of an automatic sweep, you configure the DotTune module to manually sweep from -20 to 20, does it work then?
• I see from your signature that you also have a 60D; can you try to see if the DotTune module works on that camera?

Edit: just tested automatic scanning with the DotTune module using the Jan 17 nightly build, and it works on my 50D

[menu_entry]

I've now done detailed time testing, and nearly all of the slowdown is due to unnecessary traversals of the menu_entry list.  I just submitted a pull request that dramatically improves the speed of the file manager.  The menu now takes under a second to open a 5500-file directory; build_file_menu takes ~230 ms and appears to scale as N now.  Menu closing is also really fast.

Hopefully yes, if anyone confirms the bug and commits the fix.

I removed the message and double-checked again that the automatic scanning is working properly.  Pull request submitted.

[X]

I just tested the module, and the automatic scanning still works fine.

With my 6d and 5d2, I rarely, if ever, get a successful Dot-Tune AFMA.

There is almost always a warning:
"Double-check the Focus Target"

90%+ of the time, there is a value for AF micro-focus that seems valid ... mid-way between the left and right side of the focus confirmation squares ... such as
__xxXXXXXXXXXXXXXx_________
results in something like -3, for example, which seems valid.

It sounds like you are, in fact, getting a successful AFMA determination, and you just need to check whether your Canon setting has been properly updated to that midpoint value.

There is a message saying "Double-check the Focus Target" in the "OK" code path, in the automatic scanning routine. The manual scanning routine seems OK, let me know if it helps.

That message can probably just be removed.  I imagine it was put there to encourage the user to make sure that the camera was not bumped during the process, but it's prone to misinterpretation, and it overwrites the AFMA message that's printed out just a few lines above.

Here's temperature data for the 50D (nightly build magiclantern-v2.3.NEXT.2014Jan09.50D109.zip)

Code Select Expand


21 25
27 27
31 31
36 36
40 40
44 44
47 47
49 49
50 50
52 52
52 54
54 52


It looks like it belongs to the 60D/650D/1100D group.

QuickSort or HeapSort should be pretty good. Or some other algorithm with O(n log n) complexity.

Mergesort has now been implemented.  I did a few time tests on my 50D, recording both the time it took for the menu to appear and separately printing out the time for just the sort:

Files	Total	Sort
900	<1 s	11 ms
2800	3 s	40 ms
5500	10 s	88 ms

Thus, the sort itself scales like N*log(N) as it should, but the rendering of the menu now completely dominates the total time and scales more like N^2.

The 50D footage is cleaner and you can record outside of crop mode with less moire than 50D.

7D has less moire in 1x but they are equal at 5x since its read without all that skipping.

In that first quote, is the first "50D" a typo and supposed to read "7D"?

50D nightly is back, thanks to ayshih!

Also 7D and EOS M nightlies are back, thanks to Pelican and jordancolburn, but that's already old news. They now have a tough job of backporting the new stuff from 1%, so your help is more than welcome (both testing feedback and help with merging the code from TL).

Now that the nightlies are back for these models, can you (or someone with permissions) edit the original post so that it doesn't immediately tell people to go to TL builds?  TL can be mentioned as an even-more-bleeding-edge option, of course.

Thank you very much Ayshih ! Just for me to understand better: do your maintained nightly builds contains all the Andy builds latest features here ? And will also contains more, when new TL features will come up and Andy will not keep updated with his builds ? Many thanks in advance for your clarifications ! 

At least in the short term, the ML nightly builds will still be missing features that are present in the (Andy's) TL build, but I'll be working to bring over everything I can from TL.  In the future, as improvements are made in TL, it may take me some time to bring them over to ML.  My effort won't be limited to just TL backports, but for the purposes of this thread, it's important for me to get input about what differences, if any, may be keeping you on TL rather than ML.

Good luck Ayshih - it's a lot of work but great to know someone is on it now! I've tried to get my head around porting some TL stuff back to the main repo but it's beyond me. I'm learning though.

Hopefully I haven't bitten off more than I can chew!

[mlv_rec]

The changelog doesn't show anything.
Is there some specific feature you would like to be tested ?

It'd probably more instructive to look at the Bitbucket commit history, because each nightly build's changelog only shows the changes from the previous nightly build (attempt).  I believe the only recent 50D-specific change was to add a warning if the FPS gets locked to 22, likely due to overheating.  But, changes not specific to the 50D need to be tested as well: for example, over the past few weeks when it was not possible to download a nightly build for the 50D, there have been tweaks to the mlv_rec module, and it's always good to make sure that nothing was inadvertently broken on the 50D side.  Tonight's build, when generated, will include improvements to the information displayed during LiveView.  Test away!

[magiclantern-v2.3.NEXT.2014Jan06.50D109.zip]

hello, trying to install the last nightly for 50D, I get an error about the FONTS.DAT file missing.
I copied the one in the stable release and the nightly did install but it freezes trying to boot the different modules (rawrec etc)
anybody had the same issue?

Thanks for trying out the latest nightly build!  However, I don't encounter either of the issues you've described with either of the recent nightly builds that are available (magiclantern-v2.3.NEXT.2014Jan06.50D109.zip and magiclantern-v2.3.NEXT.2014Jan07.50D109.zip, which actually contain the same code).  I do not get any error about FONTS.DAT missing, even though it is not there, nor do I get any problems with booting with modules enabled (raw_rec by itself, or all included modules).

Did you make sure to delete the old autoexec.bin and the whole ML directory before copying over the nightly build?  You may wish to try reformatting the CF card and starting fresh to make sure that the stable ML (2.3) works fine, then trying again with nightly build (again, remembering to delete all the old files before copying over the new ones).

Hi, all, I've started maintaining ML for the 50D, where one goal is to bring it up to parity with TL for the 50D.  So, it'd be really useful for me for those of you using TL, especially for RAW video, to try out the latest build of ML – the nightly builds are back! – and let me know what doesn't work as well, or at all, in ML.  You can provide feedback in the thread I've created.  Thanks!

[Installation:]

It's not exactly a "new" port, but after a few weeks of unavailability, the 50D is supported again in Magic Lantern!  I'll be maintaining it, such as fixing bugs and also backporting remaining improvements from Tragic Lantern.  Nightly builds are available again from http://builds.magiclantern.fm/#/, so I encourage all interested parties to download the latest builds and provide feedback.  You can add issues on Bitbucket or just comment here.  Thanks!

Installation:
1) Format the card from the camera.
2) Make sure you are running Canon firmware 1.0.9.
3) Copy ML files on the card and run Firmware Update.

Uninstallation:
1) Run Firmware Update from your ML card.
2) Follow the instructions.

[make 1100D.105]

Outstanding tutorial! I do have one problem, however. I am looking to edit the 1100D files, and despite moving the camera directory up one level as described in the readme within the unmaintained directory, it fails to build.

When I try to run make 1100D.105 like as mentioned in the tutorial, I get:

Code Select Expand

make: *** No rule to make target `1100D.105'. Stop.

After you've moved the 1100D in the file Makefile.platform.map, I believe the correct call is simply make 1100D (i.e., don't include the ".105").

All of the other platforms compile correctly. There are no errors, it seems to just skip past the 1100D directory. I do have a basic background in programming though this is the first time I have attempted anything like this.

If you're referring to the fact that a top-level make call skips over the 1100D, that's because the variable "SUPPORTED_MODELS" in Makefile.user.default (or overridden by Makefile.user) does not include "1100D".  Until you change it, of course!