ZML_变量_整数序列
Count 0, 1, 2, 3… into a subworkflow, one integer per parallel run
- 输入变量包
- 输出变量包
ZML_变量_整数序列 is the integer sibling of the parallel-variable family: a tiny node that hands each run of a subworkflow a different whole number. Where the float version is for cfg sweeps and strength ramps, this one is for counting things - which frame to load, which item of a list to process, which step of a pipeline you're on.
It slots into the same machine as every other ZML_ParallelVariable* node. You feed it into the "变量包" (variable bundle) socket of ZML_ParallelJsonContainer, give it a placeholder name, and it resolves to 起始值 + index * 步长 where index is the run number starting at 0. So with start 0 and step 1 - the defaults - run one gets 0, run two gets 1, run three gets 2. The value replaces every {{占位符}} marker in the API JSON you pasted into the container.
The inputs that matter
- 起始值 - INT, default 0. The count starts here.
- 步长 - INT, default 1. Step size per run; 2 if you want evens, -1 if you're counting down.
- 占位符 - STRING, default
整数. The{{name}}you write into your JSON workflow template. - 输入变量包 (optional) - merge this into an existing bundle from other variable nodes.
Output is 输出变量包 (VAR_BUNDLE), one bundle carrying everything, exactly like the float/text/seed versions. It's pure plumbing - the whole node is a two-line dict merge in the source - which is fine, because plumbing is precisely what this layer is for.
Where it earns its keep
A concrete, non-abstract one: you've got a folder of 40 reference images and you want each parallel run to process a different one. The image-folder variable node produces the list of paths; this int node produces 0..39; your sub-workflow JSON uses {{索引}} to index into that list. Same trick applies to batches of prompt lines, to batch_index-style sampling, to "pick LoRA number N" loaders. The README itself calls out the pattern of using integer nodes to select LoRAs by index so you can load them in sequence or at random.
You don't need this node for a single pass. You need it the moment you want 20 different runs of the same sub-workflow, each getting its own number, executed in parallel threads instead of serially. That's the "多线程子工作流" (multithreaded subworkflow) family this pack is proudest of.
Install
Part of the ComfyUI-ZML-Image pack, 160+ nodes, one install. ComfyUI Manager → search ComfyUI-ZML-Image → install, or:
cd ComfyUI/custom_nodes
git clone https://github.com/zml-w/ComfyUI-ZML-Image
Restart, done. No models, no extra deps beyond the torch/Pillow stack ComfyUI already runs, and English users will want the README's linked translation patch since the UI is Chinese-first. The container node's "执行完成后清理缓存" flag is worth turning on for big parallel jobs - it flushes VRAM and runs gc.collect() after all runs finish, which keeps a 32-thread sweep from leaving a mess behind.
Inputs (4)
| Name | Type | Default | Description |
|---|---|---|---|
| 起始值 | INT | 0 | — |
| 步长 | INT | 1 | — |
| 占位符 | STRING | 整数 | — |
| 输入变量包opt | VAR_BUNDLE | — |
Outputs (1)
| Name | Type | Description |
|---|---|---|
| 输出变量包 | VAR_BUNDLE | — |