Mie Loop State Get String ๐
Pulling accumulated text out of a ComfyUI loop
- loop_ctx
- STRING
If you're running a loop that builds up text as it goes - an evolving prompt, a growing log of what each pass did, an LLM's running commentary - you hit the same wall every loop hits in ComfyUI: nothing survives between laps unless you explicitly carry it forward. Get String is how MieNodes lets you read back whatever text a previous iteration wrote.
Mechanism. State travels through the loop as a custom object type, MIE_LOOP_CTX, which other nodes in this pack's Loop category produce and update. Get String takes that context and a key, and returns the string currently stored under it. If nothing's there yet - first lap, or a key that doesn't line up with what a Set node wrote - you get default_value instead of an error.
The stock key, feedback_string, matches the naming across the whole family and hints at the design intent: a loop where each pass produces some kind of feedback - an LLM's critique of the last output, a running caption, an accumulated log - that gets read back in to shape what happens next.
What's on the node.
loop_ctx(required) - has to come from this pack's own Loop nodes; the type is enforced, so nothing generic slots in.key(defaultfeedback_string) - rename it per value if you're carrying more than one string through the loop (a prompt and a log, say).default_value(default empty string) - what you get before anything's been written.
The output is a plain STRING, ready to feed into a text encode node, a prompt concatenation, a log display, or anywhere else text is expected.
Installing. Through ComfyUI Manager, search ComfyUI_MieNodes (the pack's registry title) and install. By hand: cd ComfyUI/custom_nodes && git clone https://github.com/MieMieeeee/ComfyUI-MieNodes, then restart ComfyUI. Nothing here needs a model download - it's plain state-passing.
Worth flagging: the pack's README doesn't cover the Loop category at all, no node table and no example workflow for it. The description above comes from reading the schema directly and from how a loop like this mechanically has to be wired, not from confirmed documentation - a reasonable working guess, not gospel.
Troubleshooting.
- Always getting
default_value. Two usual causes: it's genuinely the loop's first pass and nothing's written yet (expected), or thekeyhere doesn't match character-for-character what the corresponding Set String node uses - these fields are free-text and case-sensitive, so the mismatch fails silently rather than throwing an error. - String is growing when you expected it to be overwritten, or vice versa. Whether text accumulates across passes or gets replaced each time depends entirely on what your Set node does with the incoming value before writing it back - if you want accumulation, you generally need to read the old string, concatenate onto it, and write the result back yourself; this node just reads whatever's there.
- Text looks truncated or garbled after several loop passes. If the string is being built up by an LLM call each iteration, check whether an upstream connector's token limit is clipping the output before it ever reaches this node - that's a generation-side limit, not something Get String does.
- Socket type error on
loop_ctx. You're wiring in something other than another Loop-category node's context output from this same pack.
Inputs (3)
| Name | Type | Default | Description |
|---|---|---|---|
| loop_ctx | MIE_LOOP_CTX | โ | |
| key | STRING | feedback_string | โ |
| default_value | STRING | โ |
Outputs (1)
| Name | Type | Description |
|---|---|---|
| STRING | STRING | โ |