HMS MediaEngine Agent
02765e6b34
1) Cue-/Szenenliste JE Layer (35/35 E2E): - Cue sichern = Snapshot (Quelle, Alpha, Position, Groesse, Z-Order, FX1/FX2 + Intensitaeten); Name + fade_ms + follow_ms pro Cue - GO vor/zurueck (steps), Goto (Index), Wrap-around am Listenende - FADE: Quellwechsel = dip-to-black (Phase1 runter, Wechsel bei 0, Phase2 hoch; E2E: alpha 0.49 -> 0.32 -> Ziel 0.8), sonst sanfter Tween von Alpha + FX-Intensitaeten; laufende Fades abbrechbar - AUTO-FOLLOW: follow_ms schaltet nach Ablauf automatisch weiter (E2E: Cue mit 600ms -> Wrap zum naechsten) - DMX CUE-GO: cue_go_channel (Settings + UI), steigende Flanke >=128 = GO auf allen Layern; ohne Flanke kein GO (E2E: 0->1, 1==1 bei High-Halten, neue Flanke 1->0); Sequenzfilter aktiv - Cue-Entfernen mit Indexkorrektur; Cues in Projekten speicher-/ladbar (3 Cues nach Projekt-Load erhalten) - UI: Cue-Bereich je Layer (Cue sichern / GO / Zurueck / Goto / Loeschen, aktiver Cue markiert, Fade+Follow-Anzeige) - Fehlerfaelle: unbekannter Layer 400, fehlendes Medium 400, unbekannter Generator 400 2) macOS (Apple Silicon + Intel) mit Skript: - setup_macos.sh: Homebrew installiert python@3.12, python-tk, GStreamer + alle Plugin-Sets + PyGObject; Apple-Silicon-PATH- Hinweis (/opt/homebrew); Erklaerung warum Homebrew statt gstreamer-.pkg (keine PyGObject-Bindings in .pkg) - Bootstrap (--bootstrap): darwin-Zweig mit brew-Installationspfad - run.py --generate-setup erzeugt jetzt 3 Skripte (Windows .ps1 / Linux .sh / macOS .sh); Bash-Syntax geprueft 3) Gefundene + behobene FEHLER: - WEB-UI-ABSTURZ (echter JS-Ternary-Klammerfehler in loadServers, seit Verteilungs-Commit unentdeckt, weil API-Tests den Browser- Code nie parsen): Klammerstruktur korrigiert + JS-Syntax nun per node --check verifizierbar (Syntax OK) + Remote-Buttons robust per data-Attribute (kein Quote-Escaping mehr) - update_layer blockierte Quellwechsel Video->Generator (Cues brauchen beides): Name entscheidet jetzt den Typ, Wechsel in beide Richtungen - Cue-E2E-Timing: dip-to-black hat 2 Phasen (Pruefung 0.2s/0.6s), Auto-Follow-Index-Fix, Art-Net-Sequenznummern im Test inkrementierend (Sequenzfilter verwirft Duplikate korrekt) E2E-Bilanz: Cue 35/35 + Regressionen Projekte 25/25, Verteilung 33/33, App 14/14, FX 16/16 = 123 Checks gruen
HMS MediaEngine
Arbeitstitel – der Produktname kann später ohne technische Auswirkung geändert werden.
Modularer Medienserver, VJ-System und generativer Licht-/Pixeleffekt-Server.
- Primärplattform: Windows 11 x64, portabel ohne Installation
- Weitere Zielplattformen: Linux x64, Raspberry Pi 5 / Linux ARM64
- Steuerung: lokale Webanwendung (Browser), Art-Net/DMX, spätere Timeline/Audio/KI
Leitsatz
Python steuert. Native Bibliotheken decodieren. Die GPU rendert. Der Browser bedient.
Projektstatus
Das Projekt befindet sich in Phase 0 – technischer Spike und Go/No-Go.
Aktueller Stand, Gates und nächste Aufgaben: STATUS.md
Fehlerverfolgung: ERRORS.md
Messergebnisse: TEST_REPORT.md
Bauplan (normativ): PLAN.md
Repository-Struktur (Eigentumsgrenzen)
/
├─ apps/ launcher, control_server, renderer, web
├─ native/ render_bridge (Rust oder C++, Entscheidung per ADR)
├─ packages/ domain, protocol, parameter_engine, render_backend,
│ capabilities, adaptive_quality, plugin_sdk, artnet,
│ cluster, content_sync, timeline, audio_analysis,
│ persistence
├─ plugins/ builtin (generators, filters, transitions, outputs), examples
├─ schemas/ project, plugin, ipc, cluster, api
├─ fixture_profiles/ master32, layer64
├─ tests/ unit, integration, rendering, cluster, visual,
│ performance, portability, e2e
├─ tools/ media_probe, shader_validate, artnet_emulator,
│ capability_probe, cluster_test_node, fixture_generator
├─ build/ windows, linux, raspberry_pi
└─ docs/ architecture, adr, plugin-sdk, api, fixture,
performance, operator
Code darf nicht beliebig zwischen Paketen quer importiert werden.
Entwicklung
# Python-Umgebung
uv sync
# Tests
uv run pytest
# Lint + Typprüfung
uv run ruff check .
Frontend (ab Phase 5): pnpm mit Lockfile, Vite-Build, siehe apps/web.
Phasenmodell
Die Entwicklung folgt strikt dem Phasenmodell aus PLAN.md Abschnitt 31.
Jede Phase endet mit einem Gate; keine neue Phase ohne grünes Gate.
| Phase | Inhalt | Gate |
|---|---|---|
| 0 | Technischer Spike, Machbarkeitsnachweis, ADRs | Gate 0: D3D11-HW-Decode, GPU-Compositing, Adaptive Quality, Art-Net-Latenz, portable Auslieferung reproduzierbar grün |
| 1 | Fundament: Supervisor, Control Core, Renderer, IPC, Node-Identität, Discovery, Paarung | Gate 1 |
| 2 | Medien-, Layer-, Basissync-Engine | Gate 2 |
| 3 | Plugin-SDK, Starterpaket Generatoren + Filter | Gate 3 |
| 4 | Art-Net-Fixtures Master32/Layer64 | Gate 4 |
| 5 | Vollständige Browser-Liveoberfläche | Gate 5 / V1.0-Kernrelease |
| 6+ | Cue/Timeline, Audio, Mapping, Pixel-Ausgabe, KI, Pi 5, Härtung | eigene Gates |
Verbindliche Regeln (Auszug)
- Keine Pixelverarbeitung in Python-Schleifen.
- Kein CPU-Readback im normalen HDMI-Renderpfad (Windows: D3D11Memory durchgängig).
- Kein Mock als fertige Funktion gemeldet; Hardwaretests nur auf echter Hardware.
- Jede Architekturabweichung braucht ein ADR und Freigabe.
- Projektschema versioniert, Migrationen getestet.
Dokumentation
- Architektur:
docs/architecture/ - ADRs:
docs/adr/(Vorlage:docs/adr/_template.md) - Plugin-SDK:
docs/plugin-sdk/(ab Phase 3) - Fixture-Handbücher:
docs/fixture/(ab Phase 4)
Lizenz
TBD – wird mit dem ersten Release entschieden (SBOM und Lizenzverzeichnis sind Teil der Release-Anforderungen, PLAN.md Abschnitt 30).