Bugtracker DMXControl 3

  • Status Closed
  • Percent Complete
    100%
  • Task Type Wunsch / Idee
  • Category GUI & Server → Server
  • Assigned To
    Soon5
  • Operating System All
  • Severity Low
  • Reported Version 3.2
  • Due in Version 3.3.0
  • Due Date Undecided
  • Votes
  • Private
Attached to Project: DMXControl 3
Opened by LightningBrothers - 09.01.2020
Last edited by 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.

Closed by  Soon5
11.01.2023 20:01
Reason for closing:  Implementiert
Project Manager
Soon5 commented on 09.01.2020 21:14

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:

  • On
  • Off
  • Last State (Projekt oder Applikationseinstellung?)
Project Manager
Soon5 commented on 11.01.2020 10:46

Ich sehe aktuell folgende Mains:

  • Input Assignment
  • DMX Interfaces (unterschied zu Freeze: Interfaces werden abgeschaltet wohingegen bei Freeze einfach der DMX Wert angehalten wird)
  • DMX-In ⇒ Out Mapping
Stefan commented on 14.01.2020 20:29

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.

LightningBrothers commented on 15.01.2020 12:54

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.

Stefan commented on 15.01.2020 15:05

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.

Project Manager
Soon5 commented on 15.01.2020 18:18

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.

LightningBrothers commented on 18.03.2020 22:28

Arne hat eine kleine Vorschau erstellt.

LightningBrothers commented on 01.04.2020 16:36

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.

Project Manager
Soon5 commented on 02.04.2020 20:05

Ist jetzt kein kritisches Feature. Um Migrationsaufwand zu sparen plane ich das mal auf die 3.3.

Project Manager
Soon5 commented on 10.05.2020 19:33

Wo wird denn der Zustand gespeichert? Eigentlich geht das nur als Applikationseinstellung.

LightningBrothers commented on 10.05.2020 19:43

Würde auch so sehen.

Project Manager
Soon5 commented on 15.01.2021 22:02

In 3.3 Testen

Mic commented on 10.04.2021 18:50

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.

nutzer99 commented on 11.04.2021 19:02

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.

Project Manager
Soon5 commented on 25.12.2021 21:43

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.

LightningBrothers commented on 07.02.2022 22:20

QRM22.2

  • Diese Funktion ist so für sich genommen fertig gestellt, sodass das Ticket nach entsprechend positiven Rückmeldungen geschlossen wird.
  • Für die Zusatzinformation, dass einer der Funktionen aktiv ist, gibt es das so genannte Warn Feature. Hierzu gibt es das Folgeticket FS#4766.

Loading...

Available keyboard shortcuts

Tasklist

Task Details

Task Editing