TiXL Import

MKRTiXLImport is the other half of the pack's Tooll bridge - the side that reads. Its sibling MKRTiXLFramePlan writes a spec for sending a frame into a Tooll graph; this node ingests a payload that comes out of Tooll and normalizes it into structured, reusable JSON. If you're building the "Tooll decides, ComfyUI renders" loop, this is where the Tooll side of the conversation lands in your graph.

The mechanism is a normalize-and-split. You hand it a tixl_payload_json blob (the raw packet from the TiXL add-on), and it parses that into a normalized packet with fields like graph_name, layers, bpm, transport, and resolution, then fans those out into four different views of the same data. One input, four ready-to-consume outputs - classic plumbing in the pack's style, turning a blob you can't read into a manifest you can wire directly into other nodes.

The input

Just one required field: tixl_payload_json. Paste the payload the Tooll add-on produced, or wire it in from wherever the packet arrives.

What comes out

• tixl_packet_json - the normalized packet, the closest thing to ground truth.
• layer_manifest_json - a layer_manifest with graph name, layer count, and the layers themselves. This is the bit you'll most likely feed downstream nodes, because it tells you what's actually in the composition.
• timing_json - BPM, transport, and resolution. Useful if your ComfyUI side needs to react to tempo or sync state.
• summary_json - project name, graph name, operator name, transport, layer count, and any parse warnings.

Installing it

Part of criskb/MKRShift_Nodes from Cris K B. ComfyUI Manager search "MKRShift_Nodes", or:

cd ComfyUI/custom_nodes
git clone https://github.com/criskb/MKRShift_Nodes

Restart. No pip requirements, no models - it's JSON in, JSON out.

Where it gets thin

The honest caveat is the same one every plan/import node in this pack carries: it's a format handler, not a live connection. It will parse whatever the TiXL add-on emits, but the packet has to get to you some way - pasted in, written to a file, or delivered by one of the network runtime nodes. If summary_json shows warnings, that's usually a payload that didn't match the schema the pack expects, so check the shape of what Tooll actually produced before blaming the node. And if your workflow is one-way (just rendering Tooll output), you can often skip this entirely and use only the frame plan on the outbound side.