PC: Expand Macros
Expand Macros — preview what your DEF macros actually turn into
- STRING
Prompt Control lets you organize a complicated prompt with segments and macros instead of writing the same phrase out five times across a long schedule - that's the pack's own framing, under "Organize complicated prompts with segments and prompt macros." This node is a small, standalone utility built for that system: hand it a block of text containing macro definitions, and it returns the text with those macros expanded out, as a plain string.
What it's for
It doesn't encode anything or touch a sampler. Its job is purely to let you see - or reuse - what a macro-laden piece of prompt text turns into once expanded, without having to run it all the way through a full text-encode node to find out. That's useful two ways: as a debugging step, when a scheduled prompt built from macros isn't producing what you expect and you want to check the expansion is correct before blaming anything downstream; and as a building block, if you want to construct a macro-expanded string for use somewhere other than directly inside a PCTextEncode-family node's text field.
Inputs and outputs
One required input: text - a multiline string containing your macro definitions and references. One output: STRING - the same text with macros expanded.
Installing it
ComfyUI Manager: search "ComfyUI Prompt Control", install, restart. Or by hand:
cd ComfyUI/custom_nodes
git clone https://github.com/asagi4/comfyui-prompt-control
Nothing extra to download - it's a text-processing utility, no models involved.
Where people get tripped up
This is a low-traffic, tools-category node, and honestly most people never need it directly - the macro system works transparently inside PCTextEncode and friends without you ever having to expand anything manually. Reach for it specifically when you're debugging: if a scheduled or macro-heavy prompt is producing unexpected conditioning, running the same text through PCMacroExpand first and reading the STRING output tells you whether the macro expansion itself is the problem, or whether the issue is further downstream in scheduling or encoding. It isolates one stage of the pipeline so you're not guessing which layer broke.
Beyond that, keep in mind this node only expands macros - it doesn't resolve scheduling syntax, LoRA tags, or anything else PCTextEncode handles. Don't expect the STRING output to be a fully "final" prompt; it's one specific transformation, isolated for inspection.
Where this fits in a bigger prompt
The pattern this node supports - defining something once and reusing it by reference - is the same discipline that keeps a long, multi-region or multi-pass scheduled prompt maintainable at all. Once a workflow is juggling several IMASK() regions, LoRA schedules, and bracket-scheduling breakpoints in one block of text, repeating a long descriptive phrase in five different places is both tedious and a real source of typos - one segment gets updated, the copy in another segment doesn't, and the schedule quietly drifts out of sync with itself. Macros are the pack's answer to that, in the same spirit as defining a variable once and referencing it everywhere instead of copy-pasting a magic string.
PCMacroExpand doesn't change how that system behaves - it just gives you a window into it. Since the macro-expansion step happens invisibly inside every PCTextEncode-family node anyway, the only reason to reach for the standalone version is when you specifically want to inspect that one stage of the pipeline in isolation, separate from parsing, scheduling, and encoding. For a straightforward workflow without heavy macro use, you'll likely never wire this node at all - and that's fine, it's doing its job invisibly either way.
Inputs (1)
| Name | Type | Default | Description |
|---|---|---|---|
| text | STRING | — |
Outputs (1)
| Name | Type | Description |
|---|---|---|
| STRING | STRING | — |