About forking Magic Lantern and the support that can be provided on this forum

[gary2013]

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.

I have been to that eosm thread many times, as you know. I have supported and worked closely with anyone that has shown concern for the M. What happened to Jordan? He was suppose to fix all of this? what happened to that spreadsheet I volunteered to work on for the M and after I worked one day on it and then replied back to, what do I do now, nothing ever happened. I never got a follow up courtesy message saying thank you and why it is now dead. I forgot who it was now. Maybe nanomad.

Are you saying that 1% is now there in the eosm thread waiting to talk and work with us all? How come you guys gave headphone to the other cameras? we now have 1% willing to do it for the M. I am not the only one wanting this.

[nanomad]

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.

[gary2013]

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.

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

[nanomad]

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.

[nanomad]

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.

[gary2013]

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.

[nanomad]

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

[dmilligan]

The big problem is constantly hearing one side say how terrible and unsafe T_ is and yet I keep saying I have used every new build everyday and I never had any problems.

"The big problem is constantly hearing one side say how terrible and unsafe [driving 150mph on the highway] is and yet I keep saying I [do that everyday on my way to work] and I never had any problems."

[a1ex]

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

There's a big difference between warning users to expect rough edges, and willfully keeping code that was proven to be dangerous.

Canon cameras have a design flaw in my opinion (and not only mine): certain settings (properties) can be saved in the non-volatile memory without validation. I already wrote about it in the FAQ. Once you manage to save a wrong setting, the camera will show ERR70 even if you boot without ML. Semi-brick.

That's why you should be really careful when changing these properties.

Fortunately, I know how to recover from many of these semi-bricks, especially if I know what setting was changed. I've semi-bricked my cameras with stupid mistakes, spent countless hours trying to figure out how to unbrick them, and I've started to understand what are the situations where Canon code may fail and how to minimize the probability of these things happening with public builds. I wrote some low-level diagnostic tools and successfully unbricked quite a few cameras in the past.

Yes, people come to me or to g3gg0 to unbrick their cameras when something goes wrong.

I still have to learn how to flash back the firmware from a bricked camera (that's why I'm keeping the ROM backup code in ML builds - something that TL removed).

So yeah, keep ignoring my warnings (which I've learned the hard way by semi-bricking my own cameras) or challenging them with anecdotal evidence.

TL had a strong tendency of disabling the error message rather than fixing the actual cause of the problem. WAV recording is one of them: I wrote the memory backend to catch mistakes, it caught a severe bug in the wav recording code (writing to unallocated memory), and I have disabled the feature until a proper fix is found. What 1% did? He bypassed the memory backend, disabling the error message but keeping the bug.

Same for many other things that were my own code, I found them to be buggy (e.g. movie remap, sraw, dual iso preview) and disabled them. TL simply enabled them without actually fixing the issue I found.

Result: waaaa, Tragic Lantern has more features!!!

Not to mention that bitrate adjustments and beep code from TL were implemented by removing the safety checks (assertions) from Canon code. These checks are there for a reason, and disabling them is something I don't agree with.

I have an engineering background, and I'm trying hard to build software that would not fall down when the first woodpecker comes along.

[Marsu42]

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

Whatever the standard, I'd vote to err on the side of safety with ML for the simple reason that it is often regarded as a "hack" and not as original quality software.

As nightly is essentially the new rolling release instead of stable branches, it is very bad publicity to add any questionable code to the public binaries. If you want it, no one is hindering you to use TL (use 1%'s binaries or compile it yourself) or open a TL forum somewhere. I also use 1%'s beep code because it's more important to me than the occasional crash. But this is not about you, me, 1% or alex, but about the general consistency and maintainability of the whole project.

[Danson Delta-40]

I'd just like to say that if it weren't for 1% I wouldn't have done half the videos I have made in the past 5 months. I know that porting things to all these different cameras can take a lot, but the time it took to get back to the 7D, a huuuuuuugely popular camera, was kind of annoying. I know you are all working for free and whatnot, and I am using this for free, but the 7D was just too popular for it to go unmaintained. Oh well, thanks for all you did 1%!

[a1ex]

7D went unmaintained because 1% did not contribute his work to ML back then.

Same for 6D and EOSM.

Back then, I've marked these ports as "unmaintained" to raise awareness about what needs to be done (but didn't really work). I've even refused to commit code for two months in order to give time for TL to merge their work back to ML. It did not happen, but it did bring a huge increase in code contributions to ML from other users (which was a very good thing). Still, there was no intention from 1% to contribute his code to ML.

This decision was made to avoid these problems in the future, and to make sure all the development efforts will end up in the Magic Lantern repository, not in private forks, so everybody can benefit from them (not just a small group of people).

Recently, 1% did submit some of his developments to ML, and one of them - the 6D GPS fix - was merged today. This was encouraging and we hope this process will continue.

I invite everybody to study the Magic Lantern commit history (here's a video version), do the same for Tragic Lantern, and try to do an unbiased evaluation of the contributions from all the parties involved. Feel free to dissect the code differences and review them. Seriously.

[feureau]

7D went unmaintained because 1% did not contribute his work to ML back then.

I think specifically, the 7D ML went unmaintained. Well, we used to have some devs working on it.

It was g3gg0's brilliant breakthrough that first got ML running on the 7D, but the devs stop when it seems like g3gg0 was offended by what some users complained about.

At the time the 7D firmware needed to be signed, and the only way regular users can get the .fir was for the devs to sign them. There were new developments posted on the forum for months but not a single .fir update was posted. Some people felt that the devs kept new developments for themselves and wouldn't share with the community, complained about it and it seems this caused g3gg0 dropped out of the 7D forum.

After a long hiatus, someone figured out how to patch the 7D and run an auto loading ML. Not long after that, the community found out that 1% was hacking away the 6D and the EOS-M then someone asked him to take over the 7D development. At the time 1% didn't have a 7D, but said if they could get him one for testing, he'd work on the 7D for TL.

The community rallied and got him a donated 7D including raising money for shipping.

With the 7D in 1%'s hand, the port went into full development. We even managed to get MLV running. Had it not been for the community's effort, the 7D ML would still be stuck at best with high-bitrate mp4. Of which, the codes has been disabled in ML because it's deemed too risky. But it runs just fine in TL.

With nobody working on the 7D ML, the community found someone willing to fork it and run with it. This is just the way natural selection work with open source software.

In hindsight it might be nice for some of the developments to get pulled back to ML, but given the way TL changes a lot of things that might break the camera, maybe pulling it back to ML wouldn't be such a good idea given ML's propensity to take less risk.

At any rate, I'm really grateful for TL and what 1% has done for the 7D. Just as much as I'm grateful for everyone who has worked on ML. Especially g3gg0.

This breaking up of the two branch is breaking my heart.

[simulacro]

I think specifically, the 7D ML went unmaintained. Well, we used to have some devs working on it.

It was g3gg0's brilliant breakthrough that first got ML running on the 7D, but the devs stop when it seems like g3gg0 was offended by what some users complained about.

At the time the 7D firmware needed to be signed, and the only way regular users can get the .fir was for the devs to sign them. There were new developments posted on the forum for months but not a single .fir update was posted. Some people felt that the devs kept new developments for themselves and wouldn't share with the community, complained about it and it seems this caused g3gg0 dropped out of the 7D forum.

After a long hiatus, someone figured out how to patch the 7D and run an auto loading ML. Not long after that, the community found out that 1% was hacking away the 6D and the EOS-M then someone asked him to take over the 7D development. At the time 1% didn't have a 7D, but said if they could get him one for testing, he'd work on the 7D for TL.

The community rallied and got him a donated 7D including raising money for shipping.

With the 7D in 1%'s hand, the port went into full development. We even managed to get MLV running. Had it not been for the community's effort, the 7D ML would still be stuck at best with high-bitrate mp4. Of which, the codes has been disabled in ML because it's deemed too risky. But it runs just fine in TL.

With nobody working on the 7D ML, the community found someone willing to fork it and run with it. This is just the way natural selection work with open source software.

In hindsight it might be nice for some of the developments to get pulled back to ML, but given the way TL changes a lot of things that might break the camera, maybe pulling it back to ML wouldn't be such a good idea given ML's propensity to take less risk.

At any rate, I'm really grateful for TL and what 1% has done for the 7D. Just as much as I'm grateful for everyone who has worked on ML. Especially g3gg0.

This breaking up of the two branch is breaking my heart.

If what you say is true, then why some people say that 1% is only taking and taking? His contributions have been so beneficial for 7d owners for example... As far as I know from what i read here. 1% was using A1ex work, but not only for his credit, but for the 7d community. I understand what A1ex said about taking TL to a risky edge, but maybe losing 1% contributions could be worse to the community. I don't know what's 1% reaction to be banned from ML, but it would be better if you bring back the TL threads. I think everyone there knew the risks, no one complained. As long as the risks of TL are well known by the users, there shouldn't be any kind of complaints

(...I remember once, I erased in my computer all the files from the CF card, including the DCIM folder. When I put the card in the camera, it did'nt respond. I was scared as hell and I thought "that's it, i bricked my camera". I knew the risks of playing with something I didn't know enough and accepted i shouldn't complain to anyone in ML or TL for my mistake. Later, i put the card again in the computer and brought back the files from the trash can to the CF card. Everything OK. What I'm trying to say, if everyone is aware of the drawbacks of using TL, there is no need of erasing all their work)

[nanomad]

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.

[Audionut]

I don't know what's 1% reaction to be banned from ML,

1% has not been banned.

This decision is based solely on the forking of Magic Lantern, and ensuring that these forks do not interfere with the core values set forth by the Magic Lantern development team.  1%, the maintainer of Tragic Lantern, and other users, are free to fork and do whatever they wish with the project.  This decision should not be considered as a personal attack towards 1%, or other users, who maintain their forks in a manner that is suitable for themselves.  We respect the development by all members, including development that moves away from the direction of Magic Lantern.

However, in the end, only the main repository can be called Magic Lantern and be supported on this website for all of the reasons listed within.

but it would be better if you bring back the TL threads. I think everyone there knew the risks, no one complained. As long as the risks of TL are well known by the users, there shouldn't be any kind of complaints

We feel that the current situation only serves to create confusion among users, split the community, and duplicate development efforts. This makes merging harder than rewriting these features and fixes from scratch, and clutters the forum with duplicate requests, issues and development discussion.

Therefore, we have decided to drop any form of official support for these kind of forks.

Magic Lantern is a development project, first and foremost*.  This development project was being hindered by Tragic Lantern.

We understand that some users may feel inconvenienced by the decision.  There was discussion regarding this decision, for around 4 months (or more), before this announcement was made public.  1% was part of this discussion.
It is hoped (and expected), that in the long run, everyone, including users, will benefit from this decision.  Look past the short term inconvenience.

Again, I encourage everyone, to read the OP, and consider the circumstances, as a whole.  Not simply on a personal level.

I created a thread here, for the express purpose of allowing users to discuss which features are missing from Magic Lantern, to bring the Magic Lantern ports into line with current user expectations, and so far, there has only been 1 response.  Seems everyone is more interested in the politics 


*  This development project has given us what we all know and love.  Magic Lantern.  It is why we are all here.  Without this development project, there would be no discussion, no forums, no cool features, nothing.

As users, we should respect the decisions of the development team.  We should respect that they make decisions in the best interest of the development project.  And as such, we the users benefit greatly, from the advancement of this project.

[lionelp]

1% has not been banned.

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.

Thank you Audionut and nanomad for clarifying this.
Even though it hurt a little from my point of view; a unified group is certainly capable of excellent future development than  as opposed to a group that is separated and not unified.

[OSCA LEE]

I understood all of that. The big problem is constantly hearing one side say how terrible and unsafe T_ is and yet I keep saying I have used every new build everyday and I never had any problems. Yet no one from ML wants to discuss that openly and then maybe rethink their general public statements. We now have a poster (more than likely he is not an M, 6D or 7D user) claiming his loyal faith to ML and he will always believe anything ML tells him. That is sort of pathetic from my view. Maybe he missed my posts in the past about how it never hurt my camera in anyway. Probably no will will see any posts with all the T_ threads closed and hidden now. I am still wondering about this open source if old threads keep getting closed and then censored.

I am asking ML to show actual proof that T_ has caused anyone to have these unsafe things happen they claim. Because it sure has not happened here on my M camera withg every build since last July to date.

I am happy to see at least some people speaking out more on this and a little bit of discussion being made openly.

Co sign 100%

[Critical Point]

Well, from what I can see, things get very slowly ported into ML, if at all. I my self am using TL because it gives me control over the H.264 bitrate and GOP. This is an amazing feature, something that really matters, but will this get ported into ML ? Probably not. And why ? Only God knows why not. As long as you don't port into ML things that really are important, you can't blame 1% for offering those features in his TL.

I think that both ML and TL should be accepted on this site, because obviously we can't get all the goodies in one place only. It would be great to see everything only in ML, but since it can't be done, because of this, I think TL should be kept.

[feureau]

Well, from what I can see, things get very slowly ported into ML, if at all. I my self am using TL because it gives me control over the H.264 bitrate and GOP. This is an amazing feature, something that really matters, but will this get ported into ML ? Probably not. And why ? Only God knows why not. As long as you don't port into ML things that really are important, you can't blame 1% for offering those features in his TL.

The bitrate hack originally came from ML. It was later removed from ML because of bad codes. I didn't know what this meant because there weren't much explanation then, but the damn thing worked just fine as long as you got a good GOP and flush setting with sufficiently fast cards. After a long time of not knowing why, best explanation we have so far is this:

TL had a strong tendency of disabling the error message rather than fixing the actual cause of the problem. WAV recording is one of them: I wrote the memory backend to catch mistakes, it caught a severe bug in the wav recording code (writing to unallocated memory), and I have disabled the feature until a proper fix is found. What 1% did? He bypassed the memory backend, disabling the error message but keeping the bug.

Same for many other things that were my own code, I found them to be buggy (e.g. movie remap, sraw, dual iso preview) and disabled them. TL simply enabled them without actually fixing the issue I found.

Result: waaaa, Tragic Lantern has more features!!!

Not to mention that bitrate adjustments and beep code from TL were implemented by removing the safety checks (assertions) from Canon code. These checks are there for a reason, and disabling them is something I don't agree with.

I was glad TL put this back so at least I can use it. The only annoying part was the auto-disabling canon audio every time you turn it on. This is insanely annoying behavior to hard code into since you have to keep turning it on every time you want to record audio, and pray you don't forget to do it. It is bad form to have the software automagically change a setting contrary to the way the user set it up to.

Plus it's interesting solution to remove a feature entirely after leaving it in for a long time (IIRC more than a year), instead of coding in the safety checks and blaming the whole thing on TL...

[Critical Point]

Well, it doesn't matter, many persons use TL because the GOP & bitrate features work, and recording the audio with an external device is a common practice, it's not such a big deal to most, because they do it anyway, with or without TL, me included. After having used TL for over a year now, it didn't chewed up my camera, and works just fine.

It is called Tragic Lantern for a good reason, and I think 1% explained very clearly that the code is not 100% good, ok, or tested, but there are some of us that accept TL the way it is, only to gain certain features that in ML we can't get. When those features will get ported to ML, I will gladly reinstall ML on my camera, but until that day comes, I'm stuck with TL because I can't give up those controls over the bitrate and GOP.

Give us an alternative in ML and we'll gladly give up TL, but unfortunately this is not happening, you guys want us to give up TL and go back to nothing. I'm sure that before TL was banned, somebody could have said: "before banning TL, let's not rob this people of some good features that they depend on, and lets put them in ML, then we'll ban TL. Lets make first ML be at the level of TL features ways, then we'll close TL."

Make an ML 2.4 with the bitrate and GOP controls included (without sound if it can't be done otherwise), but put those features in ML, they are very important to many, because those two damn features are the reason why many people use TL and not ML.

[a1ex]

Had it not been for the community's effort, the 7D ML would still be stuck at best with high-bitrate mp4.

Say what?

Well, from what I can see, things get very slowly ported into ML, if at all.

If nobody submits pull request for these features, they don't get ported. We have pulled blindly a lot of changes, FYI, and we do not want to do blind porting any more.

https://bitbucket.org/hudson/magic-lantern/commits/all?search=1%25+Percent+tragic

but will this get ported into ML ? Probably not. And why ? Only God knows why not. As long as you don't port into ML things that really are important, you can't blame 1% for offering those features in his TL.

1% can share his bitrate code as a module that can run on top of normal ML

The bitrate hack originally came from ML.

The one with patched asserts did not.
https://bitbucket.org/OtherOnePercent/tragic-lantern-6d/history-node/d043040e5de2/src/bitrate-6d.c?page=5
https://bitbucket.org/hudson/magic-lantern/history-node/fd411184b6c4/src/video_hacks.c?at=unified

Any more questions?

[Critical Point]

If there is the possibility of running ML + the bitrate & GOP features as an module...that would be lovely. But, until that day comes, I'm stuck with TL.

[engardeknave]

There's a big difference between warning users to expect rough edges, and willfully keeping code that was proven to be dangerous.

..

I have an engineering background, and I'm trying hard to build software that would not fall down when the first woodpecker comes along.

I feel like I should voice my deep appreciation for this development philosophy. I absolutely wouldn't be able to use ML otherwise. It's the difference between losing a few features, and losing all of them.

[dmilligan]

After having used TL for over a year now, it didn't chewed up my camera, and works just fine.

https://yourlogicalfallacyis.com/anecdotal

Give us an alternative in ML and we'll gladly give up TL, but unfortunately this is not happening, you guys want us to give up TL and go back to nothing.

This is a website for Magic Lantern. You have every right to continue using TL, 1% has every right to continue developing it. Just not here on this site. It is absurd for you to insist that ML developers provide support for a competing fork that does dangerous things that they disagree with. If you feel so strongly about TL, then feel free to make your own website and forum, provide support and downloads, you have every right to do so and nobody is going to stop you, but stop making ridiculous demands of the ML developers, you are only proving them right in their decision.