Lua Scripting (lua.mo)

[a1ex]

I've got it running by inserting this at the beginning of first loop in your move() function:

Code: [Select]

function move(direction)
  ...
  repeat
            msleep(500)
            lv.start()
            ....
            focus commands
            take_brackets()
  until ...
end

If LiveView is already on, lv.start() will do nothing.

If you are in image review mode, lv.start() will bring you back to LiveView (without waiting for the image review to finish).

If you call it while Canon firmware is already attempting to return to LiveView (e.g. immediately after taking a picture with image review off), you have a race condition. ML notices the camera is not in LiveView, so it queues a fake press on the LiveView button. Meanwhile, Canon code might enable LiveView. By the time the LiveView button press gets interpreted, the camera is likely already in LiveView, so the effect will be the opposite.

Hence the delay before attempting to start LiveView.

That's because camera.shoot() does not also wait until the camera returns to LiveView. It only waits until Canon firmware reports the picture has been taken (so you can take a second picture or change settings straight away). LiveView is a different task.

[garry23]

@A1ex

Once again thanks for the insight.

I'll use the 'Lua Fix', and your insight/hints, as an opportunity to refactor/tidy-up my scripts.

Cheers!

Garry

[garry23]

@A1ex

Looked at my script, following your insight, and used the following snippet in the end:

Code: [Select]

repeat
   msleep(200)
until lv.running
I used this 'upfront' and once, as you suggested. I also found I needed it after my shoot function, ie:

Code: [Select]

function my_shoot()
camera.shoot(false)
repeat
msleep(200)
until lv.running
end
I think you hinted at this.

One thought I had was whether it worth putting a bool check in camera.shoot and lens.focus that could be used by the scripter to tell ML Lua to wait for AF and LV or any other critical event/state, that you are aware of, but mortals like myself are not 

Bottom line: once again thanks for all the background hardwork and for supporting 'idiots' like myself.

Cheers

Garry

[garry23]

Carrying testing with the latest Lua fix experimental branch, but noticed no 50D version.

Is there a reason for this?

Cheers

Garry

[a1ex]

Looks like it's a bug, and the experimental build page doesn't have a way to flag broken builds (it simply lists all the successful ones). Will fix later.

[garry23]

  Cheers

[a1ex]

I've revised the behavior of "complex" scripts a bit: in the initial concept, they were started, and if they could not be unloaded, they were automatically configured to autorun. Now this is no longer necessary (and probably a bit confusing as well), because any script (be it simple or complex) can be set to autorun from menu.

Please give it a try, as I'd like to merge it soon. Not only for Lua itself (which doesn't seem very popular these days), but for the other backend updates made to pass the Lua API tests.

[garry23]

@A1ex

Going to test latest Lua experimental build against my scripts.

One thing that is not clear to me is that there is mention of lens.focus_pos but I can't find any info on this. Is it a different call to the current lens move ?

[a1ex]

Lots of info on focus_pos here. It's not moving the lens in any way, and right now it's probably only useful for research.

Also found a typo that prevented lens.focus_pos from appearing in the HTML docs.

[garry23]

@A1ex

Ok, thanks.

BTW tested build on my 5D3 with my main landscape bracketing script and my HFD positioning script. All looks OK.

Will test on 50D later today.

Cheers

Garry

[garry23]

@A1ex

Just found some time to do a quick 50D test on latest build.

See a strange thing, ie relative to 5D3, which runs my two scripts fine: Console stays on.

Three lines saying:

Code: [Select]

Black level: 1790
Duplicate Menu: Press FUNC (2)
Duplicate Menu: Press FUNC (2)


[a1ex]

Managed to review all the changes and updated the PR description:

https://bitbucket.org/hudson/magic-lantern/pull-requests/720/lua-fixes-part-2/diff

If anything looks weird to you, please say it now. Otherwise, it's ready to merge from my side.

[garry23]

@a1ex

I did try and scan the code, but bluntly could add no value until I test things in camera.

Cheers

Garry

[JohanJ]

Last weekend I was testing magiclantern-lua_fix.2017Mar26.60D111 mainly for stability of standard ML functions for still shooting. Looks good to me on my 60D. Especially the dynamic ML menu is much appreciated! Next weekend I will do similar tests w/ 100D.

The only Lua script I have in use so far is lens.lua from the manual_lens_info branch which was not running successfully on this build. I had to realize that certain changes  from manual_lens_info branch are not included in lua_fix, like moving common ui code into lib/ui.lua (bdcd13e) or introduction of  xmp.lua metadata library (ed6b260).

@dmilligan @dfort
Wouldn't it be useful to combine these two branches into one as both are providing useful Lua improvements (and much more of course)?

[a1ex]

I've synchronized manual_lens_info with lua_fix, but right now I'm too tired to play with it. Only checked whether it compiles (and found a minor problem in lua_fix that way).

[JohanJ]

Thx a1ex. Much appreciated. I know there is a lot ongoing. Exciting times. Thx again.

Sent from my SM-T719 using Tapatalk

[JohanJ]

@nikfreak  @a1ex
Just recognised that 100D disappeared from experimentals for lua_fix and manual_lens_info. Probably broken build?

Sent from my SM-T719 using Tapatalk

[garry23]

@a1ex

Just tested the latest Lua.fix (4th April) on my 5D3 and 50D.

Although not a full test, my two 'go to' scripts, Auto Landscape Bracketing and 'Move to HFD or Inf', both seem to behave as expected on both cams.

Cheers

Garry

[garry23]

@A1ex

I had a thought last night that I welcome your insight on.

Many times when writing Lua, I wish I had access to a ML C variable, ie 'just' reading it.

For example, the position of the spotmeter.

Would it be too difficult to add the following functionality to Lua?

Code: [Select]

get_ML_variable(var_name)


[dmilligan]

While it might technically be possible if the particular variable is a public global. It's not a very good idea from an API standpoint. It would violate the idea of encapsulation and expose implementation details to the consumer. The result would be very "fragile" code. It would make it much harder to change or refactor ML core without potential breaking scripts.

Think of an API as a contract. A contract should explicitly define all the interactions between the parties. There shouldn't be loopholes or backdoors, as this would be.

[garry23]

@dmilligan

I 'feared' you would say something like that 

Pity, as without access to some of the ML functionality, scripting will be 'held back', i.e. 'Restricted' to accessing the normal Canon info such as exposure etc.

Oh well, back in my box   

Cheers

Garry

[JohanJ]

I would read @dmiligan's answer in another way. Instead of adressing ML specific  variables with a generic call as you suggested there should be the possibility to extend the list of API interfaces delivering the required information independent of the type and name of the variable currently in use for ML. But that would need more programming efforts in Lua of course, right?

Sent from my SM-T719 using Tapatalk

[garry23]

@JohanJ

Good point.

If that is the case, it would be good for us to create a 'list' of potential API hooks.

Cheers

Garry

[JohanJ]

I got some instability with the latest Lua Update and fixes build for 60D magiclantern-lua_fix.2017May01.60D111. Basically my camera is just freezing. It could happen directly after starting up the camera or during shut down. It definitively happens when walking through the card file system using file_man module. Otherwise there is no reproducible reason or pattern. The only way out is pulling the battery.

Unfortunately there is no crash log I could provide for analyzing the circumstances. Did a low level formatting of the SD card but nothing changed. Using the latest nightly instead of the lua_fix build does not show these problems.

Is there anybody else encountering this problem?

[a1ex]

Basically my camera is just freezing. It could happen directly after starting up the camera or during shut down. It definitively happens when walking through the card file system using file_man module.

I've actually found this bug in QEMU in the previous build, and only fixed half of it (it's one of those bugs found with -d memchk). There's still a warning left, but I could no longer reproduce the crash in QEMU after the fix. Did not try this build on a real camera yet.

Both parts of this bug are use-after-free triggered by a race condition (on menu_remove). I'm analyzing this kind of bugs in this branch and this topic, but I have no experience with how to deal with them properly.

Was the previous build (Apr04) not affected by this issue? (old versions are here for now)