Curve_1 * Curve_2
How you actually shape prompt weights in this pack
- curve_1
- curve_2
- KEYFRAMED_CURVE
If you pick one curve operator to learn in this pack, make it this one. Multiplication is the operation that makes a curve mean something, because it's how you scale, gate, and combine influences. Multiply a weight curve by 0.5 and you've halved every prompt's contribution at every frame. Multiply two curves together and you get an "and" - the result is only large where both inputs are large, which is how you build a curve that says "strong during the night section, but only during the night section of the loop."
It's also the workhorse of the pack's marquee trick. In the "prompt entanglement / superposition" workflow, each prompt gets a sinusoidal curve between 0 and 1, and the conditionings are weighted by those curves and combined. Those sinusoidal weights get where they need to go through multiplication, and this node is where that math happens in the graph.
How it works
The mechanics mirror every other curve operator: both inputs are deep-copied and curve_1 * curve_2 runs from the keyframed library. Values are multiplied at the union of the keyframes of both curves - each timestamp that exists in either parent appears in the result, so neither curve's shape gets lost. Because it's element-wise across time, multiplying a curve by a Constant-Valued Curve of 1.0 is a no-op (the identity), and by a constant curve of 0.0 you get a flat zero - both useful properties once you're composing larger graphs.
The inputs
curve_1,curve_2(both required,forceInput) - the two curves. If you're gating one curve by another, the order doesn't matter mathematically.
The output
KEYFRAMED_CURVE - the product, feedable into anything that accepts a curve.
How to install it
Standard for the pack: ComfyUI Manager → search ComfyUI-Keyframed, or
cd ComfyUI/custom_nodes
git clone https://github.com/dmarx/ComfyUI-Keyframed
then restart ComfyUI. No model downloads; the only real dependency is the keyframed library (plus toolz), auto-installed on first import if missing.
Troubleshooting
The trap with multiplication is the union-of-keyframes behavior cutting the other way: if your gating curve was built at a high keyframe density, the product inherits all that density, and a curve that looked smooth in isolation can render jagged once multiplied. Plot the result before you trust it. Second, and this one catches everyone once: an optional input left at its default on the x10 multiplier variant defaults to 1 (the identity), not zero - so if a multiply-anything node isn't changing your curve, one of its slots is probably silently multiplying by 1. That's the designed behavior, but it's the opposite of the add variant's zero-default, and switching between the two without thinking has burned more than one workflow.
Inputs (2)
| Name | Type | Default | Description |
|---|---|---|---|
| curve_1 | KEYFRAMED_CURVE | — | |
| curve_2 | KEYFRAMED_CURVE | — |
Outputs (1)
| Name | Type | Description |
|---|---|---|
| KEYFRAMED_CURVE | KEYFRAMED_CURVE | — |