hi @lecloneur,
the GetSlice (Channel)
might have the wrong name. This demo patch shows how it got into existence:
Combo Box with GetSlice
The motivation back then was to synchronize the output channel with the index channel. So when you change the downstream value - e.g. the String
or Vector2
representation - the Index gets changed. So the index gets changed not the entry within the original spread of entries.
In your example, you don’t want the index to get changed, but you want the input entries to get changed. This is best done by Select (byPath)
.
If someone has a better idea for a name for GetSlice (Channel)
, which avoids wrong expectations: that would be welcome.
HowTo Bind a Channel to a Property ByPath.vl (34.7 KB)
After getting rid of the GetSlice (Channel)
nodes your initial problem however still exists:
BindingAgainstTheWall SelectByPathOnly.vl (34.7 KB)
The actual problem here has something to do with
Person
being a class,
- Channel networks being loosely bound together
The Select (ByPath)
nodes each introduce a new channel.
So we have a main channel holding a Spread<Person>>
, which is bound to nine channels of type Person
, which are synced to nine channels of type String
. So a network of 19 channels, mainly connected together via the root channel. Like a starfish.
When pushing in the String channels the property Name gets changed in the Person instance. The person mutates - as it’s a class. Still the Select (ByPath) triggers the Person
channel with the mutated instance, even though the instance is not new. But it mutated, which also is some kind of valuable information. This in turn leads to the main channel getting triggered, again with a spread of the same 4 persons, which changed their name.
But since we have a network of 19 channels. Some of them didn’t get notified yet. Let’s see what happens when the main channel is triggered:
All bound person channels retrieve the person via index. Since the spread still contains the same 4 persons the event cascade stops and nothing gets pushed further to the string channels. This was done to avoid endless cascades. The changed name inside didn’t get looked at.
There are several possible solutions to this:
- We could make all participants in a channel network get notified of any changing channel. This could lead to more channels getting triggered without any actual change. But better be safe than sorry. However, this could also go against your intuition: channels triggering with unchanged values.
- Avoid too many cluttered
Select (ByPath)
nodes. This might be hard to do, since your patches are structured in a certain way. One way to try could be the usage of global channels and their subchannels. Global channels are shared channels. So you’d have nine channels: root, four persons, four names.
- Make Person a
Record
. Changes are detected easily. New Name → new Person → new Spread → new Person gets discovered → new Name gets discovered.
While writing this all up made some changes to Select (ByPath)
, now being more clever and respecting the class case. However, when the class is hiding somewhere deep inside such a graph, you’d still be able to run into this case. So in the end we might be forced to always trigger, even if the involved types are immutable (like the Spread), as sometimes mutating instances are hiding deep inside. Not super happy still. vvvv >= 6.7.86
BindingAgainstTheWall Reduced.vl (31.0 KB)
see clocks in the channel visualizations? Those show you the events.