Difforum · Audio Curve

Audio Analyzer gives you numbers. This node makes them useful by wrapping one band around a base value with an amount, and emitting a schedule that any Difforum socket expecting a curve will accept.

The mechanism, and why it's this simple

The output is base + amount * band per frame (or subtract, or multiply - that's the combine enum). That's it. No envelopes, no keyframes, no expression language.

That sounds too plain until you use it. The classic Deforum-bass-pump effect is: base 0.45, amount 0.2, source low, combine add. Silent sections sit at denoise 0.45 - a steady, morphing image - and every time the bass hits, the frame gets pushed toward 0.65 and re-imagined harder. The result isn't a jittery mess; it's the picture breathing with the track, because the underlying band is already smoothed and normalised.

The five inputs

• source - which band drives the curve: amp, low, mid, high, onset, beat. Bass gives the pump, beat gives hard pulses, onset is the tightest of the three.
• combine - add, subtract or multiply. multiply is the odd one and the most interesting: with base 1.0 and amount 0.3 you get a curve that sits at 1 and dips to 0.7, which is a nice way to make something stop on the beat instead of starting.
• base and amount - the floor and the swing, both with a huge range because they're not always denoise. A beat curve with base 0.9 and amount 0.4 is a perfectly reasonable thing to wire into the Camera (expressions) x-axis.
• smoothing - extra smoothing on top of whatever Audio Analyzer already applied. 0.2 is a good default; raise it when the band is spiky.
• params and audio_curves - from Setup and Audio Analyzer respectively.

Where it goes

The schedule output is a DIFFORUM_SCHEDULE, which is the pack's universal "number per frame" type. Feedback Sampler's strength socket replaces the Director's energy curve. cfg_curve does the same for cfg. The seven *_curve inputs on Camera (expressions) replace the text schedule for that axis entirely. Prompt Travel and Schedule Plot take one too.

Worth saying plainly: you don't have to use expressions to be audio-reactive. A Director camera block with an audio reaction, driven by an Audio Curve on the energy socket, covers the overwhelming majority of music-video work. The expression syntax is there if you want it, not because you must.

Install

Manager → search "Difforum", or clone:

cd ComfyUI/custom_nodes && git clone https://github.com/chillithebillis/Difforum.git difforum

Restart ComfyUI. numpy only - the audio maths is FFT and interpolation, so there's no extra dependency to break on your next ComfyUI update.

Where people get burned

The mistake is watching the curve instead of the output. Values are clamped by whatever consumes them, so a base 0.45 / amount 2.0 curve doesn't explode, it just spends most of the clip pinned at 1.0 - which reads as "the audio doesn't do anything" and sends people back to the analyser for no reason. Start with sane amplitudes (0.1–0.3), check the plot in Audio Analyzer, and only then get greedy.

The second one is subtler: if the curve drives denoise for a turbo or LCM model, the effective step count scales with the curve, so the loud parts of the track cost more time. On a 2-step model that's nothing. On a 20-step SDXL clip it's the difference between a 4-minute and a 9-minute render, and it's the reason Audio Curve ends up paired with cadence 2 more often than not.