Bugtracker DMXControl 3

  • Status Zugeteilt
  • Percent Complete
    0%
  • Task Type Wunsch / Idee
  • Category GUI & Server → Server
  • Assigned To
    Arne Lüdtke
  • Operating System All
  • Severity Low
  • Priority Very Low
  • Reported Version 3.2
  • Due in Version 3.3
  • Due Date Undecided
  • Votes
  • Private
Attached to Project: DMXControl 3
Opened by Stefan Kistner - 09.01.2020
Last edited by Patrick Grote - 02.04.2020

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.

Project Manager
Arne Lüdtke 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
Arne Lüdtke 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 G. 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.

Stefan Kistner 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 G. 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
Arne Lüdtke 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.

Stefan Kistner commented on 18.03.2020 22:28

Arne hat eine kleine Vorschau erstellt.

Stefan Kistner 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
Arne Lüdtke commented on 02.04.2020 20:05

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

Loading...

Available keyboard shortcuts

Tasklist

Task Details

Task Editing