Up to now the only way to select overloads was to pick single pins one by one. Users demanded a way of picking the overloads directly instead.
We now offer both modes:
picking overloads = picking nodes = signatures = a bunch of input pins
picking pins
From a technical point of view, it's the same basic idea (picking pins), only the way how you pick them differs.
Let's compare the two modes:
Signatures
Single Pins
In both modes, the common pins (pins that are present in all overloads) are omitted in order to avoid too much verbosity. E.g. all
Enumerable.GroupBy nodes come with a Key Selector input
Array.BinarySearch nodes come with Input and Value inputs
FromAdoptedTexture nodes come with a Context input
Enumerable.Min nodes come with the same pins, but their types differ. So they get listed.
Compatibility
The underlying system for overload selection stays the same, thus we have back-and-forth compatibility. The only difference is the way they get presented to the user, either
as packages of pins that make the different nodes identifiable or
as single pins that in combination will result in overload selection.
Here is an example of how a node reference gets serialized:
The only new bit is the attribute OverloadStrategy="AllPinsThatAreNotCommon". Earlier versions of vvvv gamma will just ignore that part and thus will be able to load new vl files. Newer versions will show all pins as one overload pick, removing the attribute would again just show the pins.
When are NodeReferences enhanced by PinReferences
Storing pin references in all node references would be too verbose and would blow up the vl files. So we only store the currently necessary parts to identify the overload. This is exactly what you get presented in the UI.
Up to now the only way to select overloads was to pick single pins one by one. Users demanded a way of picking the overloads directly instead.
We now offer both modes:
From a technical point of view, it's the same basic idea (picking pins), only the way how you pick them differs.
Let's compare the two modes:
In both modes, the common pins (pins that are present in all overloads) are omitted in order to avoid too much verbosity. E.g. all
Enumerable.GroupBynodes come with aKey SelectorinputArray.BinarySearchnodes come withInputandValueinputsFromAdoptedTexturenodes come with aContextinputEnumerable.Minnodes come with the same pins, but their types differ. So they get listed.Compatibility
The underlying system for overload selection stays the same, thus we have back-and-forth compatibility. The only difference is the way they get presented to the user, either
Here is an example of how a node reference gets serialized:
The only new bit is the attribute
OverloadStrategy="AllPinsThatAreNotCommon". Earlier versions of vvvv gamma will just ignore that part and thus will be able to load new vl files. Newer versions will show all pins as one overload pick, removing the attribute would again just show the pins.When are NodeReferences enhanced by PinReferences
Storing pin references in all node references would be too verbose and would blow up the vl files. So we only store the currently necessary parts to identify the overload. This is exactly what you get presented in the UI.
Node Configuration.zip