RT HeartMuLa Info Dashboard

RT HeartMuLa Info Dashboard is a readout node. It takes the opaque handles your RT HeartMuLa Loader produced and turns them into a short human-readable string describing what's actually resident in memory: model class and dtype, codec class and dtype, and the device everything is on.

Why you'd want that: the loader returns custom HEARTMULA_MODEL / HEART_CODEC / HEART_GEN_CONFIG types that carry no visible information on the wire. When something sounds wrong, you usually want to know the boring facts first - did that codec_precision: fp32 actually apply, or did the loader fall back? Is the model bf16 or fp32? Is it on cuda or did something get shoved to CPU? This node answers those in one glance.

How it works

You wire in three of the loader's four outputs - model, codec, and gen_config (the tokenizer isn't needed here) - and the node's get_info() builds a string like:

Model: HeartMuLa (torch.bfloat16)
Codec: HeartCodec (torch.float32)
Device: cuda:0

It reads dtype and device straight off the loaded objects, so it's reporting what's actually in memory, not what you intended to load. That distinction is the whole point.

Inputs and output

• model - from the loader (HEARTMULA_MODEL)
• codec - from the loader (HEART_CODEC)
• gen_config - from the loader (HEART_GEN_CONFIG)
• Output: a single STRING

The string output isn't an image or audio preview, so it needs a text consumer. The pack's example workflow routes it to a ShowText node (from pysssss) so the info appears in the UI; any node that displays or logs a string works. It's not an output node itself, so don't expect it to render anything standalone.

When to use it

Honestly? It's a debugging convenience, and a fairly thin one - you won't miss it in a happy-path workflow. But it earns its keep in two situations: when you're toggling quantization/precision settings in the loader and want to confirm they took effect, and when you pick up a shared workflow and have no idea what settings the original author ran. One more tip: it's the cheapest way to sanity-check the loader's settings - though note it reports dtype, so a 4-bit-quantized model still shows its compute dtype (e.g. bf16). If you need the literal 4bit/none choice echoed back, the loader's console banner is the better tell.

Common issues

• No output / blank text - check the wire target. The STRING needs a text display node; if you left the output unconnected or wired it into an audio node, you'll see nothing.
• The dashboard shows only type(model).__name__ - that's normal for the model line; the codec line includes its dtype, and the device line tells you where it lives.
• You expected this to show quant info - it shows dtype, not the 4bit/none label. 4bit-quantized weights still report their compute dtype (e.g. bf16); use the loader's console banner if you want the literal setting echoed back.