Stoatworks Labs

AWJ Surface

A fader that follows the switcher back

In developmentApplicationJavaScript
AWJ Surface — A fader that follows the switcher back
No screenshot yet — the interface is a mapping editor and an on-screen mirror of whichever surface is attached, and no physical surface has been attached to it.

What it does

A LivePremier is driven from a web interface, which is fine for building a show and wrong for running one. Opacity, size and position are continuous values, and a continuous value wants a fader under a hand rather than a number in a field. This maps a control surface onto the frame.

A surface that only sends is half a surface, so this one is bidirectional: writes go out, and the device's own state comes back to the motors, the LED rings and the scribble strips. Four controllers ship mapped from their published MIDI charts — Behringer X-Touch, Akai APC40, Elation MIDICON PRO and MIDICON-2 — plus an OSC layout and a learn-anything profile. Profiles are plain JSON, so they diff and they travel.

Three things make this harder than a lookup table, and each is solved rather than worked around. A layer's path contains a preset letter, and which letter is on air changes at every take — so bindings say PREVIEW or PROGRAM and are resolved per event against live state, because a preview fader that silently becomes a live one halfway through a show is the failure that matters. Every write is echoed back to all clients, which drives a motor fader into the hand that just moved it, so writes are attributed and the echo to the originating control is dropped while a change from anywhere else still moves it. And a fader that is not motorised lies after a bank change, so non-motorised bindings use pickup and write nothing until the control crosses the value it is steering.

The Bring-up tab exists because a MIDI implementation chart is exactly the kind of document that is quietly wrong. Sweep every control on the surface and it reports what the profile declared but never saw, and what the surface sent that the profile does not know about — with a guess at what each one is. A sign-magnitude encoder read as a fader is the commonest transcription error and it does not look like an error; it looks like a parameter that runs away. The classifier catches it because an encoder never sweeps: its values cluster either side of 0x40.

The engine has no I/O of its own. This repo's local server is one host; LivePremier Plus is another, running the same engine in a browser.

Where it stands

In development and not tagged yet. The parameter model and every path in it were read from a live LivePremier, and the whole chain — a fader movement through to an opacity write, a TAKE, and the preset flip that follows it — has been exercised end to end on a real Aquilon C, with the frame captured beforehand and all 87 values verified restored afterwards. What has never happened is a physical control surface being plugged into it: the four controller maps come from published documentation, not from hardware, so treat a first run with a real APC40, X-Touch or MIDIcon as bring-up. That is what the Bring-up tab is for.