How CreatorStudio Suite
is put together
Context, components, data flows, MQTT contract, and deployment options — for architects, integrators, and engineering leads.
What sits around the product
Operators author content; the engine decides; vehicles actuate; Suite signs and TTS suppliers are peers on open contracts.
Operators
Author announcements & LED layouts; publish; monitor fleet; export proof.
CreatorStudio Suite
Creator + Engine + Monitor + players — one portal origin.
Vehicle / signs
Thin MQTT clients, speakers, Ultima / Mobitec FF, MatrixRenderer Unit.
Cloud services
Azure PG config / Blob cache · Azure / ElevenLabs / Acapela TTS · MQTT broker.
End-to-end system view
Major building blocks
Creator web/creator/
- Angular 20 + PrimeNG
- Projects, playlists, triggers, lexicon
- LED layouts / vehicle faces
- Publish → Azure PG
Engine src/
- Node / TypeScript ESM
- PtTriggerEngine + pipeline
- TTS cache + matrix/FF
- History / fleet / health
Monitor web/
- Live map & event feed
- Sign previews · proof UI
- MQTT over WebSocket
- Simulator & diagnostics
Portal
scripts/dashboard-server.ts — one origin for Creator, Monitor, player, docs, decks.
Thin clients
clients/go · clients/python · public/player.html — same MQTT contract.
Shared contracts
src/shared/payloads.ts · topic patterns in src/config.ts · FNT / FF encoders.
Inside the engine (one pass)
Decide
- Edge-detect on state change only
- 33 built-in + custom + geofence
- Door / velocity / stop-button gates
- Priority schedule per vehicle
Produce
- Resolve
{vars}→ playlist audio - Matrix: Display → Cycles → Layout
- Cache: LRU → FS → Azure Blob
- Prerender upcoming stops
Composition root: src/index.ts · Detail: ARCHITECTURE.md §4.
MQTT topics are the system API
| Dir | Topic | Role |
|---|---|---|
| IN | {tenant}/{vehicleId}/pis/0/# | Sensors / journey into the engine |
| OUT | …/pis/0/tts | ADT 4.x audio for speakers |
| OUT | …/display · …/exterior | Interior / exterior LED bitmaps |
| OUT | …/display/signs · …/**/ff | Matrix frames + raw Mobitec FF |
| ACK | engine/played | Proof-of-play when clip ends |
| OPS | engine/fleet · health · metrics | Dashboard retained views |
No private Engine↔Dashboard API. Broker: TCP 1883 · WebSocket 9001. Clients may join late on retained topics.
What moves where
Config plane
- Creator publishes
engine_config - pg_notify → Engine
- On-disk JSON fallback (edge)
- Version bump on hot-swap
Media plane
- TTS synth on cache miss
- Phrase key = hash(text+voice)
- Object store = fleet shared tier
- ADT carries audio to clients
Evidence plane
- Dispatched events + GPS/time
engine/playedcloses loop- History store / proof export
- Map + replay in Monitor
Same software, two topologies
Cloud / central
- One Engine process per tenant (typical)
- Fleet MQTT into data centre / VPC
- Thin clients on every vehicle
- Dashboard & Creator for ops staff
- Scale: ~2,000 veh / process (measured)
On-vehicle edge
- Same engine as multi-arch container
- Local MQTT + last-known-good config
- Optional cloud sync when online
- Autonomy / offline corridors
- Non-root hardened image
MatrixRenderer remains the on-sign Unit. Suite software drives content to it; it does not replace the Unit.
How this sits next to Luminator products
MatrixRenderer Unit
On-sign hardware — Presentation Schema consumer (Display → Cycles → Layout).
CreatorStudio modules
Software SKUs L1–L9 — author, speak, prove, optionally publish FF / signs.
Shared language
MQTT · FNT fonts · Mobitec FF mono/RGB · Ultima face roster.
Integrator takeaway
Implement a thin MQTT client once. Consume ADT + display/FF; publish PIS-PT and engine/played. Content and voices stay out of vehicle firmware.
Author → Publish → Decide → Render → Actuate → Prove
Creator writes config; Engine executes against live journey data; MQTT is the only integration surface; thin clients speak, show, and acknowledge. Cloud or edge — same code path.