it works as sleep command.
sleep blocks execution of commands until timeout
the same with md_detect_motion
The whole line acts as a sleep command? It sits there sleeping for the duration of the timeout setting?
Or does it sleep on that line during the timeout setting, and then if it detects motion it stops sleeping no matter what the timeout setting is?
I can't figure it out from your hints.
For the last 5 hours I've been trying various things by using my own sleep cycles instead of the ones you have built into that md command, thinking if I bypass yours then it'll finally make sense. But if I put the timeout to 0 or 1, then I get even longer delays. None of this is making sense. (literally months of people's time wasted in trying to write scripts, just because you won't fully explain it)
It's not that difficult.
The md_detect_motion function blocks execution of the statements that follow, and releases control in 2 cases
1. if motion is detected
2. if the time-out period (x) is exceeded
and then the next lines of the ubasic code are executed.
When md_detect_motion is called, for the duration of the Trigger Delay (e) it just sleeps,
after drawing the grid, so you can move your camera around to get the grid in the right position.
When you want to avoid continuous shooting using the Trigger Delay, you can just as well use
a sleep command before calling md_detect_motion.
Now, experience shows that the direct shooting option (j=1) is faster than shooting
yourself (j=0) when the changes from mx3 of GrAnd are applied to the MD code.
Using the `single' buffer or the '3' buffer approach did not make much difference for me,
the last is more consistent in timing, but on average is not faster, and may
give rise to `continuous' shooting. The shortest code is as follows
@title MD LightningA
@param a Columns
@default a 6
@param b Rows
@default b 4
@param c Threshold (0-255)
@default c 10
@param d Compare Interval (millisecs)
@default d 0
@param e Trigger Delay (0.1 secs)
@default e 1
@param f Time-out period (s)
@default f 3600
@param g Pix-Step(speed/accuracy adj)
@default g 6
@param i Measure Mode(1-Y,0-U,2-V)
@default i 1
@param j Direct Shoot (0=N 1=Y)
@default j 1
e=e*100
print ">[";a;",";b;"] threshold: ";c
x=f*1000
while 1
press "shoot_half"
md_detect_motion a, b, i, x, d, c, 1, t, 0, 1, 1, a, 0, j, g, e
if j=0 then click "shoot_full"
rem the next loop is endless if AE lock is activated, use 205 for DigiII
do
get_prop 206 p
until p<>1
wend
end
When x is large enough there is no need to set or test for t, md_detect_motion only exits for case 1 above.
Setting x=0 will not give you infinite time out, for that you need to modify the MD code.
The testing of prop_id 205/206 is to check if shooting is finished, so Trigger Delay (e) can be choosen small.
This takes care of the effects of exposure time etc, so those variations a accounted for. What is not taken
care of is the viewport dynamics, e.g., setting the right amplification. For me .1s works in bright conditions,
when there is not much light you need to increase e, but e should not have any influence on the delay between
detection of motion and taking a picture. Between exiting and entering again of md_detect_motion (including the
Trigger Delay period), you are not able to detect any motion. So keep e small.
