Hi,
I use an AsyncLoop region to get better performance with the CSRT Tracker node, as explained in this tutorial :
The problem is that input bangs are not always sent inside the AsyncLoop (they miss it 70% of the time).
Is there a trick to force events to be taken into account by the AsyncLoop?
testAsyncLoop.vl (16.7 KB)
Thanks
Try moving the LFO into the AsyncLoop.
Thanks @bjoern .
It kind of works (no more missed bang), but now the timing is slower (LFO cycle is supposed to be 1s, and when in AsyncLoop, it triggers every 2.5s approximatively)
If you only want to execute the Tracker at certain intervals use an AsyncTask instead.
That could work in some cases, but here I need to update it every frame (I update the tracking position every second, but I need the results in between)
My workaround at the moment is to put the LFO in the AsyncLoop region, and to set it to 0.4s
It’s not very consistent, it oscillates between 1 and 1.3s (it depends on what else is calculated on this thread?), but it’s a good start!
It only bangs sometimes, because a bang only lasts for 1 frame, and unless that is the same time as the async region is updating ( it will go faster or slower than main loop, but basically not in sync with it) you can’t guarantee that it is. You should get a bang out of the hold latest, if what you need to know is when it updates? Otherwise, what is it that you are doing with the bang?
The AsyncLoop (and probably other nodes executing in a loop like fashion) should install their own clock so animation nodes depending on time work correctly. I think the ground work for this was already done last year so it should be a quick one. Will write this up, thanks for the reminder.
Using ForEach [Reactive] (with a period that corresponds to your mainloop) seems to give pretty consistent timing. Not sure which timer is “best” and if they are all actually running in the background. @Elias ?
ReactiveForEach.vl (44.2 KB)
Yes, they are all in another thread, you can check that with the underrated and underused node Debug [Reactive], it outputs the thread Id which you can compare to the CurrentThreadId of the calling patch.
Timer is best for stuff that doesn’t need extremely precise timing as it’s quite light, BusyWaitTimer needs a bit more CPU but has extremely precise timing and the multimedia one is just buggy, don’t use it :)
I tried to replace the LFO in the AsyncLoop region by a Stopwatch + ToInt32 + Changed.
And for some reason, it works: no slow down or acceleration with Stopwatch, the Bangs are regular…
The Stopwatch node uses the real time and not the frame time, that’s why it works everywhere.
Nodes like LFO should work inside of AsyncLoop in upcoming previews. For reference here is the relevant change: `AsyncLoop` installs a frame clock now - fixes animation nodes not re… · vvvv/VL.StandardLibs@5cba9e3 · GitHub
