Web tools
Some of our tools don't need to be a download. These run in a browser tab, on your machine, on a show day — no account, no install, and no file of yours going anywhere near a server we own.
01 — PMSE Licence → Wireless Workbench
So the frequencies get typed in by hand. Two dozen of them, from a schedule, into a coordination tool — which is slow, and is exactly the job that produces a transposed digit at four o'clock on a show day. This reads the licence and writes the import files instead.
It's free and open source, like everything else here, and it started life as a standalone app you could self-host. It still is one — but the version you'd actually use now lives inside RFutils, our RF suite, under Convert › Ofcom PMSE licence, where the PDF parser has been validated against a real Ofcom licence.
.txt
Documented format
The licensed frequencies in Shure's own documented import format — megahertz, three decimals, one per line. Import it through Wireless Workbench's Import frequencies from file. This is the safe path, and for most jobs it's the only file you need.
.csv
Documented format
Every frequency mapped to a suggested channel name and to its Ofcom coordination and fee group. An Ofcom licence carries no per-microphone names — it is a list of frequencies — so this is the sheet you label channels from, and the one you hand to whoever is patching.
.shw
Experimental
A native Wireless Workbench 7 show file with receivers built, channels named and frequencies already assigned. An in-page editor groups the frequencies into receivers of any channel count from one to eight — not fixed four-channel blocks — names every channel, and sets an IP per receiver.
The browser build has no table detector, so it buckets positioned text into the columns of Ofcom's ST16 template and merges the several physical lines that make up one row. That's been validated against a real licence — all 116 assignments, sites, periods and fees — but the geometry is calibrated to that template, and a materially different Ofcom revision would need recalibrating.
The format is undocumented. The generator clones structurally-verified XML fragments from a real WWB7 file and substitutes frequencies and names — automated tests can prove the file is internally consistent, but only WWB can prove WWB accepts it.
The one verified receiver template is a Shure AD4Q-A in band G56. Rather than silently mislabel other hardware, the generator refuses to build a show file for any other band. The .txt and .csv exports work for every band.
The sample file this was built from never had a device with a real IP configured, so the packed-integer address and the static-mode flag are both inferences. If a receiver's IP doesn't take after import, set it again inside WWB.
02 — Blend Calc
Define the projection canvas, set the array, pick a projector and a lens, and get the system resolution, the pixel budget for the doubled regions, the lens requirement per position, a PDF report and a Resolume Arena advanced-output file.
Everything is computed in the page and kept in local storage — no backend, no account, no telemetry. The projector and lens library is yours to edit, with JSON import and export, so it can hold the stock you actually tour with rather than a list somebody else curated.
01
On a curve you give the arc width measured along the surface, the way a screen is actually built, and the radius; the wrap angle and chord fall out of that. The optics are not the flat maths with a fudge factor — you need a wider lens than flat suggests, and the image is shorter at the tile edges than at the centre.
02
Pin one blend and the solver derives the other so the array lands exactly: fit width sets the horizontal and derives the vertical, fit height does the reverse. Manual mode reports the spill or the shortfall rather than quietly correcting it.
03
Blend bands are covered by two projectors, and where a horizontal and a vertical blend cross, by four. All three are reported separately, in canvas pixels and as a share of the canvas, with the redundant pixels — the ones you pay for twice and see once — totalled.
04
Required throw ratio per column, the lens that covers it, where it sits in its zoom range, and the horizontal shift needed. Two placement models: one projector per tile on its own axis, or the whole array stacked at a common point, where off-axis tiles need shift and a curve changes the throw column by column.
It is flagged unverified throughout, badged in the UI and carried as a warning box on the PDF. Confirm lens coverage and brightness against the manufacturer datasheet, and the room against a site survey, before anything is ordered or quoted. The generic lens classes — "standard zoom, 1.3–1.8:1" — are honest by construction, because they describe a category rather than a product.
It assumes square pixels, no keystone, no lens distortion, a perfectly built screen and zero optical losses. The luminance estimate is a ceiling in particular: it ignores lamp ageing, port glass and blend-region compensation.
One Screen per projector, each with a slice covering that projector's share of the composition including its overlap. Blend parameters are deliberately absent — no reference file had blending enabled, and a guessed parameter name is worse than a missing one — so set the blend widths on each slice edge in Arena. The XML vocabulary was read off real files from an Arena 7.27.0 install, but it has never been round-tripped through a running Arena.
03 — Pixel Peeker
Lay out cabinets on a canvas, add processors, wire the ports, and see the load on each one, its headroom, and the highest frame rate it could actually sustain at that load — before anyone is standing in front of it on site.
This is the lite build: the design tool, the PDF report and the Resolume export — the parts with no caveats attached. The full build adds the NovaStar cabinet schedule, the LCT/VMP configuration brief and the JSON interchange file, and will replace this one here once it is ready.
01
Pick a cabinet from the library or define a custom panel by resolution and receiving card. Fill a canvas, build blocks, or place tiles by hand. Every record in the library was parsed out of the manufacturer datasheet it names as its source.
02
NovaStar and Brompton controllers with their real port counts, input connectors and device capacity limits. Auto-wire in serpentine or column order to a chosen fill limit, or patch ports by hand.
03
Overlapping cabinets, unpatched tiles, over-capacity ports, a device that runs out before its ports do, an input too small to carry the wall, panels that cannot reach the refresh rate you asked for, and chains that jump around the wall.
04
The point of it
Controllers pack each colour into a power-of-two container, so 10-bit costs 32 bits per pixel and not 30. With those containers a single 0.9500 link efficiency reproduces NovaStar's three published MX40 Pro per-port figures exactly. The usual spreadsheet formula overstates capacity by about 7% — in the direction that gets you into trouble.
The capacity model is pinned in tests against published manufacturer figures, and it reproduces them to the pixel. That is not the same as site-proven: no processor, receiving card or panel has ever been connected to this, and nothing it has laid out has been rigged.
Records carry a verified flag and a source, and unverified ones are badged in the UI and called out in the PDF. Receiving-card pixel limits specifically are conservative placeholders rather than verified figures.
Element names, nesting and number formatting were read off real files written by Arena 7.27.0, not guessed from documentation. What has not happened is this particular arrangement — one screen per processor, one slice per output port — being loaded into a running Arena, and Resolume change the format between releases.
04 — ATEM Fleet Admin
Build every ATEM's configuration through forms that already know what that model can do, then download one folder per switcher containing a config.xml that ATEM Software Control will load. The alternative is the same settings typed into the same dialogs twelve times, on a flight case, the night before.
This is the browser build of a desktop app, and it does the part that matters — the XML is generated here in the page by the same code the download runs. What it cannot do is reach a switcher: a web page has no way to open a socket to one, so the desktop app is what you want if you would rather apply the config live over the network than load a file at each unit.
.zip
One directory per device, named after it, holding that switcher's config.xml — the same tree the desktop app writes to a folder you pick, delivered as a download instead. Unzip it onto a stick and walk the room.
.xml
Matched to real autosaves
A <Profile> in ATEM Software Control's own format — element names, nesting and ordering matched against real autosave files. Load it with Software Control's own Load button; nothing here talks to the switcher.
.json
The whole fleet as one project file you can save, reopen and hand to someone else. It is written and read entirely in the page — Save downloads it, Open reads it back — so the fleet never leaves your machine.
.txt
Each device folder that has media-pool items carries a MEDIA.txt naming what belongs in which slot, and where you said the source file was. The browser cannot read a file from a path you typed, so it lists them rather than pretending to gather them.
Connect & apply opens a TCP connection to the switcher. A web page cannot do that at any privilege level, so the button is absent here rather than present and failing. Everything else — the forms, the model catalog, the generated XML — is identical to the download.
The export carries the XML and the manifest, not your stills and clips. Load the media pool from ATEM Software Control as you normally would; the pool slots and names are already in the config either way.
The XML generator was matched against real ATEM autosave files, but no ATEM Mini save existed as ground truth — so the Mini <Streaming> and <Recording> sections are reconstructed from the protocol rather than copied from a known-good file. For those specific settings the desktop app's live apply is the authoritative path.
There is no backend and no upload endpoint. The XML is generated and the zip is assembled in your own tab, which matters here because a fleet file is a list of your switchers, their names and their addresses.
05 — PDF Presenter Lite
Open a PDF and get the two windows a presentation needs: Now and Next with a clickable thumbnail strip in front of you, and a clean fullscreen slide with no chrome on the projector. It is the whole app, running in a browser tab, on a machine you were handed ten minutes ago.
This is the browser build of a desktop app. The rendering was always done by pdf.js in a page, so the presenter view, the output window, blanking and the laser pointer are the real thing here rather than a demo of it. What needs a desktop is the remote control: OSC and the Companion module need a UDP socket, and the watched folder needs to read a directory — so if you drive the show from a Stream Deck, use the download.
01
Now and Next side by side, and a strip of every slide underneath — click any of them to jump straight there. Arrow keys, Page Up/Page Down and Space all advance, so a presentation clicker works without configuring anything, because a clicker is just a keyboard.
02
A second window showing only the current slide, which you drag to the projector and make fullscreen. Keys pressed while that window has focus still drive the show — so a stray click on the output, or a clicker aimed at it, does not strand you.
03
Press B or W to cut the output to solid black or white without losing your place, the way PowerPoint's presenter shortcuts do. Move the mouse over the Now preview with the pointer enabled and a glowing dot tracks it on the output.
04
Links authored into the deck — a contents page, "back to agenda" — are clickable on the Now slide and jump to the right page. Top-level bookmarks become named sections. There is also a timed auto-advance that stops at the last slide rather than looping.
The output opens as a pop-up window, so a blocker will stop it the first time. On Chromium it then puts itself on your second display — that needs the window-management permission, and refusing it just means you move the window yourself. What it cannot do either way is open fullscreen: only a gesture inside a window can make that window fullscreen, so it opens as a normal window with a prompt, and one click finishes the job.
The desktop app is field proven on real shows. This one is newer: it has been verified against a real multi-page PDF on a dual-display setup — the deck renders, both windows stay in sync, keys from the output drive the control window, and the output window opens on the second display on its own. That is a bench, not a venue. Run your own deck through it once before it matters.
Those need a UDP socket and a readable directory, so they are absent here rather than shown and broken. The desktop app has all three, and its Companion module is a separate download.
There is no backend and no upload. The file is read by the page from your own disk and stays there, which is rather the point when the PDF is an unannounced product or somebody's results a week before publication.
Why they work this way
None of these upload anything. The parsing, the maths and the exports all run in the page, which is not a detail: a PMSE schedule names a licensee and their address alongside their allocation, and a wall layout or a projector plot is somebody's unannounced show. None of it is a document to hand to a stranger's server for convenience.
