What are your plans about merging the branches into master?

Started by pakkanen, January 04, 2021, 08:02:26 AM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

pakkanen

Hi,


I am Thomas (C programmer) and this is my first post here. :)

First of all:
Thank you so much for the "Magic Lantern" software! <3

I have a meta question about the experimental branches and the current workflow:
The last days I completed the task to compile the current master trunk in a virtual box with Xubuntu 18.04 iso. I mean this master trunk: https://foss.heptapod.net/magic-lantern/magic-lantern/-/tree/branch/unified
But I am little confused because the codes from the master trunk and the latest nightly builds on your website are from the year 2018.

Then I saw that your are busy working on different branches. Some of these branches are active and others are stale branches from 2019 or 2018. I mean this: https://foss.heptapod.net/magic-lantern/magic-lantern/-/branches

What are your plans and ideas about merging these branches into master?

My three Questions:
A.) Does it make sense to change the master trunk code until you finish your work on the branches?
B.) Are you merging the active branches for Lua and Iso into master if you finish them?
C.) What about the branches which are currently staled since 2019 or 2018?

I know your free time is valuable and rare, so you do not have to answer in great detail. Just give a short summary. :)


Thank you so much and best regards,
Thomas

Audionut

Some background reading on issues that have impacted main development:

https://www.magiclantern.fm/forum/index.php?topic=24420.0
https://www.magiclantern.fm/forum/index.php?topic=24548.0
https://www.magiclantern.fm/forum/index.php?topic=25717.0

There is still development work happening, simply that it's not very noticeable on first glance. Look at the popular threads in the camera specific section and join us on discord
Until all of the linked issues are fully resolved, I don't expect any changes to the current workflow.

Ideally we would like to have a stable build of ML, however, feedback is often lacking and bugs can go unnoticed by the dev team for months, if not longer. There are efforts to mitigate these problems, search "qemu".

ChristianEOS

A more amateur question. Would the latest build 5.7k crop_rec_4k_mlv_snd_isogain_1x3_presets_2020Dec11.5D3113.zip
Be in the stable release?
Christian Bruno James

a1ex

Also worth mentioning: https://www.magiclantern.fm/forum/index.php?topic=19737.msg218437#msg218437

Currently, the project is unable accept contributions in any meaningful way, so we need to solve that first.
Long answer: links from Audionut.

pakkanen

Hey everyone,


thanks for the hints and answers. :)

So I will lay my focus on the two active branches for testing, so maybe I could help you with some feedback, so its easier for you to finish them. :)

The last two days I try to understand the "mlv_rec" and the "pic_view" module in the lua branch. Mostly the module named "pic_view", because it is the smallest available module in the module folder. And I have to admit: Guys, you have balls of steel! Respect! :-) I am not used in firmware programming and this is really fascinating C source code. It is not complicated, but I thought before starting that these image/video topics would be far more easier to understand. ^^ Also I will join your Discord server, because I got some questions about compiling the ML modules, which currently do not work for me. "Missing" ../../src/module.h file error.


Thanks a lot and have a nice weekend! :)
Thomas

Walter Schulz

Just out of curiosity I peeked into pic_view.c to find
        bmp_printf(FONT_MED, 0, 0, "Not a CHDK DNG");


This doesn't feel right but IANAP. ;-)

a1ex

Quote from: pakkanen on January 08, 2021, 09:04:59 AM
The last two days I try to understand the "mlv_rec" and the "pic_view" module in the lua branch. Mostly the module named "pic_view", because it is the smallest available module in the module folder.

Probably not the best starting point - pic_view was one of the first modules I wrote, so the coding style back then was quite rusty. To get started with modules, I'd recommend following the Hello World module tutorial (which is not in the repository, specifically so people can actually follow it and create that module from scratch).

Then, some of the simpler modules are mpu_dump and sf_dump - though, pretty low-level. The "deflick" module is another easy one, although it has limited purpose - everything done by that module can be done much better in post-processing. The benchmarks module (bench.mo) could be also reasonably easy to understand. Arkanoid is a fun one - but also one of the older modules.

ETTR and Dual ISO are a little more polished, but also more complex. For raw recording, I find mlv_lite being simpler than mlv_rec - but that's largely because it was derived directly from my old raw_rec code (unlike mlv_rec, which was more like a major rewrite). If you look at mlv_lite, also check the crop_rec_4k and derived branches (LJ92 compression etc).


Quote from: Walter Schulz on January 08, 2021, 09:32:34 AM
Just out of curiosity I peeked into pic_view.c to find
        bmp_printf(FONT_MED, 0, 0, "Not a CHDK DNG");


This doesn't feel right but IANAP. ;-)

Kind of - that code works specifically with DNGs created by the library we have borrowed from CHDK (src/chdk-dng.c). Other DNG formats, created by other means, probably won't work.

That reminds me of the attempt to switch to another DNG library - PR 603 by dmilligan - currently on the back burner, sorry.

pakkanen

Hi,

thanks for the hint with the hello world example. :)

Based on these steps I created as a test a simple ML module for checking the camera screen. Showing five colours (white, black, red, green, blue) each five seconds for checking the camera screen for blind or dead pixels (see short video linked at the end).

I had a look at the different modules Alex mentioned and the game module for Arkanoid looks funny. :) Currently I try to understand how to address the pixels from the camera display. Thanks for your answers in Discord about these topics (different API versions and display). First I thought the display is a normal 24/32bit display with RGBA, but things seems to be a little bit more complicated. ^^

Questions:
* If I could fix a bug for example in "Arkanoid" where would I commit this bug? Pull request for current master branch or the other branches? I am not used in these concepts so I have to ask. :)
* Did someone knows how many fps the display can handle?

Best regards,
Thomas


Video link (40sec):
https://www.maatuu.li/ml/disptest.mp4




heder

I wish I had the time to contribute more, but I dont, so I linger in the 40D department. But if I had the time  :)  I would start by cleaning up the Main branch code, line by line. ML is extremly complex and needs a pretty filter run over the code, more comments, and more inline documentation, more coding style, and no more ^M please. Also to many ifdefs makes the code difficult to port. But .. these changes are not valueable features, most Ppl only cares about bigger  :( resolution.

How about creating a unifed dev branch ?
... some text here ..

names_are_hard

Maintenance work is indeed not the most exciting, but it certainly is useful.  In my ML git repo, I've merged unified, lua_fix and qemu branches.  It's nice not having to swap branches so often!  I've updated Qemu to a version that's supported.  I've removed most ^M.  I've made some other tidying / style changes.  But, I don't believe I have any way to get these changes into Heptapod.  They'd want significant test effort, too.  Maybe I'm wrong and there's some process I can follow?

A "unified dev" branch would help me.  Even better would be some agreed upon naming prefix to allow multiple unrelated changes to be in flight at one time.  Unless branches are short lived, they run the risk of diverging too much and never getting merged.  Sometimes you need long-lived branches for expensive experiments, but this is rare.  Most branches should be for one feature only, never two different things in one branch.  Combined, these strategies make merges much easier.  A feature gets finished, merged, then the branch is never needed again.  Possibly something like this: "unified/features/dos2unix_line-ending_cleanup", "unified/features/50d_fix_crash_when_enabling_sound", etc.

Since I'm using git and have done multiple large changes, I'll need to separate out the individial fixes.  This is extra work I gave myself by doing things in a slightly awkward way.  I am happy to do this work to get the improvements into ML.  I want to do this, but I don't know if there is a way at present.

I've also been thinking about how to tame the ifdefs.  This is fundamentally hard with a project like ML, where it's inevitable that some cameras will have different features, or need the same function to do subtly different things.  Changing it is even harder, because you're bound to break things as you go, and automated testing for ML is another hard problem.  I think moving more things into the platform dirs might improve things.  You'd duplicate some code, but make the code easier to understand and change.  But to test that theory, you have to do quite a lot of work to the build system.  I have a good start on this.  Including stopping the build making .o files all over the place; everything is created inside build/.  So much cleaner.  But I've only got a small piece of the old build system functionality duplicated, continuing is a lot of effort and risks diverging the repos more than I'm comfortable with.  Nobody seemed interested in my changes so I've stopped working there.

names_are_hard

Quote* If I could fix a bug for example in "Arkanoid" where would I commit this bug? Pull request for current master branch or the other branches? I am not used in these concepts so I have to ask. :)
* Did someone knows how many fps the display can handle?

First, well done getting a module working!  Pixel test is a nice idea and not too hard to learn with.

Re setting pixels, different cameras have different displays.  Some are RGB, some are YUV (possibly only Digic 6 or greater?  If so, nothing currently supported but the point still stands).  There are different bit-depths, etc.  ML abstracts this away so you don't need to worry about it, and so your code is portable.  See disp_set_pixel() in src/disp_direct.c.

Re bug fixes, I believe you'd want to send these to the "unified" branch.  The actual master branch is many years out of date.  All real work seems to happen on unified.

There's no single answer about fps of the display.  This differs per camera model.