michael/ProdDash
1
0
Fork 0
Code Issues Pull Requests 3 Actions Packages Projects Releases 1 Wiki Activity
Files
a692b6a9e284a2e51f8699a245f9d6ee2ee00324
ProdDash/CLAUDE.md
T
christianandClaude Opus 5.5 2893316a1a Vista Cues 1.0.0: which Vista 3 cue lists are live, from the network MIDI that fires them 
Vista 3 reports nothing about what it is playing — its OSC only takes
commands — so a booth with no lighting operator can't see the lighting
computer. ProPresenter, the tracks rig and Companion fire Vista's cue lists
with notes over macOS network MIDI sessions, and a session sends every note
to every participant, so the module joins those sessions as one more
listener (RTP-MIDI in plain Node, no helper) and hears what Vista hears.

The admin's cue sheet turns notes into Go / release / pause / back / flash
on named lists. Sheets with no release notes use [groups]: a Go replaces its
group's live list, and the first group is the headline — the main scene —
which takes over the look and clears the FX below it. The tile shows the
headline list large with how long ago and who fired it, the other live
lists as tags, recent notes, and which senders are connected.

The module invites each configured sender and keeps re-inviting, accepts
invitations from anyone, and advertises itself over Bonjour on macOS. A
busy port (a config save re-initing before the old sockets close) is
retried rather than failing. Default session port is 5040/5041, clear of
the 5009 session on NA Ingest.

tools/vista-midi-mock.js is a stand-in sender for development;
modules/vista-cues/vista.test.js covers the parser, packet decoding and
real loopback sessions.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-10-11 11:15:45 -04:00

5.1 KiB
Raw Blame History

ProdDash

Modular production dashboard web app for Waters Church, developed in this repo. The app lives at the repo root and is built: zero-dependency Node server (server.js, Node 18+), dashboard shell client in public/, admin page at /admin, modules in modules/ (the repo's copies — a packaged install ships none and installs them from the admin page's catalog), and a native macOS menu-bar launcher in launcher/macos/ (Swift, no dependencies — the shipped macOS app: it carries the server and its own Node runtime, supervises them, and owns the macOS permissions modules declare; see its README). Runtime state (module config, named layouts) is written to a per-machine data directory outside the checkout (PRODDASH_DATA_DIR overrides; see README "Where settings are kept") — never add code that writes runtime state into the repo folder. SPEC.md was the authority for the initial build; README.md has run/configure/use instructions.

Building a new module — read docs/MODULE-GUIDE.md first

docs/MODULE-GUIDE.md is the authority on the module contract (manifest, client factory + moduleApi, optional server entry, title-bar controls). The rules that matter most:

  • A module is one self-contained folder in modules/ — never modify the shell (server.js, public/) to add one. Installation = the admin page's Available modules (downloads from the repo into the data directory), or drop the folder and restart; configure in /admin.
  • All settings in the admin page (configSchema / instanceSchema) — never a separate setup page, hand-edited file or env var. Dependencies ship inside the module folder (zero deps is the norm). Everything the module does runs inside its server entry — no helper scripts, companion programs or daemons the operator starts by hand; a listener or decoder is started in init() and stopped in stop(). A native helper ships prebuilt inside the module folder for Apple silicon macOS and 64-bit Windows (bin/<name>-macos-arm64, bin/<name>-win-x64.exe, source and build script under native/); nothing is ever compiled on the machine running ProdDash, and a missing binary means the feature reports itself off, not a broken module. Declare "proddash": ">=x.y.z" and bump the module's version on every change.
  • Browsers never call upstream services directly; the module's server routes proxy everything (no CORS, secrets stay server-side).
  • Keep the interface clean (guide rules 5-11): no help and no label over three words in a tile's gear; server-side settings in configSchema only; a tile setting changes that tile alone; hide-toggles ungrouped when there are four or fewer, in a folded Show group when there are five or more; title-bar controls are icons with tooltips, never labels, and never repeat something the gear already offers.
  • Style with the shell's CSS variables only, scoped under [data-module="<id>"]; survive upstream loss (reconnect + setStatus).
  • Verify against the guide's testing section and resilience checklist. Mocks for the existing upstreams: node tools/prodcom-mock.js (ProdCom) and node band-lineup-display/tmp/pp-mock.js 1599 (ProPresenter). node tools/slack-mock.js 24716 (Slack; run ProdDash with SLACK_API_BASE=http://127.0.0.1:24716/api). node tools/pco-band-mock.js 24710 (Planning Center for Band Lineup; run ProdDash with BAND_LINEUP_API_BASE=http://127.0.0.1:24710). node tools/ableset-mock.js 39071 (AbleSet over OSC/UDP; point the AbleSet module at 127.0.0.1:39071; --stopped, --no-live, --speed 4). node tools/vista-midi-mock.js 5104 (a network MIDI / RTP-MIDI session for Vista Cues; point its first sender at 127.0.0.1:5104 and paste the cue sheet it prints; --invite 127.0.0.1:5040 joins from its side, --name, --channel, --every, --notes 2,23,8).

Reference code (read-only forks — don't develop these here)

  • prodcom-listener/ — live ProdCom transcript web app. Zero-dependency Node server.js that serves public/ and proxies /prodcom/* (including the SSE transcript stream) to the ProdCom API at config.json → prodcomUrl (set per site; each campus runs its own). Good reference for: SSE handling, reconnect logic, channel colors/filtering, PWA install.
  • band-lineup-display/ — backstage Electron app (stage lineup photos with mic/pack labels) plus ProPresenter Now/Next:
    • band-lineup-display/propresenter-core/ — shared ProPresenter 7/20 client, no deps, no Electron. All ProPresenter quirks live here (PP20 runtime route discovery, arrangement-expanded slide totals, uuid-then-name live-item matching). Reuse this rather than re-implementing ProPresenter access.
    • band-lineup-display/propresenter-app/ — standalone Now/Next web display.
    • band-lineup-display/tmp/pp-mock.js — mock ProPresenter API for testing without the real thing: node tmp/pp-mock.js 1599, then point at 127.0.0.1:1599.

Upstream sources: ProdCom Listener lives at github.com/michaelmcgary2008/prodcom-listener; BandLineupDisplay exists only on the production machine. These folders are snapshots, not submodules.

Reference in New Issue View Git Blame Copy Permalink