Messages

shot 8gb of 720p 24fps sample footage, working on processing this now I'll post it up when it's done. Just some night shots and random footage at a store.

Right now 633x is the fastest SD card you buy buy afaik.

For 5d2, I found all stubs, but the function lv_raw_dump() seems to be inert in the 5d2.. doesn't dump anything!

after I call lv_save_raw() *(*(0x1D78) + 0x3F4) points to the raw buffer's location. Using bmp_hexdump() I can see image data there changing with each frame, but only about 30 bytes of it from where the buffer pointer starts..

I tried dumping 4.2mb from here but all I got was a blank file.

lv_raw_dump() hangs up and never returns, dumps a blank file (0bytes).

damn.

5d2 benchmark:

I think I found prop changes by hijacking the PropMgr manager and printing to console. The other problem with the 5dc was there's no full-press (and no way to find it), I had to dig deep just to find half press (using EMState changes to know when it happens). 5dc was quite difficult to port

So far I've enabled some small feat like sensor temp and warning for bad settings and removed all what is not working. I have some problem with spotmeter, zebra and magic zoom, once disabled they can't be turned on in any way.

Other things tried are focus patterns but the menu item don't shows up if enabled and camera didn't recognize the lens attached.

EDIT: I've fixed compiling with picoc enabled but without any script on card ML loads fine (and no scripts menu), with scripts loaded in ML/scripts/ the blue led stay on at boot and ML menu don't show up pressing trash, other than that camera seems to work like without ML.                     

does the 5dc have the free memory available for scripting? (iirc it was pretty low on free memory)

got this assert running the test suite:

Code Select Expand

ML ASSERT:
PROP_LEN(80020015) = 0
at ../../src/property.c:293 (prop_request_change), task ?


Magic Lantern version : v2.3.NEXT.2013May05.5DC111.scrax
Mercurial changeset   : 9f1a1235a182+ (unified) tip
Built on 2013-05-05 21:14:32 by [email protected].
Free Memory  : 0K + 2443K


that property corresponds to PROP_REMOTE_SW1 which from what I recall, doesn't exist in the 5dc (it's missing SW1/SW2 properties). I remember this is the reason we can't trigger bulb exposures for bulb timer. I'm not at a developing computer atm (busy this week at work) but go to property.c and see what needs to be IFDEF'd out for the 5dc for this property. The prop len returns as 0 because the property is inert / doesn't exist in the 5dc.

afaik the 5d3 will be the only camera that supports clean hdmi out (with the new update from canon)

Added raw histogram.  Fixed adapter ring expo. Turns out there is a zoom box and you can move it around with your finger... the mz flickers once when the zoom box position changes but its kinda cool. Also works to have mz on 1/2 shutter and when it focuses it zooms in on the area its looking.

Console still not working, no characters show up even when I enable console debug.

i think it's a backend bug, i can't make it work on the 6D (from main repo not yours).

So do you think Canon could enable 1920x752 RAW 24p recording even if you guys don't quite get there? It's just a matter of compressing the DNGs now isn't it?

I don't mean to sound pessimistic, I reckon you guys are gonna nail it.

the current bottleneck for everything is sd/cf card technology, cards aren't fast enough yet

s thanks , so i have to easy upgrade to 113 from canon firmware and after install ml?

just install the firmware update from canon and put a prepared card back in with a 113 bin on it, no need to enable the bootflag again (it isn't affected by firmware updates)

Is there a chance for DNG silent pics on other cameras, especially 550D?

In theory yes, the only question is how big will the silent pics be (since buffer size depends on the camera). should be the same resolution as normal silent pics (it is on 6D i know)

Synced MZ on EOSM... input 15 old state 5 on evf state fires every frame... unfortunately this doesn't work for display filters.

For image parameters we are catching Display state just one state too late. It is firing right at the end. On 6D it would fire one transition before. They are both state 1 but on 6D there is also a state 0 that comes after it.

On 600D we can't sync because both input 3 and 5 happen on old state 5. The sync function would have to  run at 1/2 speed somehow. Fires twice as much as needed.

int skip = 0;


skip = !skip, to toggle it on/off?

void SetGUIRequestMode(int name) {}


this is needed by ML, it should be a stub defined in stubs.S

Well its still freezing after beep and I don't see anything in the logs.

For menu while recording:

Redraw flood needs to be disabled. It can't open the canon dialog in the backround. Also guirequestmode of 0 means the buttons don't work. Setting gui request mode to ML mode like 90 fixes the buttons but when you come out of the menu it doesn't go back to 0 right, you lose all events and if lucky can press play mode to get them back after stopping recording.

Is assert working on this camera?

ML assert? should be

Hundreds (thousands?) of hours in IDA studying.

This was my only lesson for assembly language (didn't even know what it was before);
http://magiclantern.wikia.com/wiki/ASM_introduction

It took me a year to understand what the stack is, as I had no prior knowledge of programming at anything lower than Visual Basic (which is really high-level). After that things started making more sense

Yes on 5DC format is erasing all stuff on the card. This may change in future, but no guarantees.
Better use "Erase All" when you want to empty your card.

i've had some close calls with that erase all option while in the field, careful

Spent some time studying audio code in the 6d, it appears the code is almost identical to the 5D3, except for the addition of a new StateMachine, AsifState, and a slew of semaphore checks which is what's breaking beeps / test tones on the 6D. These semaphores aren't in the 5d3 so there's no issues.

Either we need to patch all of the semaphores out (last resort way, hacked), or study the state machine and see if we can inject some state changes required to stop Asif successfully.

Using the built in function to start/stop a beep works:

Code Select Expand


call( "StartPlayWaveData" );
msleep(5000);
call ( "StopPlayWaveData" );


but we can't play custom beep tones with this method, and my attempts to change the buffer used for the tone didnt' work either. This is how Alex implemented beeps, by studying this function and seeing how it works underneath this wrapper function (so he could pass custom tones to it).

Start asif works, but StopASIFDMADAC doesn't return, so at some point a semaphore check is timing out and causes err70. In StopASIFDMADAC, the call to (i think it's) TaskClass_TryPostEvent() returns 0 which causes the lockup. It returns 0 probably because the states are all messed up with AsifState, since we didn't trigger any state changes to start the wav playing.

I'm gonna try to work on this more this week, but at least we're making some good progress to understanding the real underlying problem.

[NIGHTLY BUILDS]

I think we can adopt a release system similar to Cyanogenmod:

NIGHTLY BUILDS

Are HIGHLY experimental. Do not post issues to the issue tracker. Chances are the CM team already knows about the issue and are working to fix it. Be patient flash the next nightly. Complaning about battery life or any number of issues will not change a thing as to that these are EXPERIMENTAL builds!!!

M-Series

Something we have learned over the past few months is that if you don't release, someone else will do it for you. Since we are open-source, we absolutely encourage it! Unfortunately, the quality of unofficial builds can vary, and we are serious about quality. Of course nightlies are always available, but we realized that having something that is a bit more stable on a more frequent basis is important. Starting now, we are rolling out our M-Series releases. M-Series builds will be done at the beginning of every month. We did a soft freeze of the codebase for the last week, blocking new features in order to stabilize. Our plan is to continue this (assuming that the response is good) up until stable release, and onward.

We aren't exactly sure what M stands for. "Monthly", "milestone", or perhaps "MINE ALL MINE!". Whatever it is, I hope that we are meeting the needs of community.

M-Series builds will be available under the EXPERIMENTAL tag. The filename will include the date stamp as well as the M version. These builds should be stable enough for daily use, and we encourage feedback and bug reports.

RELEASE CANDIDATE

Everything is believed to be working at the time of release.

got lots done since yesterday, working on fixing up the audio stuff now.

CONFIG_PICOC = n in Makefile.user.default and the following declarations in dummy.c did indeed produce an autoexec.bin file.

int was_sound_recording_disabled_by_fps_override() { return 1; }
int fps_should_record_wav() { return 0; }
void movie_tweak_menu_init() {}
int hdr_video_enabled() { return 0; }
int get_digic_iso_gain_movie() { return 0; }
void SetGUIRequestMode(int name) {}

I'm going away for a few days, but I'll see if I can brick my camera with this next week   Thanks!

glad that worked for you!

I'm not up to speed on the touch screen yet but I think this thing seriously needs support for it.

So there has to be an X/Y register or location somewhere.  Once that can be read my idea is:

1. Hijack Touch input from canon so we can intercept events.
2. Make hot corners... like windows 8. Seems simple and one could be ml menu, one could be mz, etc.
3. The junkie menu should already have X/y for the buttons since it draws them all on 1 screen. I think this would be a good way to interact with ML menus via touch.


For vsync, evf state is pretty good. 60P MZ is pretty much flicker free. Maybe use that to sync anamorphic,etc. I'm getting original problem like 6D where the overlays don't draw and F/S mz doesn't work. I'll have to look and see if display state sends anything usable.

BTW; not seeing lines on EOS_M when using FPS override with timer B.... also the videos are baseline profile... this is digic V?

M is digic 5 yes, as far as touch goes, here's some testing I did:

lines are present, here's a 9 hour timelapse showing them getting worse over time:

Joined ML about 2 years ago when I had 500d. I have a background in programming (moreso, interest in it because i didn't know much before ML). I am a photographer on weekends like you, but I shoot electronic concerts / night life.

Other than ML, i enjoy working on cars and cooking. cool thread

Got the EOSM, going to start messing with it. Prop LV lens is different yet again... the filters dont work... how do you even activate MZ?


Lots of work on this one, going to be a PITA but might make something of EOSM yet.

Yep... hard to get those fancy vsync features working... but a question:

Why is vignetting correction applied twice? Once from Vsync and then again from state 4->5


Can beep now... Needs patching going to try to do a better job and jump the asserts instead of no-oping them. I was doing little endian before it wasn't working.

Audio *MIGHT* be easier on this camera... the audio IC writes/reads look more like they are sending commands not loading a struct and shooting it all at once. There are 2 headphone powerup commands and a monitoring command.

vsync is tough on this camera, it will take some tweaking.

- good job on beep! i didn't even look at audio, i was too busy getting menu and stuff working.
- for MZ, it's best to just set it to always on, because i was yet to find some indicator that focus was changing (I found one status register in memory that changed when focus was changed a lot, but nothing very accurate / fine).
- vignetting, idk (happened during random commits? haven't really really worked on this since the fall)
- display filters, not sure - like you said the prop is changed now.

Ask me questions and i'll bring you up to speed. Glad someone is at least working on it now

disable picoc (probably not enough ram anyways) and add dummy stubs (fake functions) with the names that the compiler complains is missing (see dummy.c in platform directory, put the stuff there).

the error about abort is related to libc.a, I forget how we fixed it last time I saw this..