Keyframing Convert to FLOATS (MTB)

ComfyUI's type system is just string matching - a LIST output only plugs into a LIST input, even if two different packs are both holding a list of the exact same numbers under a different type name. OPAC2Floats exists purely to solve that mismatch for one specific pairing: it re-types this pack's OPAC schedule outputs into FLOATS, the custom type used by mtb, the well-known keyframing/utility node pack from developer melMass (a name that shows up in the ComfyUI ecosystem's own informal roll call of node developers alongside people like kijai and rgthree).

What it does

Every input is optional and independently typed LIST: zoom, angle, translation_x, translation_y, translation_z, rotation_x, rotation_y, rotation_z - matching OPAC's output names one-to-one. Each gets converted to the matching FLOATS-typed output. There's no logic here beyond the type conversion itself - wire in only the schedules you actually need converted; anything left unconnected simply doesn't produce output on that channel.

Where you'd use it

Only relevant if you actually have mtb installed and want to drive one of its keyframing/animation nodes using a schedule generated by this pack's OPAC node. If you're not running mtb nodes anywhere in your workflow, you have no reason to touch this node - it exists exclusively as a type-compatibility bridge between two specific packs, not as a general-purpose conversion utility.

Installing it

ComfyUI Manager: search SaltAI-Open-Resources. Manual install:

cd ComfyUI/custom_nodes
git clone https://github.com/get-salt-AI/SaltAI

Restart ComfyUI. This node itself needs nothing extra - but note it's only useful alongside a separate pack (mtb), which you'll need to install on its own if you don't already have it, since SaltAI doesn't bundle or depend on it.

Common issues

If a downstream mtb node still refuses the connection after running your schedule through this converter, double-check you're wiring the right output - each of the eight outputs corresponds to a specific input, and it's easy to grab the wrong one when there are eight nearly-identically-named ports side by side on the node. If you only need one or two of the eight schedules converted, only wire those in - there's no requirement to connect every input just because they're all present on the node. And remember this node changes the type label, not the values - if the numbers themselves look wrong, the bug is upstream in OPAC's range/tremor settings, not in this conversion step.