Do not use tensor tuple past sampler

[WASasquatch]

A tuple list is not editable. You cannot add to remove, or dynamically (easily) rebuild it without knowing total tensors and catting them manually by code (which means a whole huge conditional block to handle every possible size in nodes).

After the ksampler, tensors should be converted to a simple list of tensors for post processing management. Otherwise you're limited to very basic tensor operations on the whole batch which severely diminishes the continuity of a node system.

[comfyanonymous]

What do you mean? You can edit tensors pretty easily and can get their shape with: .shape

Do you mean you want batches to be able to contain multiple tensors/images of different sizes?

[WASasquatch]

The output of a batch from ksampler is a tuple, which cannot be added to, removed from, concat, etc, it's elements are predefined.

We should actually be using a dict system from node output really, easily added too, could carry irrelevant information for certain nodes, but key for use for others, like piping "meta" information of sorts.

For most outputs we are even doing something like return (output,) and creating a single element tuple.

[comfyanonymous]

It's a tuple because that's the normal way of making functions return multiple values in python. Each index in the returned tuple corresponds to an output of a node.

For example LoraLoader has 2 outputs: https://github.com/comfyanonymous/ComfyUI/blob/master/nodes.py#L247

It returns the two outputs like: https://github.com/comfyanonymous/ComfyUI/blob/master/nodes.py#L255

It doesn't make sense for nodes to have a variable number of outputs so it's a tuple.

[WASasquatch]

It doesn't make sense for nodes to have a variable number of outputs so it's a tuple.

That seems highly subjective... most every node system is sharing more then just a result with a node connection... Programs I use send dozens and dozens of parameters through a single pipe for various stuff down stream. They also make sure it can be edited by other nodes, sending it down stream, as it's inherently a node network, designed for this exact usage.

Any of this functionality can still be handled like

{
  "output": {
    "output_1": someTensor,
    "output_2" whatever
 },
 "whatever_other_data": { 
    "something": something,
    "etc": anotherObject
  }
}

It seems some functionality is already set up this way with like the UI aspect for image, and hopefully text output, and heck, it would be continuous and conducive with input setup.