- Status geschlossen
- Prozent erledigt
- Aufgabentyp Wunsch / Idee
- Kategorie GUI & Server → Server
-
zuständig
Soon5 - Betriebssystem All
- Schweregrad niedrig
- betrifft Version 3.2
- fällig in Version 3.3.0
-
fällig am
unbestimmt
- Stimmen
- versteckt
angelegt von LightningBrothers - 09.01.2020
zuletzt bearbeitet von Soon5 - 11.01.2023
FS#4015 - Zeitpunkt für Aktivierung der DMX-Ausgabe selbst festlegen
Für einen Test baute ich kürzlich zusätzlich zum Main-PC noch einen zweiten Backup-PC auf, wovon nur einer der beiden PCs die DMX-Daten über Art-Net ausgeben sollte. Gerade bei Art-Net gibt es ja bekanntermaßen murks, wenn zwei PCs das gleiche Gerät ansprechen wollen.
Wenn alles geregelt läuft, kann ich vor einem Neustart zum Beispiel die Art-Net-Ausgabe deaktivieren. Liegt aber nun ein Fehler vor, wodurch ich das Deaktivieren nicht mehr entsprechend anstoßen kann, sind die DMX-Interfaces wie zuletzt gespeichert beim erneuten Starten des Kernels nur kurze Zeit wieder aktiviert und die Ausgabe wird auf 0 gesetzt - egal ob ein Projekt geladen wurde oder nicht. Dies war im konkreten Fall insofern problematisch, weil das Projekt beim Starten von DMXControl 3 als “Default Project” direkt mit geladen wird und ich während des Ladevorgangs keinen Zugriff auf die DMX-Ausgabe habe. Damit mir nun mein Main-PC nicht in die Suppe spuckt und nichts ausgegeben wird, blieb mir nichts anderes übrig, als im Interface-Rack die Art-Net-Interfaces händisch temporär direkt auf den Backup-PC umzuklemmen.
Um nun im Falle eines unvorhergesehen Neustarts (insbesondere mit einem Default Project, was effektiv gesehen das “Arbeitsprojekt” / “Showprojekt” ist) nicht Hand an der Verdrahtung der Hardware anlegen zu müssen, würde ich mir hier eine Möglichkeit wünschen, dass ich im Idealfall selbst den Zeitpunkt festlegen kann, wann die DMX-Ausgabe auf die Interfaces bzw. die Interfaces selbst aktiviert werden - und zwar unabhängig davon, was in den Einstellungen für die DMX-Ausgabe grundsätzlich gespeichert ist.
Ich denke über ein paar "Main" Switches nach, die als Hauptschalter zentral Erreichbar sind. Einen Main Switch für DMX Ausgabe, einen für Input Assignment, einen für ….
Die Idee ist, dass dann diese Main Switches über eine Einstellung gesteuert werden, welche den Startzustand festlegt:
Ich sehe aktuell folgende Mains:
Wäre schön, den Zustand auch mit laufendem DMXControl über ne Schnittstelle (z.B. MQTT) oder notfalls per Aufruf einer *.exe per Kommandozeilenoption ändern zu können. Dann wird's echt interessant und eine Integration in andere Systeme möglich.
In der 3.2.1 ist es durch verschiedene Nodes möglich, die Interfaces und einzelne Ports über das Input Assignment ein- und auszuschalten, sprich also über das Softdesk, Tastatur, MIDI, DMX-In etc.. Dem entsprechend bedarf es in dem Fall nur ein Plugin für MQTT, welches die ankommenden Befehle und Informationen im Input Assignment als Inputs anbietet und über Outputs verschiedene Rückmeldungen ins MQTT zurückspielt.
Ah, danke für die Info, dann hab ich den Bugreport teils falsch verstanden.
Dann sollte man nur nicht mit nem DMX-In das gleiche Interface schalten, sonst hat man ein Henne-Ei Problem.
Yepp, MQTT wär klasse, ne Kommandozeilenoption oder ne andere Low-Level API (REST, …) ginge vorerst auch.
Hm. Da wir mit 3.3 eh auf gRPC umstellen und dann die API auch per gRPC für quasi beliebige Programmiersprachen zur Verfügung steht wäre die Frage in wieweit MQTT als (zusätzliche) Schnittstelle dann noch notwendig ist.
Mit 3.3 existiert dann alles als Gui unabhängige offene Schnittstelle. Das gibt der Automatisierung quasi unendlich Möglichkeiten.
Arne hat eine kleine Vorschau erstellt.
Entsprechend der Beta-Tester-Runde vom 30.03.2020 wurde festgehalten, dass der überwiegende Teil das Feature als sinnvoll erachtet und einige davon dieses auch häufiger einsetzen würden.
Ist jetzt kein kritisches Feature. Um Migrationsaufwand zu sparen plane ich das mal auf die 3.3.
Wo wird denn der Zustand gespeichert? Eigentlich geht das nur als Applikationseinstellung.
Würde auch so sehen.
In 3.3 Testen
Ich finde das Feature gut, allerdings finde ich es etwas fehleranfällig, weshalb ich mir eine zusätzliche Visualisierung in der GUI wünschen würde. Ich stelle mir hier den Fall eines unbedarften Users vor, für den nicht ersichtlich ist, warum DMXC keine DMX-Werte ausgibt, da wäre DMXC für mich schnell gestorben, wenn mir dadurch eine Show vermasselt wird…
Ich könnte mir folgende Alternativen vorstellen:
- hinterlegen des Buttons "Hauptschalter" bei deaktivierung eines Elements in einer kräftigen Farbe (evtl. rot blinkend)
- visualisierung der deaktivierten Elemente in der Statusleiste in einer kräftigen Farbe (evtl. rot blinkend hinterlegt)
Die Einstellungen für die Startwerte würde ich ggf. auch mit:
- Startwert DMX-Interfaces
- Startwert … beschriften, damit klar ist, was die Einstellung bewirkt.
Bei der ersten Vorstellung des Features, hatten wir den gleichen Gedanken. Deshalb haben wir in einem QRM beschlossen, dass default beim Programm Start die Switches aktiviert werden. Sollte ein Nutzer Probleme haben, weil er ausversehen die DMX Ausgabe oder ähnliches deaktiviert hat, dann ist nach einem Nuestart vom Kernel wieder alles i.O.
Ne, das stimmt so nicht. Die Schalter nehmen die Einstellung ein, was eben in den Einstellungen eingestellt ist, und da gibt es die Optionen "An", "Aus", "Letzter Wert". Im QRM 20.1 Protokoll steht davon auch nix, dass nach einem Neustart die Funktionen alle wieder auf An gehen. Was korrekt ist, der Default Wert ist An, ergo wenn jemand die Systemeinstellungen zurücksetzt, dann gehen alle wieder auf an.
Bzgl. dem Roten Blinken, weiß ich nicht, ob ich das toll finde. Wenn, dann Ausschaltbar. Warnungen OK, aber irgendwie nicht so penetrant.
Worüber wir aber schonmal nachgedacht haben ist so ein allgemeines "Warndreieck" in der Statusleiste, wo man alle Dinge die irgendwie die DMX Ausgabe behindern visualisieren kann (Die üblichen Verdächtigen, Grandmaster = 0, usw.). Eventuell kann man das kombinieren.
QRM22.2