Bugtracker DMXControl 3

Der Name ist leicht, Status ist schwerer

Über den Namen oder eben auch die ID des verknüpften Elements könntest du doch nachgelagert ein Cuelist-Node (oder entsprechend andere Nodes) hängen, die dir dann den Status oder andere zusätzliche Informationen rückmelden. Das wäre zwar nicht die volle Flexibilität wie gewünscht, aber vielleicht ein gangbarer Zwischenschritt?

aktuell wird ja nur die Executor ID ausgegeben. Ich weiß nicht ob das ne Cuelist, nen Grandmaster oder sonstewas ist…

Ich muss die Daten ja auch irgenwie in ein Status verheiraten. Entweder in den Bitmap fürs Streamdeck, oder einfach nur ne Lampe auf nem Midi Gerät, ne RGB Farbe whatever. Aktuell haben die einzelnen Buttons nur das Feedback ob diese gedrückt wird. Ob die dahinter ligende Funktion gerade aktiv ist bekomm ich nicht zurück…

Ich hoffe das war verstädnich formuliert…

Alles gut. Dein Problem hatte ich verstanden. Mit dem Namen bzw. die ID bezog ich mich nicht auf die bereits existierenden Ausgänge am Node, sondern schon auf ein bzw. zwei zusätzliche, die dann zum Beispiel Child-ID und Child-Name heißen würden, analog beispielsweise zum Device Group Node - eben nur mit dem Unterschied, dass an einem Executor nur ein Child hängt. Sobald diese Information vorliegt, kommt das zum tragen, was ich oben bereits geschrieben habe.

Moin @MisterX,

Node um Ausgänge für Namen und Typ des verknüpften Elements erweitert.

Das ist ja nur ein Teil der Funktionen die ich mir da gewünscht hatte. Eigentlich geht es ja noch darum den Status des zugewiesenen Objektes zu bekommen. Cuelist läuft oder master ist oben, tc Show läuft…

@nutzer99 Ja, das ist bewusst und diese Umsetzung ist bewusst so gemacht, wie sie gemacht wurde. Denn man kann sich viel wünschen. Aber ob das auch sinnvoll umsetzbar ist, steht auf einem anderen Blatt ;)

Folgende Alternativen sind alle doof:

1. Ein "Status" Ausgang mit genau einer Info: Was ist da "die eine Information"? Wenn wir so einen Ausgang einführen, kommen danach x Tickets ala "aber bitte noch diese Info in den Memberstatus packen" oder "bitte lieber jene Info als Memberstatus setzen". Es gibt aber nicht "den einen Status" bei den Membern. Nehmen wir mal deine Beispiele: "Cuelist läuft": Der eine will die Info "Cuelist läuft", der andere will "Cuelist führt Cue 3 aus". Bei "Master ist oben" kommt sofort die Frage: Welcher Master beim ColorMaster oder PositionMaster? "TC Show läuft": Aktiv/pausiert oder der aktuelle Transportfortschritt? Was ist mit Recording? Wenn man 3 Leute fragt, bekommt man hier 5 Meinungen, welche eine einzige Info in den Memberstatus gehört.
2. Ein "Status" Ausgang mit allen Infos: Dies entspricht nicht dem, wie das Input Assignment größtenteils und wünschenswerterweise aufgebaut ist. Es sind alle Informationen üblicherweise einzeln an separaten Ausgängen (und das ist auch gut so). Wie oben gezeigt, gibt es bei den Membern den einen Status nicht und man muss dann wieder memberabhängig den Output zerlegen. Das ist dann aber das selbe wie bisher über die Member-ID, aber viel bescheidener, weil irgendein string-gebastel nötig ist.
3. Adaptiver Node: Das hat gleich mehrere Probleme. Hier wechselt der Node jedes Mal seine Ports, wenn man den Executor wechselt ⇒ Ständig fallen Verbindungen weg und der Node wird unbenutzbar (vor allem der adaptive Executor Node). Dazu kommt, dass man sämtliche Logik der anderen Member-Nodes in den Executor Node implementieren muss, was unnötige Doppelungen wären.

Auf Basis dieser ganzen Nachteile der anderen Lösungen bleibt nur die Implementierungsform, die Martin in Absprache gewählt hat. Anhand des Typ-Ausgangs weiß man nun, welcher Membertyp darin ist und kann das passend verdrahten. So muss man nicht mehr raten und findet gleich den richtigen Node heraus.