Loading scripts in order

Started by garry23, December 03, 2017, 10:52:30 AM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

garry23

I am running two EOSMs with two identical scripts.

But they respond differently and I believe it to be how the scripts are loaded, as I'm using keypress event handlers in both scripts.

On one camera script A is listed first and on the other script B.

Is there a simple way to ensure which scripts load first?

Cheers

Garry

garry23

...just an update as this is mystifying me.

As I say, I have two identical cameras (EOSMs).

I only have two scripts and the SD cards on each camera are loaded with the identical scripts from my PC.

One camera loads script A first and the other script B.

I need script A loaded first.

Any ideas?

Walter Schulz

Try using Touch to manipulate file date.

garry23

@Walter Schulz

Walter I have been playing around with this weirdness for over an hour.

I have now 'solved' the immediate problem and both cameras now have the correct script loaded first.

I played around with file dates etc and, in the end, I'm not sure how I fixed it.

It would be great if ML had a way to force the order that scripts were loaded and hence operate within the ML environment.

Cheers

Garry

Walter Schulz

As written above: I suppose Canon/ML orders files/directories (in some cases) dependent on timestamp. That's what happens in Config Preset. https://www.magiclantern.fm/forum/index.php?topic=8499.msg147584#msg147584

garry23

@Walter Schulz

Walter, yes I explicitly recreated the two scripts to 'reset' timestamp and indeed I can dictate the script loading order.

Also did it the other way round to prove things.

Thanks for the insight.

Cheers

Garry

g3gg0

so it would probably be helpful to sort by filename before loading?
the order then can be dictated by adding digits in front of the file name.
Help us with datasheets - Help us with register dumps
magic lantern: 1Magic9991E1eWbGvrsx186GovYCXFbppY, server expenses: [email protected]
ONLY donate for things we have done, not for things you expect!

garry23

@g3gg0

I don't believe sorting by name would work: I tried that.

As Walter said (thanks again) the timestamp is the key.

Scripts in the Lua scripts folder get loaded in timestamp order.

There are ways to change the timestamp attributes, eg https://www.petges.lu/, however, all you need to do is to ensure you move each script into the Lua folder at different times, ie not together as I was doing ;-)

Cheers

Garry

Walter Schulz

Garry, g3gg0 is well aware of the fact ordering by file name doesn't work right now. Now read again.

garry23

@Walter Schulz

Got it!!!!!

@g3gg0 is suggesting we add that feature to ML  ;)

Sorry: just a dumb Lua scripter here  :D

Looking forward to seeing the suggested feature, but now I know the work around I'm 'happy'.

Cheers

Garry

Walter Schulz

It will work for you but this workaround is nothing I want to support for "the masses".

garry23

@Walter Schulz

I'm 100% with you.

But, sometimes, I'm loath to ask/suggest 'minor stuff', with all the lofty work going on by the ML gurus.

My gut feeling is that most of the ML posts these days are video related; and I don't do video...well at least not yet.

As you know from my previous posts (and my blog) I believe ML is a killer environment for stills photographers, eg silent (albeit not working fully yet, eg seamlessly across shutter space), ETTR, auto-bracketing, Dual-ISO and, dare I say, my focus bar for landscapers :D

It just keeps getting better  :)

Cheers

Garry

a1ex

Modules work in the same way (they are sorted by name before loading). Not ideal, but at least this gives a predictable outcome when handling events.

@all: have a better suggestion on how to solve such conflicts? They can happen for all types of events where one handler may wish to exclude others. In the core, the order of execution is hardcoded (and there were quite a few UI bugs solved by reordering the key event handlers), but with modules/scripts, that order is no longer under programmer's control.

More examples:
- display filters (custom routines that alter the LiveView image); only one can run at a time; if the user enables two or more features that use this backend (for example, anamorphic preview and fisheye correction, or any of those and raw video preview with correct framing, only one of them will work).
- custom picture taking functions (these replace Canon still photo capture when ML has to take one, e.g. intervalometer or focus stacking; luckily, we only have only one - silent pictures)
- LiveView info bar items (lvinfo) - here, each item provides a preferred_position hint (whether an item should be placed to the left, to the right, or in the center, but the exact ordering is not critical and is decided by the backend)

garry23

@a1ex

Once again, thanks for the insight.

As I implied, both my main scripts, focus bar and toggler, use event handles extensively. Also both access and control the same keys, eg INFO.

It is not clear to me how each script accesses the keypresss, eg shared alternatively or what.

Any insight would help my education.

Cheers

Garry

a1ex

Key handlers are run sequentially in gui-common.c, handle_common_events_by_feature. If one of the handlers decides to stop processing (returns 0), then subsequent handlers will no longer get the event (and neither Canon firmware).

Modules receive key events in handle_module_keys (somewhere near the top, except for some special events). So, they have the ability to block the keys for most other ML stuff.

Scripts receive key events from the Lua module (so, modules with a letter "lower than" L can "steal" keys from Lua, while Lua scripts can "steal" keys from modules with a "higher" letter - by returning false).

Lua scripts receive the events in the order they were loaded from the card. Not sure if it has to do with the timestamp, or with the order they happen to be in the file allocation table.

As mentioned earlier, sorting them alphabetically is not ideal, but at least deterministic (you have some sort of control).

Suggestions to improve this are still welcome. Maybe a priority flag when defining the event handler? One may want to define a high-priority handler (that runs before all other modules) or a low-priority one (which runs only if nobody else handled the event, maybe also after all other ML handlers). In any case, it will be a source of subtle bugs and quirks.

BTW - the ml-cbr backend seems to have support for event priorities. Might be worth a refactor. The question of what to do with events of equal priorities is still open (call all of them? let the first one block the others?)

garry23

@a1ex

Many, many thanks.

Each time you find time to comment like this, really helps people like me.

Cheers

Garry