Echo: the artist speaks, the room answers — you approve.
A plan to import a grandMA3 show, refine it conversationally with the artist — in rehearsal, live, with you as gatekeeper — and push approved changes back to the desk. Nothing here replaces your programming. It speaks your looks, into your sandbox, on your approval.
The artist directs the show in plain language.
Your taste is the vocabulary.
lumen knows exactly where you are in the show. The artist speaks a note — “the drop should hit colder” — and lumen pins it to that moment, resolves it to your look, previews it on the phone, and waits for you to say go. The desk is never touched until you approve.
How a note travels — on the artist’s phone
Picture rehearsal. The artist is in the house, you’re at the desk. lumen is following the timecode, so it always knows the song and the position. The artist just… talks.
What just happened
- It knew where you were. Locked to timecode — song, section, frame, tempo. No scrubbing, no “which cue was that.”
- The artist spoke, didn’t program. A dictated note, captured against that exact moment.
- lumen resolved to your vocabulary. The note became one of your authored looks — never invented DMX.
- Preview before reality. The change renders on-device first; the rig only moves when asked.
- You stay the gatekeeper. It arrives as a proposal for your approval — nothing lands on the master show without you.
The one-line verdict
Realistic — conditional on one test:
does grandMA3 v2.x round-trip Groups, Presets, Sequences and Timecode
through its native XML export/import? If yes (likely for most), this is a tractable build.
If the data only lives in the opaque .show.gz binary, native export becomes a research project.
Why this respects the desk
The non-negotiable design rule: lumen never invents raw DMX, and never silently touches live programming. The artist talks in plain language; lumen resolves that language only to looks you authored. Everything it can write is confined to an agreed sandbox, and in the room you approve every change before it lands.
Your taste is the moat
“Blood-red and tight” resolves to a look you defined — palette, beam, edge, motion, energy. lumen matches intent to your vocabulary, then confirms. It never guesses a fixture value on its own.
The sandbox is hard-walled
Writes are physically confined to a reserved range (sequences 90–99, high groups, exec page 9). A loose Store or Delete outside it is refused by the adapter, not by good behaviour.
Three modes — and the safety line between them
The same show model is used three ways. They are deliberately separate so the live-stage one can’t be fat-fingered.
| Author | Rehearsal | Perform | |
|---|---|---|---|
| Purpose | build / edit offline | refine on a live rig, together | broadcast the finished show |
| Touches a live rig? | never | read + sandboxed write | output / input only |
| Realtime surface? | n/a | yes — the point | none (forbidden) |
| Output | a saved version | a proposed version (you accept) | live light |
Rehearsal mode — the room workflow
This is the part you asked for: the artist dictates changes in real time, and lumen reads the actual code coming back off the MA3 so the conversation is grounded in what the desk really did — not what we hoped.
- You pause at a position in the run.
- lumen reads the real desk state at that moment over telnet (the console’s own reply lines).
- Artist gives voice/text feedback — “colder, tighter.”
- lumen previews on-device from real state + the proposed change (faithful, not photoreal).
- Artist agrees or tweaks until it reads right.
- lumen pushes the change as a proposal — into the sandbox, captured as a proposed version.
- You approve / accept before it merges into the master show.
Why this is safe: writes are sandboxed, every change is a proposed version (never auto-applied), and you remain the gatekeeper. It is collaborative refinement, not a bypass.
The four inputs, assessed honestly
| Input | Realism | Why |
|---|---|---|
| Audio + sync | High | A file pinned to one show-clock offset. No MA3 dependency. We use frames as the integer currency so cues don’t drift over a long set. |
| Push to console (telnet) | High | Already designed. Store / label / fire over port 30000 into the sandbox. Only the exact v2.x syntax needs live confirmation on your desk. |
| Import MA3 programming | High via XML | grandMA3 ships a native XML Export/Import. We use that — never reverse-engineer the binary bundle. |
| Timecode | Medium | Clean conceptual match to our show-clock, but timecode-track editing is telnet’s known weak spot. May need the on-console Lua plugin. |
| Native MA3 export | Medium | Done as XML re-import of the changed objects — not a monolithic file rewrite. The binary rewrite path is avoided. |
The honest caveat: the moment we’d need to parse and
rewrite the raw .show.gz bundle byte-for-byte, realism collapses — it’s undocumented and changes
across point releases. The entire plan is built to lean on MA’s own XML serializer instead.
The MA3 interface — telnet first, Lua for the rest
| Interface | Job |
|---|---|
| Telnet (port 30000) | Primary channel. Send command-line strings, read the replies back — that read-back closes the feedback blind spot and powers Rehearsal mode. |
| Lua plugin (on-console) | The surgeon for what telnet can’t reach: timecode-track editing, data-pool ops. Lives on your desk. |
| XML Export/Import | The import and native-export path. MA’s own format, so it survives version changes. |
| MA-Net / DMX-out | Output only. Can’t program through it; rejected for the cross-site mirror. |
De-risking plan — in dependency order
- Spike 0 — XML coverage truth table. On your sample shows in onPC: export Groups, Presets, Sequences/Cues, Timecode to XML, re-import to a blank show, record what round-trips and what’s lost. This single test decides High vs. Low for the whole feature.
- Spike 1 — read one real show into lumen. Map an exported sequence + its presets/groups to our model, read-only.
- Spike 2 — audio + timecode alignment. Load the audio, scrub, confirm a known cue lands on the musical moment across the full set.
- Spike 3 — export one edited look back to onPC. Change one colour, write XML, MA3 Import, eyeball it. Smallest possible native round-trip.
- Spike 4 — telnet push + read-back on your desk. Confirm the real v2.x syntax and the state read-back live. This is where we’d want your console.
Spikes 0–2 need only MA3 onPC + your sample files. 3–4 want your actual console (or a faithful onPC) to confirm Import and telnet behaviour.
What we need from you
- Your exact grandMA3 software version string — the single highest-leverage fact to de-risk the adapter.
- A sample show export to run Spike 0 against (you confirmed these exist).
- The look vocabulary — your authored looks are the product’s quality. We encode your taste, not ours.
- Eventually, time on the real desk for Spikes 3–4.
Next move: run Spike 0. One afternoon in onPC with a sample show tells us whether native export is conventional engineering or a research project — before anyone commits a timeline.
lumen — author a live show as intent, re-perform it anywhere, locked to one clock. Confidential technical proposal. This page is gated for casual privacy only, not secured.