Discipline
Getting presenter files in, converted, on screen, and out again afterwards.
Every event has the same content problem in the same order. Files arrive late, in the wrong format, from people who are not going to learn your system and shouldn't have to. Something has to convert them without losing the speaker notes. Something has to put them on the screen and give the presenter a view of what is coming next. And when it is over, several terabytes of recordings have to become a project an editor can open.
That chain is the least-tooled part of a show and the one most likely to be held together by a runner with a memory stick. These are the pieces written to replace the memory stick.
11 projects · 8 with builds to download
The part that happens before you are involved, done by people you cannot train.
A Nextcloud app for production teams: build a show from a CSV, the browser or a live Google Sheet, and it creates a folder and upload-only drop link per session, emails each presenter, and can create per-theatre accounts scoped to their own folder.
Converts Keynote, PowerPoint, Google Slides and ODP to PDF with a presenter-notes sidecar, so notes survive the conversion. GUI, CLI, server and a Nextcloud app from one codebase.
What the presenter sees, and what drives what the room sees.
A minimal PDF-only presenter: Now/Next view with clickable slide thumbnails and a fullscreen output on the second display, driven by keys, a clicker or OSC. No notes panel, no media, no deck editing.
The presentation-laptop half: a bespoke PDF/Keynote/Google Slides engine with dual NDI outputs — Program and Next Slide — driven remotely from the Server.
Master control for a presentation room: a real-time NDI video matrix router, layered scene compositor, presenter-notes hub, and a Control Surface with a JSON-RPC automation API.
Playing the result out, alongside everything else the room needs.
A live-events media server built on CasparCG — screens on a canvas, frame-accurate cues, a media library, GDD template forms and a trigger grid, all in a browser. Verified against a real CasparCG 2.5.0.
Turning what was recorded into something somebody can edit on Monday.
Scaffolds an entire DaVinci Resolve project — theatre and day bins, per-session timelines, imported media and smart-bin recipes — from the same session CSV that drives the file-drop workflow.
Everything else in the category.
Drop in a .pptx and find out which fonts it actually uses, which of those are installed on the machine looking at it, and what to do about the rest. The hard part is that a plain search of the file is wrong: every Office theme carries a script-fallback table naming around thirty CJK and Indic fonts whether or not the deck contains a single such character, so three real presentations report 39, 36 and 9 typefaces where the true answers are 2, 4 and 6. Decks also name faces rather than families — "Helvetica Neue Medium", "Poppins Regular", "Times Roman" — which a naive check calls missing when the font is sitting right there. It resolves both before it says anything. Missing fonts are matched across two catalogues — 1,942 Google Fonts families plus 119 more from Fontsource. The ones that can never be shared — Calibri, Cambria, Arial, Times New Roman — get metric-compatible stand-ins instead, same advance widths, so line breaks hold. Adobe Fonts are named as Adobe Fonts and linked to activate rather than pretended to be fetchable. Anything left goes into a sidecar .zip with per-platform installers. A desktop build installs them outright.
PowerPoint Font Manager as an Office add-in: a task pane inside PowerPoint that reads the open presentation directly, works out which fonts it actually uses, checks which of those are installed on the machine looking at it, and offers the missing ones as real downloads, metric-compatible substitutes, or a sidecar .zip. It is the same scanner as the web tool — vendored from that repository and imported unchanged — run on the deck you have open instead of a file you drop in, so nothing is uploaded and there is no drag-and-drop. One manifest covers PowerPoint 2016+ on Windows, 2019+ on Mac, PowerPoint on the web and Microsoft 365; installing it means handing PowerPoint one small XML file that points at the hosted build.
Browse, preview and bulk-download open-source fonts — every Google Fonts family, plus the ones Fontsource carries that Google does not — or hand it a CSV, XML or text list of family names. The files are the complete original TTFs from the google/fonts repository, never the subsetted web versions, and a whole-catalogue pull (about 2.2 GB) streams to disk as one zip with per-platform installers and every family's licence text. Names it cannot find get open stand-ins: Carlito for Calibri, Arimo for Arial, Tinos for Times New Roman, with the same widths. The desktop app installs fonts straight into your user font folder, starts at login in the tray, watches a folder for lists, and takes fonts and lists from an SMB, NFS or WebDAV share — so one folder on a NAS provisions every machine that runs it.
A tray tool that keeps a Resolume show on DXV. Point it at a folder and anything dropped there is probed and, if it is not already DXV, sent to Resolume Alley to be converted. Point it at a running Arena or Avenue and it finds the clips that are still h264, converts them, and swaps the converted file into the composition in place — keeping in and out points and clip effects, and skipping any clip that is currently playing until it stops. The conversion is done by Alley itself, because there is no DXV encoder in ffmpeg and Alley is the only way to produce one.
These were written in the order the problem arrives, and they hand off to each other on purpose. A speaker drops a deck into a folder; it is converted to PDF with the notes preserved as data rather than as pictures of text; the presenter view reads those notes; the master server routes the output; and the session's own record of what happened becomes the edit project. Each link can be used on its own — most people arrive needing exactly one of them — but the reason they look like they were designed together is that they were.
The formats are where it fights back. Every exporter drops hidden slides, so a slide count and a page count are not the same number and anything that assumes they are will silently mis-title half a deck. That kind of detail is what these tools are actually for.
Content tooling has a habit of assuming a cloud account, a login and a working uplink, none of which are safe assumptions in a basement ballroom an hour before doors. The conversion runs locally, the presenter apps talk to each other over the local network, and the file-drop side sits on your own Nextcloud rather than somebody's platform.
The Companion modules that put these on a Stream Deck are listed separately — they are the control surface for this chain rather than part of it.
The whole catalogue
The full index carries every project at once, searchable and filterable by discipline, type and how finished it is — including the disciplines that don't yet have a page of their own.
