💪TB | GenParams Debug Logger
See what's actually inside the genparams blob, without guessing
- genparams
- genparams
The TinyBreaker pack funnels every setting through one GENPARAMS blob, which is elegant - and also opaque. When an image comes out wrong, the first question is usually "what did the chain actually decide?" 💪TB | GenParams Debug Logger answers that by printing the contents of the blob to the console so you can see exactly what the sampler is about to receive. It's a dev tool, it's flagged as one in the pack's category (__dev), and it's the closest thing this ecosystem has to a debugger for the genparams pipeline.
How it works
It's an output node (it doesn't need to run in the normal flow; it's a terminal that observes). Feed it a genparams and pick how it dumps:
mode-no logging,user parameters(just the ones you set),short text values,long text values, orkey/value pairs. "Short text values" truncates long strings so a giant prompt doesn't bury the numbers; "long text values" dumps everything; "key/value pairs" is the raw map, which is what you want when a key name matters.filter- a prefix filter, soimage.aspect_ratiologs only that param, anddenoising.refinershows everything under the refiner. Empty logs all. This is the killer feature - TinyBreaker's param keys are dotted paths likedenoising.base.noise_seedandimage.batch_size, and filtering by prefix turns a wall of text into a targeted readout.flag- a free-text marker that prefixes the log line, so when you have several loggers in one graph (or are logging at several points in the chain) you can tell them apart in a busy console.
Output - the same genparams you fed it, passed through untouched. You can splice it inline (log → continue chaining) or leave it dangling as a pure monitor.
When you'll actually want it
Two moments. Debugging a "why did that come out at this size/seed/CFG" mystery - stick it after the suspect node, filter by denoising, and see what the values really are versus what you think you set. And when you're writing a custom style: log with filter styles to confirm your overrides landed. It also demystifies the pack - seeing the real default keys (base sampler uni_pc, refiner deis, CFG 3.4 vs 2.0) teaches you the architecture faster than any tutorial.
Install
The usual pack install - ComfyUI Manager search "tinybreaker", or git clone https://github.com/martin-rizzo/ComfyUI-TinyBreaker into custom_nodes, restart. Console output appears in the terminal where you launched ComfyUI (enable it there; the pack logs via its own logger).
The gotcha
It's a read-only observer, so it can't fix anything by itself - and it won't log anything if the genparams it receives is empty or if the nodes before it never populated the keys you're filtering. If a filter shows nothing, that's information too: the key isn't in the blob, which points at a chaining problem upstream. Don't leave loggers in your production workflows - they're cheap, but they're console noise you'll stop reading, and "user parameters" mode exists specifically to keep normal runs quiet.
Inputs (4)
| Name | Type | Default | Description |
|---|---|---|---|
| mode | COMBO | user parameters | Select the logging mode. |
| flag | STRING | Flag to mark the logging. | |
| filter | STRING | The prefix of the parameter to be logged, empty to log all parameters. e.g. image.aspect_ratio | |
| genparamsopt | GENPARAMS | The generation parameters to be logged. |
Outputs (1)
| Name | Type | Description |
|---|---|---|
| genparams | GENPARAMS | The same input genparams. (you can use this output to chain other genparams nodes) |