362e089be0
Der Nutzer hat recht: Der Ordner war voller Entwicklungs-Muell. Jetzt ist sauber getrennt: ROOT (was der Nutzer sieht und braucht): - run.py = das Programm - hms_app/ = der Anwendungscode - HMS MediaEngine.app = macOS Doppelklick-Starter - HMS-Start.vbs = Windows Doppelklick-Starter - HMS-Install.vbs = Windows Erst-Installation - HMS-Mac-Install.command = macOS Homebrew-Installation - HMS-Portable-Install.command = macOS Portable-Installation (16GB-Fix) - installer_gui.py = grafischer Installer - launcher.pyw + launcher_core.py = interne Start-Logik - LIESMICH.txt = 10-Zeilen-Kurzanleitung - .gitignore _entwicklung/ (alles andere, NICHT benoetigt): - packages/ apps/ native/ plugins/ tools/ schemas/ tests/ docs/ build/ fixture_profiles/ - PLAN.md STATUS.md ERRORS.md TEST_REPORT.md CHANGELOG.md README.md - pyproject.toml uv.lock setup_*.sh/ps1 make_mac_app.py Diese Trennung gilt ab sofort fuer alle Commits. Der Nutzer kann _entwicklung/ loeschen wenn er Platz braucht - die App laeuft ohne. Verifiziert: App startet nach Aufraeumen unveraendert (Health 200).
42 lines
1.9 KiB
Markdown
42 lines
1.9 KiB
Markdown
# Architekturüberblick (Phase 0)
|
|
|
|
Verbindliche Referenz: `PLAN.md`. Diese Seite fasst Prozess- und Besitzgrenzen zusammen.
|
|
|
|
## Prozesse (§6.1)
|
|
|
|
| Prozess | Technologie | Aufgabe |
|
|
| --- | --- | --- |
|
|
| Launcher/Supervisor | Python (Phase 1) | Start, Portwahl, portable Pfade, Heartbeat, kontrolliertes Beenden |
|
|
| Control Core | Python, asyncio, FastAPI, Pydantic, SQLite/WAL (ab Phase 1) | autoritativer Zustand, REST/WS, Art-Net, Persistenz |
|
|
| Render Worker | Python-Orchestrator + GStreamer + nativer Renderkern (ADR-0004 offen) | Decode, GPU-Compositing, Ausgabe, Telemetrie |
|
|
| Web-Frontend | TypeScript, Vite (Phase 5, ADR-0006 offen) | Bedienoberfläche; niemals Videoausgang (§3.2) |
|
|
|
|
## Besitzgrenzen (§8)
|
|
|
|
- Jedes Paket hat eindeutige `hms_*`-Namen; kein Quereinbau zwischen `packages/*`.
|
|
- Control Core und Renderer verbinden ausschließlich über das versionierte IPC (ADR-0003).
|
|
- Der Renderer erhält pro Frame einen unveränderlichen Parametersnapshot (§11.4).
|
|
|
|
## Kernregeln (§33, Auszug)
|
|
|
|
- Python steuert, decodiert nicht und rendert keine Pixel.
|
|
- Windows: D3D11Memory durchgängig; kein CPU-Rundweg im Normalpfad.
|
|
- Plugins: versioniertes Manifest, kein Datei-/DB-Zugriff, Quarantäne bei Fehler.
|
|
- Alle Steuerquellen (Browser, Art-Net, später Timeline/Audio/KI) laufen über die zentrale Parameter-Engine.
|
|
|
|
## Steuerfluss Phase 0
|
|
|
|
```text
|
|
Lichtpult/Emulator → ArtDMX (UDP 6454) → hms_artnet.receiver
|
|
→ Control Core (hms_parameter.engine: Priorität CONSOLE)
|
|
→ IPC-Snapshot → Renderer (GStreamer-D3D11) → Opacity/Parameter an Frame-Grenze
|
|
|
|
Browser → REST/WebSocket → derselbe Command-/Parameter-Pfad (Priorität WEB)
|
|
```
|
|
|
|
Beide Quellen adressieren denselben Parametersatz; es gibt genau eine autoritative Instanz (Control Core).
|
|
|
|
## Phase-0-Spike
|
|
|
|
`hms_renderer` definiert die Pipelines als Launch-Strings; Ausführung und Messung erfolgen auf Referenz-Windows-Hardware (Gate 0). Messprotokoll: `TEST_REPORT.md`.
|