HandMod

A getUserMedia stream feeds MediaPipe's tasks-vision landmarkers, running on the GPU through WebGL where the browser allows it. Hands come back as 21 points each, the face as 478, the pose as 33, all in normalised frame coordinates. Each set is smoothed with a one-pole filter across frames before anything reads it, because raw landmark output jitters by a pixel or two even from a perfectly still hand and that jitter would otherwise arrive as audible noise on every lane.

The metric layer is pure maths over those points and is the part that is unit-tested: wrist-to-knuckle vectors become roll, pitch and yaw through a small orientation solver ported from the original tool; fingertip distances become spread and pinch; the convex extent becomes area. Shape mode takes four fingertips, orders them into a quad, and runs a shoelace area, a centroid, a long-axis angle and a segment-intersection test - that last one is what reports the twist, splitting the quad into two triangles and summing their areas instead.

Each enabled lane then reads one normalised value, applies its curve, scales it into its Min-Max window, smooths it again at lane level and emits a CC only when the rounded value actually changed, so a still hand does not spam identical bytes. Every event goes through the shared Audio & MIDI session to the selected destination, while a local parameter mirror keeps the page's controls visually in step without opening a second MIDI connection.

None of this is audio DSP, so HandMod has no kernel and no parity claim. It runs on the camera's frame clock rather than the audio block clock, and expect roughly 40-80 ms between a physical move and an audible change - most of it camera capture and model inference, not the mapping. That is fine for sweeps, swells and shapes, and it is not fine for triggering notes, which is why HandMod sends no notes.