EmAySee String Tuple Input

I'll let the pack's own README speak first: this node's title there is literally "EmAySee String Tuple Input (DEV NODE, Wouldn't use it)". The author marked their own node as not worth using, and that is about the most honest documentation you'll get in this pack. So the real question is: what is it, and should you care?

Mechanically it's trivial. You paste a multiline string - one item per line, the default placeholder is "Label 1 / Label 2 / … / Label 20" - and it splits the text on newlines into a Python tuple of stripped strings, output as a STRING_TUPLE. That's the whole node: a text-to-tuple converter.

The catch is the output type. STRING_TUPLE is a custom type that only means something if another node in your graph declares it as an input. ComfyUI doesn't ship with a string-tuple consumer, and within this pack there's no obvious downstream node that expects it. If nothing can receive STRING_TUPLE, the output socket is a dead end - you can't wire it into a plain STRING input, so it sits there looking useful and connecting to nothing. That's presumably why the author called it a dev node: they used it while building something and never finished the consumer, or the consumer lived in an experimental workflow.

The input that matters

• string_list (multiline STRING) - one item per line. Blank lines get skipped? Not exactly: every line becomes a tuple element, just with surrounding whitespace stripped. Empty lines become empty strings in the tuple. So don't leave stray blank lines unless you want empty entries.

Output is STRING_TUPLE_OUTPUT - a tuple of the lines.

Installing it

With the rest of the pack - ComfyUI_EmAySee_CustomNodes via ComfyUI Manager, or:

cd ComfyUI/custom_nodes
git clone https://github.com/EmAySee/ComfyUI_EmAySee_CustomNodes

Restart and it appears under EmAySee_Utils. Zero dependencies, zero models.

Should you use it?

Honestly? Probably not, and not just because the author said so. If you need to feed a list of strings into something, almost every pack that consumes lists does it via a type that actually has consumers - wildcard syntax {a|b|c}, CSV strings, or a LIST type from another utility pack. If you're already running a node that declares a STRING_TUPLE input (check the tooltip on your target node), this one will happily feed it. If you're not, it's a curiosity. Worth keeping in mind as a neat illustration of this pack's character: sixty-odd nodes, auto-loaded from a single folder, some of them finished tools and some of them the author's own scaffolding left in the drawer.