70 Shaders You'd Actually Use

There's a reason RenderWave ships 70 shaders instead of 316. When a catalog grows past a couple hundred pieces, the average quality drops fast. Most of those shaders never make it onto a real club rig — they look great in a static thumbnail, then stutter under load, fight the audio analyzer, or break when you push them to 4K. A library full of "yes that one too" entries makes you slower in front of an audience, not faster.

Every RenderWave shader has a production budget behind it. We write the Metal-compute kernel, then we audio-test it on real tracks across techno, house, drum & bass, and ambient. We tune parameter ranges so a MIDI knob sweep always lands on a usable look. We benchmark each kernel against a 4K60 performance budget on M2 — if it can't hold the frame, it gets rewritten or it doesn't ship. Each shader is a deliberate piece of work, not a checkbox.

The architectural decision underneath this is Metal-compute, not ISF-interpreted. ISF is a great open format, but it's interpreted at runtime over OpenGL or a Metal compatibility layer. RenderWave's kernels are direct MTLComputeCommandEncoder dispatches authored against the Apple Silicon GPU. That means lower latency, lower power draw, and headroom to stack effects without dropping frames.

The per-band audio modulation is the other half of the story. A library where every shader has been tested with bass / mid / treble routing is more useful than a library twice the size where half the shaders don't react well to a kick. The 70 here all do.

ISF (Interactive Shader Format) is a wonderful open standard — it gave the VJ world a portable shader format and an enormous community library. But it's a JSON-described GLSL fragment shader, executed by a host that often runs OpenGL or a Metal compatibility translation. The host pays for parsing, parameter binding, and context-switching every frame.

RenderWave's shaders skip that entire layer. Every kernel is a Metal compute function authored against the Apple Silicon GPU directly. The runtime hands the kernel zero-copy access to the previous frame, the audio analysis buffer, the parameter uniforms, and the output texture. There's no interpreter, no JSON, no GLSL-to-Metal pass.

Concretely, the dispatch loop looks like this:

// Per-frame, per-shader dispatch (simplified)
let encoder = commandBuffer.makeComputeCommandEncoder()
encoder.setComputePipelineState(shader.pipeline)
encoder.setTexture(prevFrame, index: 0)
encoder.setTexture(outputTexture, index: 1)
encoder.setBuffer(audioBands, offset: 0, index: 0)   // bass / mid / treble
encoder.setBuffer(paramUniforms, offset: 0, index: 1)
encoder.dispatchThreadgroups(grid, threadsPerThreadgroup: tg)
encoder.endEncoding()

The pipeline state is built once at load and cached. Parameter changes from MIDI, audio, or the sequencer write into a single uniform buffer — they don't trigger shader recompilation. The kernel reads the audio bands as a tiny structured buffer, not as global state. That's why per-band audio reactivity stays cheap even with eight effects stacked on top.

The practical result for VJs: RenderWave can hold 4K60 with the audio analyzer running, MIDI feedback active, Syphon output enabled, and three post-processing effects chained. ISF-based hosts on Mac can match the look — they just need more GPU headroom to do it, which means less budget for other effects in your stack.

A lot of audio-reactive shader libraries hand you a single "loudness" value. That's enough for a strobe — it's not enough for a club set. RenderWave's audio engine runs an FFT on the live input and splits the spectrum into bass, mid, and treble bands with adjustable crossover frequencies. Each band is exposed to every shader as a separate value.

That means a tunnel shader can have its camera speed driven by bass while its color shift is driven by treble. A particle emitter can spawn from mid-band hits while its size pulses to the kick. A distortion shader can stay quiet during breakdowns and slam during the drop. You're not modulating a single global parameter — you're routing three independent envelopes into the kernel.

Each parameter slot has its own modulation depth, smoothing time, and response curve. Combine that with the modulation envelopes from the sequencer and the MIDI-mapped knobs, and every shader becomes a fully playable instrument rather than a fixed loop.