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:
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.
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…