Stoatworks Labs

Aquilon VPU Map

Where every mixer in the chassis went

Releasedv1.2.0ApplicationJavaScript / Rust
Aquilon VPU Map — Where every mixer in the chassis went
The chassis map, read from a real Aquilon C.

What it does

A LivePremier will not tell you that a configuration does not fit until it fails to fit. The mixer allocation behind that answer is reported by the device in full, but the stock Web RCS shows it a panel at a time, so the question everyone actually has — is there room for another layer, and where — takes a tour of the interface to answer.

This puts the whole chassis on one screen. A VPU mixer is the physical mixing and scaling resource the device assigns to a (screen, layer) pair; an Aquilon has up to four processors of sixteen, and a layer too wide for one mixer is split across several as slices. That is why counting layers never tells you whether a configuration will fit, and why a single eight-slice native layer can eat an entire processor board.

The grid follows the manual's own figures rather than a re-invention of them: a row is one layer-capacity link and carries exactly one layer, columns belong to screens in contiguous runs, and a layer spread wider than four output links wraps onto another link with the manual's own hook. Optimized mode lifts that boundary for capacity-2 layers and only those, so those VPUs stop drawing the scaling-engine centre line.

The device keeps two copies of the map — `current`, which is running, and `new`, which is staged — so the tool also shows what applying the pending configuration would change, including the case where every difference is a link moving and no property changes at all. A properties-only comparison calls that no change.

Desktop builds for macOS, Windows and Linux are about 2 MB because they use the system WebView; there is also a server build and a container. It builds and runs on iOS and Android too, though neither is published. Screens are named the way you named them, read live from the frame.

Where it stands

Released at v1.2.0, and it has read a real Aquilon C end to end in two different configurations — the captures, the tests and the screenshots all come from that device, and the second configuration corrected two things the first had made look settled. What has not been exercised: Link setups (devices 2-4), capacities other than 4K and 5K, combined VPUs, Optimized mode and Cut & Fill. There is no Aquilon here any more, so the three recorded configurations in the repo are the whole ground truth, and the capture guide is written for anyone with a frame who can settle one of the open questions. The macOS builds are not signed, so Gatekeeper objects once.