Immer wieder Blackout oder wenig / keine Reaktion

  • Wir haben mal wieder ein Problem.

    Wir nutzen aktuell die Version 3.3.1. Das Problem mit der komischen Startfarbe ist bisher nicht mehr aufgetreten, dennoch immer wieder ein anderes Problem seit dem Upgrade auf 3.3.1

    Immer wieder geht einfach alles aus, wenn wir in den Cues wechseln. Teilweise von Moderation zu S1 M1. Aber auch bei anderen Wechseln


    Alles wird dunkel und wir müssen mit Stop all Cuelists arbeiten, das hilft aber nur 50%. Ab und zu hilft nur komplett neu starten vom DMXControl.

    Die Logs sind leider nicht aufschlussreich, keine Fehlermeldung nichts anderes zu sehen.

    So richtig konnte ich den Fehler nicht reproduzieren und gefühlt tritt der Fehler immer unterschiedlich auf. Mal nach 5 Minuten Laufzeit, mal nach 4 Stunden. Aber auch hier, die Logs geben lediglich die Infos wann das Programm beendet wurde und alles neu geladen wurde, mehr habe ich bisher nicht gefunden auf die schnelle.

    am 17.10-19.10 sind die Fehler immer mal wieder aufgetaucht, evtl findet jemand den Fehler den langsam habe ich keine Idee mehr.

  • Wie sieht das denn in der Kanalübersicht aus oder in der Stage-View aus? Hört sich für mich erstmal so an, als wann das DMX-Signal unterbrochen wird.


    In der Stageview faded alles aus, also wird dunkel, wie wenn man auf stop drückt. So sieht auch die Channeloverview dann aus. Aber keiner drückt stopp, lediglich auf zur nächsten Cue.


    Nur sind in der nächsten Cue eigentlich Werte hinterlegt und manche Geräte bleiben aber an und ändern sich nicht. Mal bleiben die Blinder an, mal die ganze AT3 Gruppe, mal nur ein Fluter.


    Das Fehlerbild/Verhalten ist völlig komisch und bei 4 Personen ist der Fehler komplett unterschiedlich. Eine Fehlbedienung würde ich ausschließen.

    Als Geräte zum Steuern kommt ein Korg Nano Control zum Einsatz sowie ein Stream Deck XL

  • Hatte schon den Gedanken ob es an den Cues liegt und durch die Versionupgrades.

    Von 3.2.3 auf 3.3.0 waren viele Farbwerte, Effekte von den Effektcues sowie manche Dimmerwerte nicht mehr richtig. Bei einer Blau/Pinken Farbgebung war die Hälfte auf weiß

  • Von 3.2.3 auf 3.3.0 waren viele Farbwerte, Effekte von den Effektcues sowie manche Dimmerwerte nicht mehr richtig.

    Kannst du das Projekt aus DMXC 3.2.3 auch noch zur Verfügung stellen? Das hört sich in der Tat etwas komisch an, denn in diesem Bereich gab es keine Änderungen, die sich auf den Inhalt von Cues von Cuelists selbst auswirken.

  • Öhm da haben wir eigentlich nichts geändert in dem Bereich. Ich hatte jetzt leider noch keine Zeit, in dein Projekt zu schauen und das wird auch leider noch etwas dauern, bis ich das wieder machen kann. LightningBrothers  nutzer99 könntet ihr da bitte mal reinschauen und mir dann intern eure Findings schreiben? (um eben mit meiner gerade sehr begrenzten Zeit zu haushalten).

    Viele Grüße

    JP

    im Falle eines Falles klebt Gaffa einfach alles, denn Gaffa ist dein Freund und Helfer :thumbup:

  • Von 3.2.3 auf 3.3.0 waren viele Farbwerte, Effekte von den Effektcues sowie manche Dimmerwerte nicht mehr richtig.

    Kannst du das Projekt aus DMXC 3.2.3 auch noch zur Verfügung stellen? Das hört sich in der Tat etwas komisch an, denn in diesem Bereich gab es keine Änderungen, die sich auf den Inhalt von Cues von Cuelists selbst auswirken.

    hier ist das zuletzt aktive Projekt von der 3.2.3

    Probier es doch einmal mit einen neuen sehr kleinen jungfräulichen Projekt und ein paar einfachen Cue(List).

    Ich habe mir mal für Sonderevents eine Vorlage gebaut, wo ich die bestehenden Cues zum Großteil gelöscht habe und für jede Veranstaltung neu zusammenstelle. Dort ist mir so etwas noch nie passiert. Würde meine Theorie bestätigen. Aber wir bekommen es nicht hin, das Verhalten zu reproduzieren. Dann wäre es einfacher einen Fehler einzugrenzen.

    Aber es wäre auf jeden fall einen Versuch wert, einfach die Cues mal zu löschen und neu zu erstellen.

  • Also wenn ich dein Projekt mal so anschaue, hast du beim Input Assignment alle Register gezogen. Das Problem ist dabei, dass deine Connection Sets alle aufeinander aufbauen und hier womöglich kettenreaktionen auslösen. Du steuerst z.b. GoTo an. Wenn hier eine 0 am Eingang anliegt, wird die erste Cue gestartet.

    Ohne das jetzt mir zwei Stunden anzuschauen würde ich sagen, du musst da etwas komplexität raus nehmen und eine einheitliche Ansteuerung bauen. Z.b. würde ich an einigen stellen den LTP Node verwenden. Hier kann man sogar in den Einstellungen festlegen, dass Werte wie 0 oder null oder so ignoriert werden. Das vereinfacht dir einige Connectionsets.

    Gruß

    Nutzer99

  • Also wenn ich dein Projekt mal so anschaue, hast du beim Input Assignment alle Register gezogen. Das Problem ist dabei, dass deine Connection Sets alle aufeinander aufbauen und hier womöglich kettenreaktionen auslösen. Du steuerst z.b. GoTo an. Wenn hier eine 0 am Eingang anliegt, wird die erste Cue gestartet.

    Ohne das jetzt mir zwei Stunden anzuschauen würde ich sagen, du musst da etwas komplexität raus nehmen und eine einheitliche Ansteuerung bauen. Z.b. würde ich an einigen stellen den LTP Node verwenden. Hier kann man sogar in den Einstellungen festlegen, dass Werte wie 0 oder null oder so ignoriert werden. Das vereinfacht dir einige Connectionsets.

    Gruß

    Nutzer99

    Nur das ich es annähernd verstanden habe. Als Beispiel beim Input Assignment bei General/Seitenwechsel wäre es einfacher einen LTP zu nutzen anstelle on 20x Binary Switcher? GoTo habe ich auf die schnelle nicht gefunden, da die meisten Cues die wir ansteuern wie im Screenshot zu sehen ist aufgebaut ist.

    Also wäre eine Lösung zu schauen was man aktuell überhaupt noch nutzt und fürs arbeiten braucht und entsprechend diese Bereiche neu aufbaut und vereinfacht?

    Dann wäre die Chance geringer für eine Kettenreaktion die immer wieder ein anderes Bild aufzeigen kann, da nicht gesagt ist das diese eine Kette jedes mal gleich abläuft?

  • Du steuerst z.b. GoTo an. Wenn hier eine 0 am Eingang anliegt, wird die erste Cue gestartet.

    Damit ist ein Eingang am Cuelist-Node gemeint.

    Als Beispiel beim Input Assignment bei General/Seitenwechsel wäre es einfacher einen LTP zu nutzen anstelle on 20x Binary Switcher?

    Ich selbst habe in dein Projekt noch nicht reinschauen können. Was nutzer99 mit dem Hinweis "verwende doch ein LTP-Node" meint: dieses bietet seit DMXC 3.3.0 einen weiteren Ausgang, der mitteilt, an welchem Eingang die Werteänderung unter Berücksichtigung der für das Node gewählten Einstellungen zuletzt erfolgte. Kommen am LTP-Node also 10 Buttons / Taster an, wählst du in den Einstellungen die Option "Ignore Zero values" (oder so ähnlich) und dann nennt dir der zweite Ausgang immer den Button, den du zuletzt gedrückt hast. Alle Buttons selbst brauchen dabei nur ein True bzw. 1 zu schicken, wenn man sie drückt.

  • Ich habe mir nun auch nochmal dein Projekt live angesehen und kann nochmal folgendes sagen:

    • Der von nutzer99 angemerkte Punkt zum Thema "die massenhaft verwendeten Binary Switcher durch LTP-Nodes" ersetzen möchte ich so grundsätzlich auch unterschreiben und sogar erweitern. Denn ihr "schiebt" in vielen Connectionsets mal mehr mal weniger Werte in einen Input eines Nodes. Dieses wird nun von DMXC3 nicht explizit unterbunden, aber am Ende kann es passieren, dass nicht klar ist, wie welcher Wert durchgereicht werden soll. Sollen also mehrere Werte in einem Input verarbeitet werde, sollte dies mit einem vorgeschalteten Logik-Node in geordnete Bahnen gelenkt werden. Das kann eben ein LTP-Node sein, aber auch ein Math-Node oder ein Logic-Node. Diese Nodes stellen ja auch immer mehrere Inputs zur Verfügung. Am Ende kommt im Idealfall an jedem Input eines Nodes auch immer nur eine Verbindung an.
    • Insgesamt solltet ihr euch aber grundlegend über euer Ansteuerungskonzept Gedanken machen. Ihr habt in eurem Projekt eine sehr komplexe Livesteuerung realisiert, die vergleichsweise viel ausschließlich auf dem Programmer basiert. Dass ihr euch hier immer wieder mal das Licht auf der Bühne ausschaltet, wundert mich in dem Sinne nicht, wenn es Probleme bei den Abhängigkeiten im Input Assignment gibt. Denn wie an vielen Stellen gesagt, dient der Programmer in DMXControl 3 vorrangig dem Programmieren von neuen Lichtstimmungen und dem Ändern von vorhandenen - aber weniger, um damit eine Liveshow zu fahren.
    • In meinem Beitrag von gestern sagte ich, dass sich im Bereich des Speichern von Werten in Cues von Cuelists nichts zu DMXC 3.3.0 bzw. 3.3.1 geändert hat. Da ging ich aber eben davon aus, dass ihr auch entsprechend mit Cuelists arbeitet. Anders sieht es aber im Bereich des Input Assignments aus. Hier gibt es in der Tat zahlreiche funktionelle Änderungen an zahlreichen Nodes. Folglich möchte ich nicht ausschließen, dass das "komische" Verhalten des Projekts daher rührt - eben in der Kombination der sehr umfangreichen Livesteuerung über den Programmer.

    Nach dem ganzen Feedback möchte ich aber umgekehrt auch meinen Respekt aussprechen. Ihr habt hier in der Tat eine sehr umfangreiche Lösung geschaffen, mit der ein einfaches Stream Deck sehr umfangreich bespielt wird - und die sicher wie erwähnt auch gut für das Programmieren von Lichtstimmungen funktioniert, jedoch weniger für eine Liveshow.

    Komplett wegschmeißen müsst ihr die Ansteuerung im Übrigen auch nicht. Vieles lässt sich garantiert auch gut zum Beispiel auf entsprechende Color-Master oder Parameter-Master umbauen, welche dann für die jeweiligen Gerätegruppen in Cuelists abgespeichert werden. So wäre es zum Beispiel möglich, die jeweilige Gerätegruppe in einem bestimmten Helligkeitswert und einer bestimmten Farbe ein- und wieder auszublenden. Damit würden die harten Wechsel von Farbe und Helligkeit zumindest dann der Vergangenheit anhören, wenn diese Werte vor dem Starten der jeweiligen Cuelist gesetzt wurden. Dies mal so als erste Schlagworte, was mit DMXC 3.3.1 mittlerweile möglich ist.

  • LightningBrothers November 7, 2025 at 7:25 PM

    Changed the title of the thread from “Immer wieder Blackout oder wenig/keine Reaktion” to “Immer wieder Blackout oder wenig / keine Reaktion”.
  • Erst einmal Danke für die ganzen Tipps und Infos zu unserem Projekt :)

    Ich habe in diesem Jahr den Bereich erst übernommen und entsprechend habe ich recht wenig an dem bisherigen Input Assigment gearbeitet sondern das bestehende Projekt weitergeführt aber wenig am Grundgerüst gearbeitet. Vieles wollte man damals über das Streamdeck bedienen können, ist uns auch gelungen aber das weißt mittlerweile Schwächen/Probleme auf.

    Ich habe mich heute nochmals einige Stunden mit dem Problem befasst und tatsächlich werden Werte hinterlegt im Programmer durch unser Input Assigment beim Start. Selbst wenn man eine Cuelist startet werden insbesondere die Dimmerwerte nicht überschrieben, bzw. bleiben bestehen. Als Hauptursache konnte ich SD Dimmer ausmachen.

    Wenn man einzeln Änderungen machte und die Cueliste durchging wurde beim wechsel alles auf 0 gesetzt. Außer die Geräte welche man bearbeitet hat und ein Switchpack.


    In einem neuen Projekt für Sonderevents gehe ich mittlerweile so vor, das ich vieles entfernt habe und im normalen Cueablauf die Farbwerte auf meine Geräte setze und mit extra Cues lediglich den Dimmer ansteuer. Somit hatte ich keine Probleme bisher.

    Notlösung bis ich alles umgebaut habe ist es einige Bereiche zu entfernen/ beim Start auf clear zu gehen.


    Ich denke ich werde vieles noch aussortieren müssen was unübersichtlich ist, nicht mehr aktiv genutzt wird und werde vieles vereinfachen und besser Strukturieren.

    Abschließend kann man sagen, die Art und Weise des Input Assigment ging bei 3.2.3 noch gut, aber in der neueren Version ist vieles neu und auch besser geworden und somit kam unser Gerüst ins Wanken. Einiges an Arbeit aber eine grandiose Software :)

  • [Es] tatsächlich werden Werte hinterlegt im Programmer durch unser Input Assigment beim Start. Selbst wenn man eine Cuelist startet werden insbesondere die Dimmerwerte nicht überschrieben, bzw. bleiben bestehen.

    Das ist dann nochmal eine Sache der Prioritäten zwischen Cuelists, die ausgeführt werden und dem Programmer. Hier musst du mal schauen, wie die Einstellung im Projekt aussieht.

    Ist die Priorität für den Programmer auf „Programmer“ gesetzt, können Cuelists selbst mit der höchsten Priorität die Werte für die entsprechende Funktion nicht überschreiben. Anders ist es, wenn die Priorität für den Programmer auf „Normal“ gesetzt ist.

    Liegen also nach dem Laden des Projekts bereits Werte im Programmer und die Priorität für den Programmer ist auf „Programmer“ gesetzt, musst du auf alle Fälle einmal den Inhalt des Programmers mittels Clear entfernen.