VL-Language icon indicating copy to clipboard operation
VL-Language copied to clipboard

[CoreLib Proposal] ForEach State Management Refinements

Open gregsn opened this issue 1 year ago • 4 comments

Introduction

Some of our core regions manage state, even if they don't have "Manage", "State" or "Lifetime" in their names.

For E.g. a ForEach loop allows to use process nodes and will instantiate the patch inside the region once per index -> All process nodes in a ForEach exist several times.

Behavior over time:

Only when the count goes up from frame to frame new states will get created. The other ones get reused. And when the count goes down Patch-States / "Slices of the ForEach" will get disposed of.

So a ForEach region is as much a lifetime manager as ManageProcess, just for many instances of the patch (one per index).

However, currently, the patch instance gets also disposed of when the user feeds False into the Keep pin.

Proposed Refinements

  • option "Always Keep State". We'd be able to use the Keep pin to decide what data shall go into the splicers, but we'd always keep the state of the region for this index. Currently, the state of the region gets thrown away, which sometimes feels wrong.

  • option to Synchronize to a key: It feels off that we sync to an Index. It would make more sense to sync to a Key.

  • If the Key is new -> Create a patch instance. If the Key is known reuse the patch instance. All Keys that disappeared from one frame to the other result in Disposing of the patch state. This is currently done in so-called Synchronizer regions, which no one uses or knows of as it's too hard to explain what they really do and why you need them. My intuition now is that their functionality is more natural than just using the index as the key.

Variations for determining the key:

  • "Use All Splicers as Keys": a tuple of all splicers is used as a key. We wouldn't need to pick one slicer.
  • Introduce a special keyword ("Slice Key", "#" or "key"..). When using this keyword in the splicer name this one gets used as the key.
  • If the compile time type is an IVLObject we could use the Identity as the key (instead of the reference).

We could throw away the complicated synchronizer regions and when a user creates a new ForEach enable this new behavior as the default.

Model-Runtime & Model-View synchronization, which is getting more and more common would get a lot simpler than current approaches.

gregsn avatar Jul 14 '23 17:07 gregsn

related: https://github.com/vvvv/VL-Language/issues/47

gregsn avatar Jul 14 '23 19:07 gregsn

Seems related: https://discourse.vvvv.org/t/strange-behaviour-of-keep-in-foreach/21121

bj-rn avatar Jul 14 '23 20:07 bj-rn

I have some recollection that I did a branch once where the loop behaved like described but it was disregarded as no use there are sync regions doing that ;)

will need to dig in our history how it was called..

azeno avatar Jul 15 '23 12:07 azeno

Here it is (only visible in internal repo): https://github.com/devvvvs/vvvv/compare/dev/azeno/keyed-loop

azeno avatar Jul 17 '23 12:07 azeno