Using “run” To Delay Python Code
A little trick that I like to do when I use the run command. Instead of composing the comand using concatination or f-strings, i just pass a function as one of the arguments
run( "args()", lambda : print("foobar") )
using closures I can easily pass refferences around without having to create badly readable scripts in string format.
For example in an extension
def update_par(self, value): self.ownerComp.par.Foo.val = value def trigger_delayed_update(self): run( "args()", lambda: self.update_par("uno") ) run( "args()", lambda: self.update_par("dos"), delayFrames = 200 ) run( "args()", lambda: self.update_par("tres"), delayFrames = 400 )
Oh wow, that’s awesome.
I feel like this should be the default behaviour, to be honest
@alphamoonbase what’s the point of using lamda here - simply readability? i just pass all the args into the run string, regardless of type. seems the most simplistic/readable to me.
def update_par(self, value): self.ownerComp.par.Foo.val = value def trigger_delayed_update(self): run('args(args)', self.update_par, 'uno') run('args(args)', self.update_par, 'dos', delayFrames=200) run('args(args)', self.update_par, 'tres', delayFrames=400)
@Ivan one thing that has always bothered me is that
delayMilliseconds does not run agnostically of the frame rate - which logically one would presume when specifying something in milliseconds vs frames. obviously, this causes issues when using run delays in non-realtime systems w/uncapped framerates. my workaround is to pipe the current rate into the delay value…
run('args(args)', self.foo, 'bar', delayMilliseconds=2*me.time.rate)
however, it seems more logical and less prone to confusion to respect the true milliseconds - regardless of the frame rate. or, add another argument to
run to specify how the delay timing is evaluated - ie.
@Ivan sure. here’s a non-realtime .toe w/vsync disabled demonstrating the issue.
RunUpdate toggles a red background color with a delay of 5 seconds. you’ll note in perform mode it’s blasting through nearly instantly at uncapped FPS rates, whilst out of perform it acts as intended with the 5 second delay…
RunTime.toe (4.1 KB)
Hi milliseconds is converted to frames on the timeline.
This is similar to our parameters that allow for specifying frames, seconds or samples in menus.
We’ll make note of allowing for realtime / elapsed system time delays as well.
Ps. We’re actively investigating how to streamline lambda function arguments as described in the earlier posts.
I think the main problem is that all bets are off for absolute time when you turn realtime off.
@choy can you give an example where you are running non-realtime, but you want a real-timed delay to occur?
@malcolm in a non-realtime queue-based render system using callbacks/requests to external systems wherein it is either not possible or particularly cumbersome to ascertain a particular external state needed to trigger a subsequent action, etc. in this case, realtime delays/run loop checks with simple exception handling have been useful.
also, in a few instances - quickly setting a simple delay of N before beginning a file xfer of a completed render as to ensure the file has been completely written to disk and not still in use by the OS, without having to write a file checker to verify the status before doing so.
in most cases - more robust callback/verification code is eventually added to replace the functionality of a simple delay - however, during development/debugging i’ve found it to be quite useful.