Stoatworks Labs

AWJ Surface

A fader that follows the switcher back

Field testingApplicationJavaScript
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 runs from a web interface, which is fine for building a show and no fun for running one. Opacity, size and position are continuous values, and a continuous value wants a fader under your hand, not a number in a box. This puts a control surface on the frame.

A surface that only sends is only half useful, so this one works both ways. Writes go out, and the device's own state comes back to the motors, the LED rings and the scribble strips. Four controllers come 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 you can diff them and take them with you.

Three things make this harder than a lookup table. A layer's path includes a preset letter, and which letter is on air changes at every take, so bindings say PREVIEW or PROGRAM and get resolved on every event against the live state. A preview fader that turns into a live one halfway through a show without telling anyone is the failure I care about most. Every write is echoed back to all clients, which drives a motor fader into the hand that just moved it, so writes are tagged with where they came from and the echo to that control is dropped, while a change from anywhere else still moves it. And a fader without a motor lies after a bank change, so non-motorised bindings use pickup and write nothing until the control crosses the value it's steering.

The Bring-up tab is there because a MIDI implementation chart is just the sort of document that's wrong in small, unhelpful ways. Sweep every control on the surface and it reports what the profile declared but never saw, and what the surface sent that the profile doesn't know about, with a guess at what each one is. A sign-magnitude encoder read as a fader is the commonest transcription mistake, and it doesn't look like a mistake. It looks like a parameter running away from you. The classifier catches it because an encoder never sweeps: its values bunch up either side of 0x40.

The engine has no I/O of its own. The local server in this repo is one host for it, and LivePremier Plus is another, running the same engine in a browser.

Where it stands

In development, not tagged yet. The parameter model and every path in it were read off a live LivePremier, and the whole chain (a fader move through to an opacity write, a TAKE, and the preset flip that follows it) has run end to end on a real Aquilon C, with the frame captured first and all 87 values checked as restored afterwards. On 9 September 2026 the catalogue was re-checked against a second Aquilon C on firmware 6.2.73: all 421 paths it generates (86 parameters across three preset letters and two layer kinds) were sent to the box and every one answered, and a layer opacity write round-tripped and restored on that frame too. Since 12 September the catalogue generator reads a Midra 4K / Alta 4K bundle as well, cut from a live Pulse 4K, but the MIDI engine itself still only speaks LivePremier. What hasn't happened yet is a physical control surface being plugged in. The four controller maps come from published documentation, not hardware, so treat your first run with a real APC40, X-Touch or MIDIcon as bring-up. That's what the Bring-up tab is for.