TS Studio Input (Number)

Every generator has numbers: width, height, steps, cfg, denoise, strength. In a TS Image Studio backend workflow, those numbers are parameters the app exposes in its UI - and this node is the marker that carries one of them into the graph. TS Studio Input (Number) is a placeholder whose value the studio replaces at run time, and its one party trick is that it hands you the value as both a FLOAT and an INT, so you can wire the same parameter into either kind of socket without a conversion node in between.

How it works

Two required widgets, the standard marker pattern:

• param_name (default steps) - the identifier the studio uses to find this marker and set its value. Must be unique per workflow. Pick a name that matches what the parameter is for (width, steps, cfg, denoise, …) - that's the name users will see as the control in the studio.
• value - a FLOAT (default 0, range ±1e9 with 0.01 step) that the studio overwrites at run time. When you drag a slider or type a number in the studio, this is what changes.

The optional label replaces param_name with friendlier text in the studio UI.

The two outputs are the useful bit: float (the exact value) and int (the rounded value). Wire float into a denoise, cfg, or strength socket; wire int into a width, height, or steps socket. One marker, both worlds - which matters because a good chunk of ComfyUI's "why won't this connect" pain is trying to feed a FLOAT into an INT socket (or vice versa) and discovering core nodes don't always convert for you.

The mental model is shared with every studio marker: it's a slot in a template workflow that the studio fills before sending the graph to /prompt. Loaded by itself in plain ComfyUI, it just outputs the value that's in the field - so a backend file still runs by hand with its defaults.

Install and use

No extra dependencies - part of comfyui-timesaver.

cd ComfyUI/custom_nodes
git clone https://github.com/AlexYez/comfyui-timesaver
cd comfyui-timesaver
python -m pip install -r requirements.txt

If you're building a studio backend, the rules are the same as the other markers: unique param_name, wire the right output (float or int) to the socket it feeds. If you're just a user who found this in a workflow: it's the studio's wiring - the studio sets the number, you control it through the app's UI, not by typing here.

Common issues

• "The number in the graph isn't what I set in the UI." The studio overwrites value at run time; what you see in the widget is the last-set value (or the default). This is expected - the UI is the source of truth while the app runs.
• "It won't connect to my sampler." The studio app matches parameter types itself, but if you're hand-wiring a backend, remember: steps/width/height want the int output, denoise/cfg/strength want the float. Both are there - pick the right one.
• "Two markers with the same param_name." That's the duplicate-name trap; the studio will write to one of them and the other stays stale. Keep every param_name unique per workflow.

The honest scope: it's a one-value placeholder with a type convenience built in. Invisible when it works - which is the entire point of the marker system.