Getting data for variadic nodes


Is there a way to determine what the arity is for a node, or what level we are currently on?

The reason I ask is I’m looking to implement an LCD node with variable number of lines. I will need to know total number of lines selected to initialize LCD, and I need to know what level I’m currently on to know which line of LCD to write to. In my case, I need to get this info from my C++ code; I would imagine it would be quite a bit harder to provide the info in a std patch not using C++ code…

I guess I could use node state to determine line to write to, but I still need to know total # lines while still on line 1. I could add a pin that has to match # lines, but that seems tacky…



That’s a very interesting use case. If only we haven’t to know the total number of lines for initialization… I’d told you how it’s can be done right now. Back to reality. In its current implementation, the information you’re asking for is totally inaccessible to C++ because the expansion is performed on a stage preceding the stage of code emission. From the transpiler’s point of view, variadics do not exist, it sees just a bunch of regular nodes arranged as cascade like they were created by hand.

I thought a little bit about the problem, and technically the expansion stage could inject special pins bound to constants of the arity and the current level. Maybe it’s a good idea which requires investigation.

I will think more about it. Perhaps, there’s another way which is closer to what we have right now. Never know what you can do with XOD :wink:


input-vlevel could be a hidden accumulator pin that gets initialized (to ?0 or 1?; 1 probably makes more sense since it would match variadic-* and arity #) on entry and incremented for each level. This could be simulated now with dummy pins that would show on node, but should never be used except internally by the node.

I suppose arity is known when you do the expansion, so input-arity could be a special shared pin.

Having these also lets you know if you are on the last iteration when that information would be useful, like for Average function (done totaling, now divide by arity).

Adding these special input pins make the data available to the node, but would not create visible pins when the node is used. Maybe this is where we need a new shape, like a diamond instead of circle for these hidden pins… We would never be able to manually set value for the pins, and there is really no reason to change the name of them. Both pins would be invalid on a node without the variadic-* flag & only one of each pin would be valid per node.