For module development it would be nice to have a built in “Changed” hidden output pin for IOBoxes of standard types (value, color, string, enums, maybe raw) so one should be able to avoid creating a Change node for every IOBox they have in their module for scenarios need such thing (like UDP sending modules)
many thanks for such a thing!
if it’s possible can we also have a SpreadMax like thing in patch which would behave the same as in the plugins (getting the greatest slicecount of the input labeled IO boxes) maybe coming from the Self (VVVV) node. It is really pain in the arse doing that manually with count nodes and a max node.
The plugin interface for 33.8 seems quite complete about that for all major (serializable) data types.
change can be detected with the IsChanged flag of IDiffSpread (or even ISpread, and Pin anyway), and if not (eg for unboxed types), you can use the CheckIfChanged flag of the InputAttribute to force it to check.
I make extensive use of it in the new Message pack.
concerning SpreadMax: do you need that to pump up a value with a select node, so that it has the same value for the whole “bin” and by that aligns others bins (spreads of spreads)?
if yes, it would be good to know if you could move that part of that functionality to a VL patch (or which nodes you need that aren’t yet available). You wouldn’t need a spreadmax and also no select node then…
Try to set a type annotation “Sequence” on one pad to get a binsized pin in vvvv.
By that you can align a bin on one pin with a slice on another pin…
About Change: i need to check if there is a way to implement that without performance loss.
@gregsn: it was before VL appeared in vvvv, however there are some completely valid scenarios when you want to control spreadcount like that in a module, like spreading Substitute (String)
@microdee: ok. maybe that node just misses binsize pins? (are you refering to the right most example in its help patch?)
maybe also it behaves a bit strange by default (according to the comment in the middle example in the help patch).
i have the feeling that this is a very special case and typically nodes match slices of different inputs in a strait forward manner. since this node doesn’t, it might be a hint for us to rethink it and offer binsize pins to allow replacement of ALL pairs to each single slice?
maybe the default behaviour should be that only the first FROM-TO-pair should apply to the first input slice? …
well the binsize there definitely would help, anyway this is just a first-world problem, the changed pin would be more essential, maybe as an option in config pins if it’s not free performance-wise
