FrameClock in reactive or async regions

[motzi]

hey there,

it now took me quite some time to figure out how to deal with time when working with several mainloops. so please read this post as either

• a question, if this can be done better. if not →
• a howto
• a question to the devs, if the UX for this can be improved somehow.

think of the following easy usecase: an LFO runs inside a loop, that has a higher frame (~250fps) rate than its surrounding loop (at @60fps):

patched this way, the LFO inside will not have a period of 1 sec but rather 1/4 sec, as it references the frameclock running at 60fps.

it took me some time, but it can be apparently fixed by creating its own frameclock:

interestingly, there is a FrameClock available as an input, but it trying to reference it on Create results in an “Unknown Pin” error:

UX wise it would be cool to just do this as shown in the last pic instead of the working solution.
or are there other possibilities i am not aware of?

thanks!

[tonfilm]

yes, this needs improvement. but you did it right, create it on create and pass it to the LFO, then update it on update. there is one little trick that lets you use the clock input on create by creating a new state context that you can reset via the ManageProcess node:

[motzi]

thanks for the feedback. interesting.

could you shed some more light on what ManageProcess actually does? i could not find any info on that.

[tonfilm]

ManageProcess could also be called ManageState. it only opens up a new context that can hold state with the option to reset it -> delete all state and call create again.

[motzi]

“context” is a concept that most patchers, including me, are probably not familiar with.

could i think of it like this:

• a context represents the “life-cycle” of an entity. e.g a process note creates it’s own context (starting with “create”, then “update”, eventually “dispose”)
• manageprocess does something like a process node, without requiring a node. but it has “create” and “update” and is stateful

?

[Elias]

Well the patch could drastically be simplified if the LFO (and all the other animation nodes) would take the clock on Update and not on Create. Then you could just connect inside the ForEach region. Something for us to consider library wise.

Regarding your last question:
The state of each process node gets managed by the surrounding patch. It initializes their state on Create, updates them on Update and disposes them on Dispose. In case of the ManageProcess node that cycle can simply be retriggered whenever one triggers its Reset pin. It will dispose of the previous state (which is made out of all the pads and process nodes inside of it) and create a new one on which it will continue to call Update whenever its own Update is called.

[motzi]

thanks for clarification on “context”!

back to the original question on FrameClock
there is one more thing to consider with that. as soon as you place other process containing FrameClock consuming nodes inside that region, each process you need to propagate down the frameclock (or create new ones inside each). that’s quite a hassle with several hierarchies.
a solution where these nodes automatically choose the “closest” frameclock hierarchy-wise would be cool. even nicer, if you could make this somehow configurable…

[Elias]

Indeed. We’ve already played with a few ideas tackling that exact issue - passing stuff like clocks around. Needs some polishing though before we can write a blog post about it.