Messages

There are no active developers with the camera, so no.

 yes, it should be possible to route audio via the usb/av port.
It's not something that is doable in a short time frame though. We don't even know the maker of the chip

Everything is doable provided enough time and a developer with a camera.

What connectors does the camera have externally? I guess there's no headphone out right?

Is it recognised by a Linux distribution? Boot up a live cd or USB, plug the card in and see

Proposal:
Wait for the cleanup branch to be merged. I'm ironing out one critical bug then it's good to go.

Branch off ML, Tag the version as 2.4.Next in the nightly builds

Disable module that are known to be unstable: suggestions?

Wait for user feedback.

Only fixes are allowed. No new features can go in, but they can get removed as we see fit

Expected outcome: either we strip dual iso and raw video or we are just better off with nightly builds

If you come across a CR user with that issue please ask him for a video

Uhm, can you show a video of such delay? I bet patching that it's something that I would not normally allow in core ML due to use of cache hacks. But maybe we can work out something

And leave all the fine 70D folks out in the cold? Me not likes it

How about I teach you how to maintain the 6D port? It's not an issue if you are a complete novice. We've all been.

I was thinking of doing the port using a blog to track down every action I do, and having at least one follower doing the same things would help quite a bit

I'm 90% sure that the battery check is out of reach for ML as it runs on an entirely different microcontroller

And who will decide whether a build is stable or not?
It's a work load us developer can't take. Testing a build to make it stable requires long and boring tests.

I can only state once more that you community is free to come up with whatever idea to make a new stable build real.
I'll provide all the tech and backend help you guys will ask for (assuming it's reasonable)

[a speedy or even a successful port is not guaranteed]

Between the forums, his paying job, his current development workload, family, and whatever else I don't know about, that seems fairly reasonable to me.  *shrugs shoulders*

It was more like a "duh, let's check if we can do it before going the donations route ", but your observation is spot on.
Let's say I take on starting the port by getting a camera donated by the community. Whoever decides to donate must bear in mind that a speedy or even a successful port is not guaranteed. Not even having an actual "hello world" running on the camera guarantees it.

Truth be told, I'm more interested in playing with the WiFi capability than anything else (Did you say online module repository and installer?). The 70D will for sure bring some changes in how we handle some conflicts between Canon UI and ML and having a somewhat clean port will take time

That being said, shoot me a PM with subject "70D Donation" if you are still willing to donate under the above terms

1% is still contributing to the project. Technically speaking he's contributing more now than he was before. It may not look like that from a user perspective but he is.

So, little status update on the 70D:
Good news first:
  - Got most of the stubs
  - Got some constants

Bad news:
  - Audio API has changed once more. This time stubs hardly match.
  - We probably need new hooks to hide some canon stuff in LV

Right now all is left needs a camera for more than a couple of hours. I'll probably push the 70D branch next week but I doubt it will be in a usable state (maybe hello world of a bit further than that)

The underlying Canon dialog times out. I'll check the eosm  maybe there's one that works better

May I request that the bars be made a lot 'thicker' or that a big green dot be made to appear in the MZ window when focus is achieved.

Sounds reasonable.

Can you provide a picture of the "new" desired green bars width?

I think the histogram in HDMI mode uses the RGB LV data and not the raw one. The RGB data is affected by picture styles and such.

I'll look into it as soon as possible

Regarding the meters patch, it does not apply cleanly. It needs to be fixed agains the current ML code and re-submitted.
You can follow progress here
https://bitbucket.org/hudson/magic-lantern/pull-request/457/650d-700d-maybe-ok-to-turn-back-on-audio

See:
http://www.magiclantern.fm/forum/index.php?topic=11080.0

and
http://www.magiclantern.fm/forum/index.php?topic=9848.0

We call it a killer application. Better not waste the opportunity

That is good enough for me

You may or may not hear from me soon (good news)

And you just admitted the same warnings on ML. So, now what is the truthful way to make people not use T_? What about the guy I just mentioned who claims his loyal faith in whatever ML tells him? He based it on what ML said to scare him about being unsafe. You didn't comment on that.

I did. There are features enabled in TL that caused bricks in the past like movie mode remap or assertion patching and that have been removed from ML since for that reason. These make TL more unsafe than vanilla ML as we have documented proof of bad behavior in the past

Sorry if it is an old question or if you already stated it.
Are planning on relasing the source code under a free software license?

ML warns people about using ML at their own risk and possibly bricking a camera. So what is the difference there? A double standard?

Call it however you want. I know some features caused bricks in the past. I use ML on my camera. I'm not taking responsibility for merging them then seeing my camera brick because of them and because I accidentally enabled it.

I won't promise to provide support either if you enable it then have troubles later on.

Btw yes it was me and yes I was impolite for not getting back to you guys. What that spreadsheet did was demonstrate the the ML eosm port was not really out of date and that it could be re enabled in the nightly builds.

Do you want to see how a wrong patched assertion or movie mode remap or enabling sraw can cause a brick or a semi brick? We got professionals using their cameras for paid gigs and we can't afford even the possibly of such things happening.

We can discuss on the merit of hiding the TL sections, and I do agree that it may not be the best solution. But sacrificing stability for things that are known to have causes issues in the past is a big no no.

well, if that is true, then let us talk with 1%. I am concerned that he told me he can now fix the EOSM to have a headphone output. Then all this stuff started here and we can't get what was wanted by many loyal forum users, like myself, who have asked for this and waited patiently.

Then the EOSM thread is waiting for you.
Keep in mind that if said changes involve patching assertions in canon code they won't likely make into ML any time soon.
Assertions are there for a reason and we don't mess with those as they could cause the camera to enter an invalid state and potentially brick.