RFC Discussion: RFC: Variable length node inputs

[github-actions[bot]]

This is the discussion thread for RFC PR #18.

Please provide feedback and discuss the RFC here rather than in the PR comments.

PR Link: #18

[bezo97]

Here's some food for thought: in Blender this is solved in 2 separate ways, not sure why there are multiple designs..

• This one is close to what the RFC proposes. Except the +1 "extra" input looks a bit different, like an empty socket. I think this is great because it looks distinct to having just multiple non-variable length inputs, so the user clearly knows that this is a variable-length input:
  
• The other way is that instead of separate sockets, there's just one socket that grows after connecting. This takes less space and no need to make up these indexed input names like conditioning_1
  

---

Regarding min_length >= 1 I don't see why 0 couldn't be accepted, ie. an optional variable-length input. If we go with the first Blender design then it could just be marked as an empty socket.

---

There can only be one variable length input per node at the last of parameter list.

This looks like a technical constraint of using the *args pattern. If possible, this could be changed to using eg. list or tuple arguments so multiple variable-length inputs can be present, and regardless of position.

[huchenlei]

Thanks for the feedback! Will add these aspects to the proposal.

This looks like a technical constraint of using the *args pattern. If possible, this could be changed to using eg. list or tuple arguments so multiple variable-length inputs can be present, and regardless of position.

Yea, let's use the tuple arguments. It would be more flexible than *args.

[webfiltered]

• there's just one socket that grows after connecting

This is what I want, also. It's so much cleaner. But would like it to be expandable in some way, so disconnects don't require tracing the noodles back to the other side.

[guill]

I appreciate that this RFC is attempting to avoid scope creep by focusing on variable length node inputs, but I think this is a case where it's worth considering how this implementation might be extended to support dynamic types as well (even if actually implementing them isn't within the scope of this RFC). If we ever want to support loops in core-ComfyUI, that's something we'll need to support, and if possible I'd like to avoid a situation where we have two different ways to implement variable-length inputs that each of their own quirks and limitations.

I have a separate 'RFC' that was posted as a draft PR (before the rfcs repo was created) that attempts to solve the same problem as this RFC while also supporting dynamic typing: comfyanonymous/ComfyUI#5293

If people prefer the public API syntax proposed in this RFC to the template-inspired syntax in the other, I think it's still worth considering implementing it on top of layers 2 and 3 as proposed in the other API. Even if we only publicly expose the variable length inputs for now (and not the dynamic typing), that sets us up to add support for the dynamic typing in the future.

[JorgeR81]

Could it be possible to have native, configurable bus node that works in a similar way to the Variable length node input ?

The Context (rgthree) node works well, but to use some data types ( e.g. mask or ControlNet ) we have to use the "Big" version, which is too cumbersome. 

The ideal solution would be a configurable bus node that would just take the inputs we plug int.

[MNeMoNiCuZ]

Wouldn't we need "separate" visual solutions for both when input order matters, and when it doesn't?

For example, a CONCAT STRING input would be order dependent.
But for an ADD INT math input, the order wouldn't matter.

In Unreal Engine (Blueprint), some inputs accept multiple inputs. But the system does a bad job of telling you which nodes/functions behave like this. It's usually shared upstream common functionality. Some inputs accept arrays, some just single inputs.

It's a little bit of a mess, but even though it's not taught/presented cleanly, it always works.

I like the tall vertical slots that @bezo97 presented from Blender. Those are a nice way of grouping them together, and I could see a similar ordered approach where they are not taking up "a full slot" each, but rather would look like "connected blobs", where the order is clean, and they would be re-arrangeable as well.

The blobs for connected inputs, and an "empty slot" to show that it accepts more inputs?

And with a context-menu for editing pin order.