Bugtracker DMXControl 3

Klone ich ein bestehendes Connectionset mit mehreren Nodes, so werden die darin verwendeten Nodes nicht aktualisiert bzw. aktiviert. Dadurch arbeitet das Connectionset nicht wie gewünscht. Der beigefügte Screenshot zeigt die Situation nach dem Klonen. Das Connectionset selbst als auch die zugehörige Bank ist aktiv.

Dieses Ticket ist (möglicherweise) ein Seiteneffekt vom Ticket  FS#4129 , der dort bereits schon angemerkt wurde.

Aktuell bietet das Node Position to Pan / Tilt nur die Ausgänge für Pan und Tilt als DMX-Wert, jeweils für 8 bit und für 16 bit. Benötige ich aber in einem Connectionset den Wert für Pan und / oder Tilt im Wertebereich 0 bis 1, muss ich mir erst das beigefügte Connectionset bauen und verkompliziere den Graphen dadurch unnötig.

Hier wünsche ich mir eine Möglichkeit, dass ich die Werte direkt im Wertebereich 0 bis 1 erhalte.

Beim DMX-Interface-Node werden die Ausgänge Available, Heartbeat und Heartbeat restarts nicht aktualisiert, was insbesondere am Heartbeat zu sehen ist.

Ziehe ich mein aktives Nodle R4S am PC ab, wäre zudem zu erwarten, dass sich der Wert für Available von true auf false ändert - spätestens, wenn im Kernel entsprechende Logeinträge aufgeführt werden.

Problem siehe oben und lässt sich wie folgt reproduzieren:

1. Slider mit Parametermaster 1 verknüpfen.
2. Connectionset deaktivieren.
3. Im Parametermaster-Node einen anderen Parametermaster, zum Beispiel Parametermaster 2 auswählen.
4. Connectionset aktivieren.

Das Ergebnis ist, dass der Slider nach dem Reaktivieren des Connectionsets weiterhin den Parametermaster 1 anspricht, obwohl im Connectionset auf der Inputseite die ID des Parametermaster 2 vermerkt ist. Diese wurde intern nicht weiterverarbeitet. Gleiches lässt sich mit dem Cuelist-Node reproduzieren.

Das Powersource-Node wird nicht aktualisiert, wenn die Geräte einer Device Group oder die aktuelle Auswahl in der Stage View mehreren Powersources zugeordnet sind.

1. 8 Geräte mit gepflegten Leistungsdaten anlegen.
2. 2 oder mehr Powersources anlegen.
3. Geräte 1 bis 4 der Powersource A, Geräte 5 bis 8 der Powersource B zuordnen.
4. Neues, leeres Connectionset anlegen, Powersource-Node einfügen und Powersource A wählen.

In den beiden folgenden Fällen werden die Inhalte des Nodes nicht aktualisiert:

1. Man wählt in der Stage View die Device Group aus und highlightet diese.
2. Man wählt manuell die Geräte 1 bis 5 aus.

Wählt man dagegen nur die Geräte 1 bis 4 aus, aktualisiert das Powersource-Node die Werte auf der Output-Seite, auch ohne dass hieran weitere Nodes etc. angeschlossen sind.

Ordne ich den Eingängen eines Input Selectors verschiedene Farben als RGB-Wert zu, so werden die nach dem Speichern und Neuladen des Projekts konvertiert (siehe Bild 1).

Ändere ich den Farbwert nach dieser fehlerhaften Konvertierung, so versteht der nachgeschaltete Button die Farbe nicht mehr als Farbwert sondern nur als Text und ändert dem entsprechend unbeabsichtigt seine Beschriftung (siehe Bild 2).

Ich habe ein Softdesk neu gebaut, wo mehrere Cuelist Monitore im Einsatz sind. Diese sollen mir die Cuelists aus verschiedenen Cuelist Groups anzeigen. Im Input Assignment erstelle ich das hierfür benötigte Connectionset (Cuelist Group Node → Cuelist Monitor) für die erste Cuelist Group. Nach dem Hinzufügen der Verbindung, sehe ich im Softdesk wie erwartet die der Cuelist Group zugeordneten Cuelist.

Wenn ich dieses Connectionset nun vervielfältige, um nach und nach die restlichen Cuelist Monitor zu füllen und ich nicht aufpasse, verliert der Cuelist Monitor des vorherigen Connectionsets die Inhalte. Bedeutet: ich habe sechs Cuelist Monitore in meinem Softdesk. Nach dem sechsten Duplizieren und Anpassen des Connectionsets zeigt nur noch der letzte Cuelist Monitor die zugehörigen Cuelists “seiner” zugeordneten Cuelist Group an.

Mögliche Workarounds sind zwar

• ich deaktiviere das Connectionset, von dem ich das Duplikat anlege
• ich füge den entsprechenden Cuelist Groups temporär eine andere Cuelist hinzu, nachdem ich im Input Assignment fertig bin
• ich speichere das Projekt und lade es neu

Diese sind aber allesamt unbefriedigend, weil sie zusätzliche Handlungen und Hintergrundwissen erfordern.

Von daher wäre es gut, wenn dieses Verhalten entweder grundlegend abgestellt werden kann oder ich die Möglichkeit erhalte, die Aktualisierung aller Connectionsets (oder die der aktiven Bank) manuell anstoßen zu können, so wie es ja auch beim Laden des Projekts bereits der Fall ist.

Aktuell befinden sich die beiden Einträge zum Anlegen einer neuen Bank und eines neuen Connectionset als Unterpunkte in den Menüs zu den beiden Buttons “Bank” und “Connectionset”. Da aber insbesondere beim manuellen Anlegen neuer Connectionsets dieser Eintrag recht häufig benötigt wird, war in der letzten Betatester-Runde der Wunsch, diese Einträge nach “vorne” zu holen. Damit ist gemeint, dass das Anlegen einer neuen Bank und eines neuen Connectionsets im Idealfall mit einem Mausklick erfolgen kann.

Ich habe dieses Ticket daher mal auf Usabiltiy Relevant gesetzt, da es sicher einige Varianten gibt, dieses zu realisieren.

Wie unter anderem beim Logic- oder beim Math-Node wäre es hilfreich, wenn man bei Bedarf die Anzahl an Ein- / Ausgängen beim Input bzw. Output Selector erhöhen könnte. Eventuell wäre hier auch zu überlegen, die obere Grenze nicht auf 10 Ein- / Ausgänge zu begrenzen, sogar hier bis zu 25 zuzulassen.

Um mittels Buttons bestimmte Szenen einer Szenenliste direkt aufzurufen, muss man aktuell zum Beispiel die Ausgangswerte der Buttons entsprechend anpassen, dass der Button 1 die Werte -1 und 0 und der Button 5 die Werte -1 und 4 übergibt. Dies führt zu aufwendigen Konfigurationen.

Hier sollte ein Node hilfreich sein, welches immer die ID des zuletzt geänderten Inputs n ausgibt. Die ID ist dabei der Zahlenwert des Inputs. Zusätzlich kann ich in den Einstellungen festlegen, ab welchem Wert die ID der verfügbaren Inputs hochgezählt werden soll. Die Anzahl der verfügbaren Inputs kann ich analog zum Beispiel des LTP-Nodes festlegen.

Mit dem Projekt aus Ticket  FS#4415  kann ich unten genanntes Fehlverhalten des Programmer-Nodes generieren, wenn ich folgende Schritte ausführe:

1. Ich lade die Cue aus der Cuelist 1 in den Programmer und sehe dann alle Änderungen im Makroboard-Profil.
2. Ich schließe nur die GUI und beende dabei auch die Session. Den Programmer leere ich nicht.
3. Nach dem Neustart der GUI nehme ich erneut Änderungen an der Cue vor und lade diese hierzu in den Programmer.

In diesem Fall aktualisiert das Programmer-Node seine Werte an den Outputs nicht, weswegen auch keine Aktualisierung der Werte im Makroboard-Profil erfolgt. Das Device Control als auch die Stage View zeigen die neuen Werte an.

Möglicherweise ist dieser Punkt in DMXControl 3.3 durch den gRPC-Umbau korrigiert. Ansonsten darf dieses Ticket dahingehend verstanden werden, dass dieser Punkt zu prüfen ist.

Aktuell werden Connectionsets nur neu berechnet, wenn eine Werteänderung im logischen Verlauf des Graphen erfolgt. Ein gutes Beispiel ist hier das “Füllen” des Cuelist Monitors. Je nachdem wie das zugehörige Connectionset vervielfältigt wird, kommt es vor, dass der Inhalt des Cuelist Monitors gelöscht wird - nämlich bis ich entweder

1. das Projekt nach dem Speichern neu lade
2. kurzzeitig eine weitere Cuelist der entsprechenden Cuelist Group zuordne.

Dieser Fall ist auch in meinem Live-Tutorial "Clubshow mit DMXC3" ab 42:08 zu sehen. Ursprung für alle nachfolgenden Connectionsets (CS) war das Connectionset “MHS LCH”. Dieses CS ist nach dem Aktivieren aller CS das einzige, wo die Cuelists der gleichnamigen Cuelist Group nicht angezeigt werden. Hierzu wähle ich weiteren Verlauf die 2. Option, um auch die Cuelists in diesem Cuelist Monitor zu sehen.

Um das ganze Prozedere zu vereinfachen, wünsche ich mit eine Möglichkeit, die Aktualisierung bzw. Neuberechnung eines CS sowohl in der Graphenansicht für den aktuellen Graphen oder in der Tabellenansicht für eine oder eine Auswahl von CS manuell anstoßen zu können.

Ich habe das folgend beigefügte Projekt gebaut, in dem ich über das Input Assignment den Manual Beat Node mit der Taste Q (keine Tastenkombination) triggern möchte. An den Outputs werden nur die Anzahl der Beat Signale hochgezählt. Die Berechnung oder gar Aktualisierung der Outputs für Hz, BPM, s etc. findet nicht statt. Dabei macht es keinen Unterschied, ob ich das Beat-Tool sowohl über die Taste 1 über das Input Assignment oder per Mausklick in der GUI aktiviere oder deaktiviere.

Eventuell steht auch folgender Log-Eintrag der GUI mit in diesem Zusammenhang:

2021-04-26 19:59:43,762 [Log-Thread] DEBUG Lumos.GUI.Net.gClient.Beat_gClient - LearnManualBeat
Grpc.Core.RpcException: Status(StatusCode=DeadlineExceeded, Detail="Server didn't respond.")
   bei System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
   bei System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   bei System.Runtime.CompilerServices.ConfiguredTaskAwaitable`1.ConfiguredTaskAwaiter.GetResult()
   bei Lumos.GUI.Net.gClient.Beat_gClient.<LearnManualBeat>d__6.MoveNext() in D:\Jenkins\workspace\Lumos_Pipeline_master\LumosGUI\src\Net\gClient\Beat_gClient.cs:Zeile 69.

Dieses Verhalten bzw. Problem besteht auch in DMXControl 3.2.2, ist also in dem Sinne nicht zwingend ein neues Problem.

Ich habe in meinem Club22-Projekt mehrfach einen Count-Down ins Softdesk eingebaut, um die Zeit in Minuten und Sekunden bis zum Auslösen einer Aktion ausgeben zu können. Das Umbauen eines entsprechen Werts benötigt hier aber das im Anhang beigefügte Connectionset. Ausgangspunkt ist der Fade-Output des Cue-Nodes. Im Rule of Three-Node geschieht die Umrechnung des Prozentwerts in Sekunden. Die nachfolgenden vier Nodes übernehmen die Aufteilung in Minuten und Sekunden. Der größte Nachteil an diesem Aufbau ist, dass ich beim Ändern der Fadezeit der Cues das Rule of Three manuell anpassen muss und auch nicht mit wechselnden Fadezeiten arbeiten kann.

Um dies zu vereinfachen und universeller zu gestalten, schlage ich die Implementierung eines Count-Down-Nodes vor. Der Name Count-Down ist aber aktuell nur ein Arbeitstitel - vielleicht gibt es hier noch einen besseren.

Dieses Node ist wie folgt aufgebaut:

• Eingänge
  • Fadewert in % als dynamisch verändernder Wert wie er zum Beispiel aus dem Cue-Node kommt
  • Zeitbezugswert als fester Wert in Sekunden, welcher entweder manuell gesetzt oder aus einem anderen Node übergeben wird
  • Zeitwert als dynamischer Wert in Sekunden oder Millisekunden, wenn die Quelle diesen bereits zur Verfügung stellt
• Ausgänge
  • Zeitangabe in HH:MM:SS als String, abhängig von der eingestellten Vorlage
• Einstellungen
  • Angabe des Zeitformats aus einer Auswahl von fest vorgegeben Vorlagen wie SS, MM:SS, HH:MM:SS, etc.
  • Angabe der Einheit auf der Eingangseite für die Zeit in Sekunden oder Millisekunden, sofern sich das nicht aus dem ankommenden Wert “herauslesen” lässt
  • Zählrichtung, also absteigend (klassischer Count-Down) oder zunehmend (Stopp-Uhr)
  • Ggf. ein benutzerdefiniertes Prefix oder Suffix

Im beigefügten Projekt ist das Expression-Node mit drei Variablen x, y und z konfiguriert. Da scheinbar beim Laden des Projekts die Variable z mit dem zugehörigen Input nicht rechtzeitig geladen wird, wird die Verbindung zu diesem Input gelöscht. Der Kernel zeigt an dieser Stelle den folgenden Eintrag.

2021-08-27 10:08:46,945 [Log-Thread] WARN  org.dmxc.lumos.Kernel.Input.v2.InputManager - Unable to add Edge to Graph: Missing port.
Parametername: e
System.ArgumentException: Missing port.
Parametername: e
   bei org.dmxc.lumos.Kernel.Input.v2.Graph.AddEdges(IEnumerable`1 edges, Boolean processGraph, Boolean reassignLevel) in D:\Jenkins\workspace\Lumos_Pipeline_3.2\Lumos\src\Kernel\Input\v2\Graph\Graph.cs:Zeile 335.
   bei org.dmxc.lumos.Kernel.Input.v2.Graph.AddEdge(GraphEdge e) in D:\Jenkins\workspace\Lumos_Pipeline_3.2\Lumos\src\Kernel\Input\v2\Graph\Graph.cs:Zeile 308.
   bei org.dmxc.lumos.Kernel.Input.v2.InputManager.org.dmxc.lumos.Kernel.Project.IProjectResourceUser<org.dmxc.lumos.Kernel.Input.v2.IGraph>.LoadItem(ManagedTreeItem item, LumosIOContext context) in D:\Jenkins\workspace\Lumos_Pipeline_3.2\Lumos\src\Kernel\Input\v2\InputManager.cs:Zeile 1623.

Im Anhang findet sich das Projekt sowie die vollständigen Logfiles.

Ich habe den Output “Child ID” des Device Group Nodes mit dem Input “List” des List Selector verbunden. Möchte ich nun durch diese Liste durchschalten, erscheint bei jeder Umschaltung der folgende Eintrag im Kernel. Als Wert für die Umschaltung übergebe ich ganzzahlige Werte (also int-Werte) mittels des Counter-Nodes im Bereich 0 bis 10.

13:16:20 ERROR AbstractNode -
System.NullReferenceException: Der Objektverweis wurde nicht auf eine Objektinstanz festgelegt.
   bei org.dmxc.lumos.Kernel.Input.v2.Worker.ListSelectorNode.processInternal(NodeProcessContext context) in D:\Jenkins\workspace\Lumos_Pipeline_3.2\Lumos\src\Kernel\Input\v2\Graph\Node\Worker\Logic\ListSelectorNode.cs:Zeile 93.
   bei org.dmxc.lumos.Kernel.Input.v2.AbstractNode.process(NodeProcessContext context) in D:\Jenkins\workspace\Lumos_Pipeline_3.2\Lumos\src\Kernel\Input\v2\Graph\Node\AbstractNode.cs:Zeile 230.

Der DMXCMixer-Node gibt am Strobe-Output keinen Double-Wert aus, sodass nachfolgende, numerisch arbeitende Nodes wie der Compare-Nodes mit den ausgegebenen Werten nicht direkt arbeiten können. Hierzu muss der Wert erst unnötigerweise mit einem Format-Node konvertiert werden. Dieses Verhalten ist insofern unschön als dass es zum einen nicht von außen ersichtlich und zum anderen sich im direkten Vergleich mit dem Intensity-Output nicht gleich verhält. Der Intensity-Output gibt direkt einen Double-Wert aus.

Der Blick in den Code zeigt, dass der DMXCMixer offensichtlich von vorn herein unterschiedliche Datentypen erhält. Denn abgesehen von den verschiedenen Parametern Dimmer (Intensity) bzw. Strobe gibt es keine Unterschiede.

Um etwas mit dem List Selector zu spielen, habe ich mir das im beigefügten Projekt enthaltene Connectionset gebaut. Über die Buttons “previous” und “next” kann ich die Geräte der zugeordneten Gerätegruppe durchschalten. Für einen schnellen Überblick einfach das letzte Fensterlayout laden.

Hierbei musste ich aber feststellen, dass die Liste, welche das Device Group Node generiert, nicht der Reihenfolge der Sortierung der Geräte innerhalb der Device Group entspricht. Die erwartete Sortierung entspricht dem, wie die Geräte in der Stage View von links nach rechts positioniert sind. Selbst eine einfache alphabetische Sortierung der Geräte entsprechend ihres Namnes oder auf Basis der Gerätenummer findet nicht statt. Somit ist es in der aktuellen Version etwas unintuitiv, das gewünschte Gerät aus der Liste herauszusuchen.

Ich möchte mit einem einzigen Fader den Wert eines Position-Masters ändern. Dazu baue ich mir ein Positions-Objekt mittels des Format-Nodes zusammen und habe dies mit “{0:0.##}; {1:0.##}” parametriert. Erhält das Position Master Node diesen Wert, gibt der Kernel folgende Fehlermeldung aus:

19:11:23 WARN  EventTools - Exception in Delegate Invocation: Void <AddDefaultPorts>b__37_3(org.dmxc.lumos.Kernel.Input.v2.GraphNodePortID, System.Object) => org.dmxc.lumos.Kernel.Input.v2.Worker.PositionMasterNode.Void <AddDefaultPorts>b__37_3(org.dmxc.lumos.Kernel.Input.v2.GraphNodePortID, System.Object)
System.Reflection.TargetInvocationException: Ein Aufrufziel hat einen Ausnahmefehler verursacht. ---> System.ArgumentOutOfRangeException: Input must be <= inMax [0]
Parametername: input
Der tatsächliche Wert war 0,5.
   bei LumosLIB.Tools.LumosTools.RuleOfThree(Double input, Double inMax, Double inMin, Double outMax, Double outMin, ERuleOfThreeBehavior behavior) in D:\Jenkins\workspace\Lumos_Pipeline_master_2\LumosLIB\src\Tools\LumosTools.cs:Zeile 544.
   bei org.dmxc.lumos.Kernel.Master.PositionMaster.set_Value(Position value) in D:\Jenkins\workspace\Lumos_Pipeline_master_2\Lumos\src\Kernel\Master\PositionMaster.cs:Zeile 170.
   bei org.dmxc.lumos.Kernel.Input.v2.Worker.PositionMasterNode.setInputaValue() in D:\Jenkins\workspace\Lumos_Pipeline_master_2\Lumos\src\Kernel\Input\v2\Graph\Node\Wrapper\Master\PositionMasterNode.cs:Zeile 189.
   bei org.dmxc.lumos.Kernel.Input.v2.Worker.PositionMasterNode.<AddDefaultPorts>b__37_3(GraphNodePortID sender, Object value) in D:\Jenkins\workspace\Lumos_Pipeline_master_2\Lumos\src\Kernel\Input\v2\Graph\Node\Wrapper\Master\PositionMasterNode.cs:Zeile 236.
   --- Ende der internen Ausnahmestapelüberwachung ---
   bei System.RuntimeMethodHandle.InvokeMethod(Object target, Object[] arguments, Signature sig, Boolean constructor)
   bei System.Reflection.RuntimeMethodInfo.UnsafeInvokeInternal(Object obj, Object[] parameters, Object[] arguments)
   bei System.Delegate.DynamicInvokeImpl(Object[] args)
   bei LumosToolsLIB.Tools.EventTools.<>c__DisplayClass9_0.<InvokeFailSafe>b__0(Delegate a) in D:\Jenkins\workspace\Lumos_Pipeline_master_2\LumosToolsLIB\src\Tools\EventTools.cs:Zeile 136.
   bei LumosToolsLIB.Tools.EventTools.InvokeFailSaveGeneric[TDelegate,TReturn](TDelegate delegate, Func`2 invoker, ILumosLog elog) in D:\Jenkins\workspace\Lumos_Pipeline_master_2\LumosToolsLIB\src\Tools\EventTools.cs:Zeile 180.

Das Position to Pan/Tilt Node versteht die so erstellten Werte dagegen und arbeitet erwartungsgemäß.

Ich möchte mir den aktuellen Farbwerrt eines Color Masters auf dem Buttons eines Macroboard Profiles anzeigen lassen und habe dazu den Ausgang “Value” des Color Masters direkt mit dem Eingang “Background Color” des Draw Bitmam Nodes verbunden.

Während der Color Master am Ausgang “Value” den Wert “1; 1; 1” als LumosColor-Objekt ausgibt, erwartet der Eingang “Background Color” des Draw Bitmap Nodes einen RGB-Wert. Folglich bleibt der Button effektiv gesehen dunkel, da ja “1; 1; 1” im RGB-Farbraum mit dem Wertebereich 0 bis 255 effektiv gesehen schwarz ist.

Im Hinblick darauf, dass wir im Input Assignment weitestgehend mit normierten Werten arbeiten wollen, sollte der Draw Bitmap Node als Folge dessen das LumosColor-Objekt an beiden Eingängen für die Farbe verstehen.

Ich möchte das aktuell gewählte Gobo eines Geräts auf dem Macro Board ausgeben und habe dazu den Ausgang “Gobo” des DMXC-Mixer-Nodes mit dem Node “Bitmap from Resource” verbunden. Dies soll eigentlich das Bild an den betreffenden Button übergeben. Stelle ich diese Verbindung her, erscheint im Kernel folgender Eintrag:

19:37:00 ERROR BitmapFromResource -
System.NullReferenceException: Der Objektverweis wurde nicht auf eine Objektinstanz festgelegt.
   bei org.dmxc.lumos.Kernel.Input.v2.Worker.BitmapFromResource.processInternal(NodeProcessContext context) in D:\Jenkins\workspace\Lumos_Pipeline_3.3\Lumos\src\Kernel\Input\v2\Graph\Node\Worker\Converter\Bitmap\BitmapFromResource.cs:Zeile 55.

Auf Grund dieser Fehlermeldung arbeiten die nachfolgenden Teile des Graphs nicht und ich sehe folglich auch kein Bild auf dem Button. Wähle ich stattdessen manuell eine Resource aus, arbeitet das Node “Bitmap from Resource” wie erwartet.

Füge ich am Gobo-Output des DMXCMixers das MacGyver-Node ein, wird im Übrigen der Name des Gobos nicht unter Image File im LumosGobo-Object geführt, sondern der Name des Gobos erscheint unter dem Ausgang “Min Value”. Schließe ich das Bitmap from Resource an diesen Ausgang an, werden mir die Gobos zumindest angezeigt, sofern ich ein Gobo des ersten von zwei Goborädern auswähle. Die Aktualisierung läuft aber nicht ganz so zuverlässig.

Nachdem ich nun das Position Master Node grundsätzlich extern ansteuern kann, ist mir aufgefallen, dass das Node am Value Input reale Positionswerte in Grad erwartet. Dies ist insbesondere im Zusammenspiel mit einer externen Ansteuerung über Fader etc. ungünstig, wie ich es bereits im Ticket  FS#4786  angeschnitten habe. Ändere ich den Aktionsbereich des zugeordneten Position Masters, muss ich auch in den Connectionsets verschiedene Anpassungen vornehmen.

Ich sehe hier folgende Ansätze, diesen Fehler (weil wir ja eigentlich immer nur mit normierten Werten von 0 bis 1 innerhalb der Connectionsets arbeiten wollen) zu beheben:

• Der Value Input wird so angepasst, sodass er nur eine normierte Position versteht.
• Der aktuelle Input wird erhalten und ein weiterer Input ergänzt, der dann die normierte Position versteht.
• Der aktuelle Input wird erhalten und analog zum Programmer-Node zwei getrennte Inputs für Pan und Tilt ergänzt.

In DMXControl 3.3.0 Beta 2 kann ich im Input Selector Node keine eigenen Eingaben mehr hinterlegen. Sobald ich in ein anderes Feld klicke, werden diese wieder entfernt. Dieser Fehler existierte bis zur Beta 1 noch nicht.

Log-Dateien kann ich keine zur Verfügung stellen, weil diese Änderungen im Node nicht protokolliert werden.

Seit DMXControl 3.3.0 Beta 2 werden RGB-Werte für Farben vom Input Selector wieder in ein Lumos-Color-Objekt konvertiert.

Dieses Problem hatten wir bereits im Rahmen des Beta-Tests von DMXControl 3.2.2. Seiner Zeit hatte ich es im Ticket  FS#4273  berichtet. Die dort vorhandenen Screenshots sind 1.1 übertragbar, weswegen ich keine neuen Screenshots erstellt habe.

Ich habe in dem beigefügten Projekt ein Connectionset für ein Softdesk gebaut, bei dem die Input und Output Selectoren mit mehr als 4 Eingängen konfiguriert sind. Beim Input Selecotor sind es 5 (1..5) und beim Output Selector 6 (1..6). Speichere ich das Projekt und lade es erneut, wird es auf Grund des folgenden Fehlers nicht geladen:

13:48:02 WARN  Graph - Unable to add Edge to Graph: Missing port.
Parametername: e
System.ArgumentException: Missing port.
Parametername: e
   bei org.dmxc.lumos.Kernel.Input.v2.Graph.AddEdges(IEnumerable`1 edges, Boolean processGraph, Boolean reassignLevel) in D:\Jenkins\workspace\Lumos_Pipeline_3.3\Lumos\src\Kernel\Input\v2\Graph\Graph.cs:Zeile 337.
   bei org.dmxc.lumos.Kernel.Input.v2.Graph.AddEdge(GraphEdge e) in D:\Jenkins\workspace\Lumos_Pipeline_3.3\Lumos\src\Kernel\Input\v2\Graph\Graph.cs:Zeile 310.
   bei org.dmxc.lumos.Kernel.Input.v2.Graph.org.dmxc.lumos.Kernel.Resource.ILumosSaveable.loadFromManagedTree(ManagedTreeItem item, LumosIOContext context) in D:\Jenkins\workspace\Lumos_Pipeline_3.3\Lumos\src\Kernel\Input\v2\Graph\Graph.cs:Zeile 802.

Da der Fehler eindeutig zuzuordnen ist, füge ich nur das Beispielprojekt bei.

Die standardmäßig verfügbaren Master “Color Master 1”, “Speed Master 1” und “Parameter Master 1” lassen sich nicht per Drag & Drop einem Graphen hinzufügen, wenn ich dies aus dem Input-Baum heraus mache. Aus dem Output-Baum heraus lassen sich diese genannten Master jedoch ohne weiteres per Drag & Drop dem aktuellen Graphen hinzufügen.

Dies lässt sich direkt mit einem leeren Projekt reproduzieren. Logeinträge sind hierzu nicht vorhanden.

Nachdem sich nun Projekt mit “großen” Input Selctoren laden lassen, musste ich feststellen, dass die eingestellten Werte für die Inputs nicht vollständig geladen werden. DMXControl 3 liest immer nur die ersten vier Werte für die Input Selectoren aus, obwohl alle Werte in der Graphs.xml abgespeichert werden.

Im Anhang einmal der Screenshot, so wie es sein soll und das zugehörige Testprojekt.

Manchmal funktioniert die Selektion in der StageView nicht mehr…. DeviceControl und Selected DeviceNode arbeiten dann nicht

~~~~~~~~~~~~~~~~~~~

Das Selected Device Node ist dazu gedacht, die aktuelle Auswahl von Devices bzw. Device Groups im Input Assignment zur Verfügung zu stellen. Dies funktioniert so mit der Beta 5 nicht mehr. In der Beta 3 hat das Node noch erwartungsgemäß gearbeitet.

Um den Fehler nachzustellen, habe ich das beigefügte Beispielprojekt erstellt. Im zugehörigen Connectionset ist zu sehen, dass es keinerlei Aktualisierungen im Node gibt und deswegen die aktuelle Auswahl auch nicht in dem hierzu vorbereiteten Softdesk angezeigt wird. Ich muss aber nachfolgend einschränkend feststellen, dass es sich um ein eher sporadisch auftretendes Projekt handelt. Nachdem ich nun zwischenzeitlich ein bisschen hin- und hergeklickt sowie andere Projekte geladen habe, funktioniert das Node aktuell wieder. Die beigefügten Logs zeigen aber die Situation, in der es nicht erwartungsgemäß arbeitete.

Ich habe in einem Projekt ein Connectionset erstellt und dieses Projekt dann gespeichert. Danach öffne ich dieses Projekt wieder und klone den Graphen.

Ersetze ich nun innerhalb dieses Graphens per Drag & Drop die In- bzw. Output, werden mir die neuen In- bzw. Outputs sowohl im Graphen als auch in der Tabelle nicht angezeigt. Auch bei einem erneuten Ladend des Projekts erfolgt keine Aktualisierung des Namens. Die gewünschte, nach dem Klonen geänderte Zuordnung funktioniert aber.

Beispielprojekt kann bei Bedarf nachgereicht werden,

In der Beta 7 kann das Position Master Node nicht geladen werden, sobald es in einem Graphen verwendet wird.

Das unten beigefügte Projekt ist neu erstellt. Dort habe ich den Position Master 1 nur im Position Master Node einem sonst leeren Graphen hinzugefügt. Beim erneuten Laden des Projekts generiert der Kernel die nachfolgende Fehlermeldung und im Graphen wird der Node entfernt.

09:58:09 WARN  InputManager - Unable to add Node to Graph: Object reference not set to an instance of an object.
System.NullReferenceException: Object reference not set to an instance of an object.
   at org.dmxc.lumos.Kernel.Input.v2.Worker.PositionMasterNode.setInputaValue() in D:\Jenkins\workspace\Lumos_Pipeline_3.3\Lumos\src\Kernel\Input\v2\Graph\Node\Wrapper\Master\PositionMasterNode.cs:line 192
   at org.dmxc.lumos.Kernel.Input.v2.Worker.PositionMasterNode.setParameterInternal(GenericParameter parameter, Object value) in D:\Jenkins\workspace\Lumos_Pipeline_3.3\Lumos\src\Kernel\Input\v2\Graph\Node\Wrapper\Master\PositionMasterNode.cs:line 389
   at org.dmxc.lumos.Kernel.Input.v2.AbstractNode.setParameter(GenericParameter parameter, Object value) in D:\Jenkins\workspace\Lumos_Pipeline_3.3\Lumos\src\Kernel\Input\v2\Graph\Node\AbstractNode.cs:line 371
   at LumosLIB.Tools.ParameterTools.LoadParameters[TParameter](IParameterable`1 parameterable, ManagedTreeItem tree, Func`2 convertName, Func`3 convertStringValueToID, Func`3 convertObjectValueToID) in D:\Jenkins\workspace\Lumos_Pipeline_3.3\LumosLIB\src\Tools\ParameterTools.cs:line 341
   at LumosLIB.Tools.ParameterTools.LoadParameters[TParameter](IParameterable`1 parameterable, ManagedTreeItem tree) in D:\Jenkins\workspace\Lumos_Pipeline_3.3\LumosLIB\src\Tools\ParameterTools.cs:line 228
   at org.dmxc.lumos.Kernel.Input.v2.InputManager.CreateSavedNode(ManagedTreeItem n, LumosIOContext context) in D:\Jenkins\workspace\Lumos_Pipeline_3.3\Lumos\src\Kernel\Input\v2\InputManager.cs:line 0

Ändere ich den Namen für die Elemente eines Makros oder aus dem Softdesk, so wird der Name nur im Input-Baum und Output-Baum direkt aktualisiert. Die Inputs und Outputs in den Graphen selbst behalten den Namen bei.

Ich füge in einem neuen leeren Projekt das Draw Bitmap Node ein und ändere die Schriftart von “Courier New” auf “Arial”. Diese Änderung wird vom Node zwar angenommen, aber nicht umgesetzt. Auch ein Speichern und Neuladen des Projekts hilft hier nicht.

Klappe ich den Eintrag “Font” in den Einstellungen des Nodes auf, steht dort in jeder Zeile die folgende Fehlermeldung:

Der Typ "System.Drawing.FontConverter" in der Assembly "System.Drawing.Common, Version=7.0.0.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51" konnte nicht geladen werden.

Dieser Eintrag taucht in keinem der Logs auf, daher nur der Screenshot.

Das DMXC-Mixer-Node hat auf der Output-Seite aktuell nur den Output “Device”, in dem die Device-ID angezeigt wird. Hier sollten aus Konsistenzgründen noch die Outputs “Name” und “Number” hinzugefügt werden, so wie es bei vielen anderen Wrapper-Nodes der Fall ist.

Dem entsprechend würden die ersten drei Outputs wie folgt lauten:

• (Device-) Name
• (Device-) ID
• (Device-) Number

Beim Installer der Version 3.1 vom 13.03.2017 funktioniert der automatische Download nicht. Die Installation wird abgebrochen.

Checking if .NET 4 is installed...
.NET 4 found!
Checking if Visual C++ 2015 Redistributable is installed...
Visual C++ 2015 Redistributable found!
Checking if XNA 4.0 is installed...
Checking if Windows Installer 3.1 is installed...
Windows Installer 3.1 found!
Erstelle Verzeichnis: C:\Program Files (x86)\DMXControl3
Lade XNA Framework...
Download fehlgeschlagen: Timed out on connecting.

Da das kleine Tool durchaus öfters zum Einsatz kommt und ja sowohl für das DE- als auch für das Nodle-Interface funktioniert, dürfte es meiner Meinung nach hilfreich sein, wenn der Installer eine entsprechende Verknüpfung im Startmenü hinzufügt.

Bei der UAC-Abfrage lautet der Titel nun “DMXControl3 Installer“. Zum ein fehlt das Leerzeichen zwischen DMXControl und der 3, zum anderen wurde im Installer der 3.2.1 auch explizit die Version 3.2.1 genannt.

Ob das Wort “Installer” durch “Setup” ersetzt wird, ist mir dagegen gleich.

Im Installations-Assistent wird beim ersten Schritt der Text der Überschrift verdeckt, da nun auch die Build-Nummer mit in die Versionsnummer aufgenommen wurde.

Hier wäre die Frage, welchen Mehrwert die Buildnummer zumindest in den Texten darstellt.

Damit Nutzer nach der Installation nicht aus allen Wolken fallen, wenn DMXControl 3 nicht richtig läuft, würde ich vorschlagen, den Installer mit einem Hardware-Check auszustatten. Dies könnte in Hinblick auf die nächste Major-Release von größerem Interesse sein.

Der Installer liefert den GUI-Teil des Nanoleaf-Plugins nicht mit aus. Deswegen wirft der Kernel möglicherweise unter anderem folgende Fehlermeldung.

2021-04-13 21:51:08,533 [29] INFO  Nanoleaf_Plugin.NanoleafPlugin - Stop Plugin: Nanoleaf-Plugin
2021-04-13 21:51:08,534 [29] DEBUG Nanoleaf_Plugin.NanoleafPlugin - Request stop for DiscoverTask
2021-04-13 21:51:08,534 [29] DEBUG Nanoleaf_Plugin.NanoleafPlugin - Await DiscoverTask stopped

Im Anhang das Logfile des Installers.

Um die Anzahl der Verknüpfungen im Startmenü auf Wunsch zu reduzieren, soll der Installer folgende Auswahloptionen für die Verknüpfungen erhalten:

• Verknüpfungen auf dem Desktop
  • DMXControl 3 starten
  • DMXControl 3 Launcher
• Verknüpfungen im Startmenü
  • DMXControl 3 starten
  • DMXControl 3 Launcher
• Zusätzliche Verknüpfungen
  • DMXControl 3 GUI
  • DMXControl 3 Kernel
  • DMXControl 3 Umbra

Die Ausgestaltung der Auswahlmöglichkeiten kann frei gewählt werden. Vorrangig soll damit erreicht werden, dass wie in der Entwicklersitzung am 28.04.2021 besprochen, auf Wunsch die Verknüpfungen für GUI, Kernel und Umbra im Startmenü angelegt werden.

Auf Grund des folgenden Log-Eintrags kann die GUI nicht gestartet werden. Wenn ich das richtig lese, fehlt eine Datei im Installer.

2021-08-30 18:45:48,515 [Main GUI] FATAL Lumos.GUI.Run.GuiRunManager - Exception when initializing Manager SettingsManager: Die Datei oder Assembly "NGettext, Version=0.6.1.0, Culture=neutral, PublicKeyToken=08d3d1c89dfd2985" oder eine Abhängigkeit davon wurde nicht gefunden. Das System kann die angegebene Datei nicht finden.
System.IO.FileNotFoundException: Die Datei oder Assembly "NGettext, Version=0.6.1.0, Culture=neutral, PublicKeyToken=08d3d1c89dfd2985" oder eine Abhängigkeit davon wurde nicht gefunden. Das System kann die angegebene Datei nicht finden.
Dateiname: "NGettext, Version=0.6.1.0, Culture=neutral, PublicKeyToken=08d3d1c89dfd2985"
   bei LumosLIB.Tools.I18n.T.LoadCatalog(CultureInfo culture, String dir)
   bei LumosLIB.Tools.I18n.T.InitializeCatalog(CultureInfo culture, String startupPath) in D:\Jenkins\workspace\Lumos_Pipeline_master\LumosToolsLIB\src\Tools\I18n\T.cs:Zeile 94.
   bei Lumos.GUI.Settings.SettingsManager.org.dmxc.lumos.Kernel.Run.IManager.initialize() in D:\Jenkins\workspace\Lumos_Pipeline_master\LumosGUI\src\Settings\SettingsManager.cs:Zeile 96.
   bei org.dmxc.lumos.Kernel.Run.AbstractRunManager`2.ManagerInitAction(TManager m) in D:\Jenkins\workspace\Lumos_Pipeline_master\LumosLIB\src\Kernel\Run\AbstractRunManager.cs:Zeile 646.

WRN: Protokollierung der Assemblybindung ist AUS.
Sie können die Protokollierung der Assemblybindungsfehler aktivieren, indem Sie den Registrierungswert [HKLM\Software\Microsoft\Fusion!EnableLog] (DWORD) auf 1 festlegen.
Hinweis: Die Protokollierung der Assemblybindungsfehler führt zu einer gewissen Leistungseinbuße.
Sie können dieses Feature deaktivieren, indem Sie den Registrierungswert [HKLM\Software\Microsoft\Fusion!EnableLog] entfernen.

2021-08-30 18:45:48,529 [Main GUI] FATAL Lumos.GUI.Run.GuiRunManager - Unhandled Exception: Error in Startup
org.dmxc.lumos.Kernel.Exceptions.KernelPanicException: Error in Startup
2021-08-30 18:45:48,529 [Main GUI] INFO  DMXControl 3 GUI - GUI closing!

Im Anhang finden sich die vollständigen Logs inklusive die des Installers.

Ich möchte die Verknüpfungen zu den einzelnen Anwendungen von DMXControl 3 im Startmenü gerne vom Installer im folgenden Pfad ablegen lassen:

C:\ProgramData\Microsoft\Windows\Start Menu\Programs\DMXControl 3.3.0\

Dass es sich hier nun um das Verzeichnis für alle Benutzer handelt, sei erstmal irrelevant, weil ich dies ja nicht explizit festlegen kann.

Scheinbar auf Grund der existierenden Registry-Einträge für die ebenfalls auf meinen PCs installierte 3.2.3 schlägt der Installer der 3.3.0 immer folgenden Pfad vor:

C:\ProgramData\Microsoft\Windows\Start Menu\Programs\DMXControl 3.2.3\

Egal ob ich den Pfad auf meinen Wunschpfad ändere (im Installer trage ich ja dann nur “DMXControl 3.3.0” ein) oder ich sage generell, dass der Installer bitte keine neuen Verknüpfungen anlegen soll - in beiden Fällen landen alle Verknüpfungen im Startmenü immer im “alten” Verzeichnis, also im Verzeichnis “DMXControl 3.2.3”.

Im Anhang die Log-Datei des Installers.

Bei der Bearbeitung des Tickets bitte beachten, dass im QRM22.1 grundlegende Anpassungen am Installer beschlossen wurden, welche bis zum Release auch umgesetzt werden sollen. Hierzu gehören unter anderem die Tickets FS#2763 und FS#4708.

Die Prüfung auf vorhandene Installation von .net 6 funktioniert nicht. Der Installer führt die Installation von .net 6 bei jedem Durchlauf des Setups von DMXC3 aus, obwohl .net 6 erst zuvor installiert wurde.

Anbei das Log des Installers.

Über das Tray-Menü des Launchers kann ich mit den Kernel und den Umbra nicht in den Vordergrund holen. Hierzu muss ich das Hauptfenster des Launchers direkt öffnen und die Einträge direkt umschalten.

Die direkte Verknüpfungen für GUI, Kernel und Umbra im Startmenü starten nur Launcher und holen diesen in Vordergrund, ohne jedoch die jeweils ausgewählte Anwendung auszuführen.

Die Verknüpfung für die GUI enthält folgende Angaben:

• Ziel:

  "C:\Program Files (x86)\DMXControl Projects\DMXControl 3.3.0\Launcher\DMXCLauncher.exe" --gui

• Ausführen in:

  "C:\Program Files (x86)\DMXControl Projects\DMXControl 3.3.0\GUI"

Das beigefügte Projekt habe ich unter DMXC 3.2.x erstellt und verschiedene Macroboard-Profile angelegt. Bedingt durch die Auslagerung in ein Plugin kann ich dieses nicht mehr laden. Es erscheint im Kernel der folgende Eintrag.

12:39:01 WARN  ProjectManager - Error when loading Project 2022-01-12 - Macroboard.dmz: Der Objektverweis wurde nicht auf eine Objektinstanz festgelegt.
System.NullReferenceException: Der Objektverweis wurde nicht auf eine Objektinstanz festgelegt.
   bei org.dmxc.lumos.Kernel.Input.Macroboard.MacroBoardManager.SelectProfile(String macroBoardID, String profileID, Boolean ignoreBoardNotExisting) in D:\Jenkins\workspace\Lumos_Pipeline_3.3\Lumos\src\Kernel\Input\MacroBoard\MacroBoardManager.cs:Zeile 338.
   bei org.dmxc.lumos.Kernel.Input.Macroboard.MacroBoardManager.org.dmxc.lumos.Kernel.Run.ILumosProjectManager.loadProject(LumosIOContext context, ELoadTime time) in D:\Jenkins\workspace\Lumos_Pipeline_3.3\Lumos\src\Kernel\Input\MacroBoard\MacroBoardManager.cs:Zeile 441.
   bei org.dmxc.lumos.Kernel.Project.ProjectManager.<>c__DisplayClass29_1.<loadProject>b__1(ILumosManager m) in D:\Jenkins\workspace\Lumos_Pipeline_3.3\Lumos\src\Kernel\Project\ProjectManager.cs:Zeile 337.
   bei System.Linq.Enumerable.All[TSource](IEnumerable`1 source, Func`2 predicate)
   bei org.dmxc.lumos.Kernel.Run.AbstractRunManager`2.DoManagerTopDown(Func`2 action) in D:\Jenkins\workspace\Lumos_Pipeline_3.3\LumosLIB\src\Kernel\Run\AbstractRunManager.cs:Zeile 142.
   bei org.dmxc.lumos.Kernel.Project.ProjectManager.loadProject(String filename, Stream inputStream, Boolean loadId, IProgress`1 progress) in D:\Jenkins\workspace\Lumos_Pipeline_3.3\Lumos\src\Kernel\Project\ProjectManager.cs:Zeile 333.

Ignoriere ich die zugehörige Fehlermeldung in der GUI, ist das Projekt gewissermaßen kaputt. Es fehlt nicht wie in anderen Fällen nur ein Element, in diesem Fall das Macroboard-Profil, sondern deutlich mehr.

Wenn ich aber die Datei MacroBoardProfiles.xml vor dem Laden aus dem Projekt entferne, kann gibt es keine Fehlermeldung. In diesem Fall kann ich aber dann das Macroboard-Profil neu anlegen und und die Buttons im Input Assignment neu zuordnen. Ist dies erledigt, lädt das auf diese Projekt nach dem Neustart der Sitzung wieder.

Das Projekt ist nur nach DMXC 3.3 importiert. Ansonsten gab es keine Veränderungen. Bei den Logfiles habe ich dieses Mal auch die des Installers beigefüpgt - nicht, dass eine Datei fehlt.

Im beigefügten Projekt habe ich die Buttons 1.7, 2.7 und 2.8 meines Streamdecks XL belegt. Schaue ich mir das Profil in der GUI selbst an, passt die Zuordnung. Auf dem Streamdeck passt die Zuordnung zwar auf der Eingangsseite. Auf der Ausgangsseite ist aber alles um einen Button nach links und einen Button nach oben verschoben. So erfolgt die eingestellte Ausgabe für den Button 2.8 auf dem Streamdeck tatsächlich auf dem Button 1.7.

Ergänze ich in dem Projekt ein zweites Macroboard-Profil und wechsle im Macroboard-Profile-Node manuell einmal zu diesem hin- und dann wieder zurück zum ersten, passt die Anzeige auf dem Streamdeck - bis ich anfange, die Tasten zu drücken. Dann sind wir wieder bei der Ausgangslage mit dem Offset.

Dieser Fehler ist höchstwahrscheinlich durch die Auslagerung der Macroboards in ein Plugin entstanden. In der Beta 1 hat noch alles wie gewünscht funktioniert.

Detaillierte Beschreibung folgt.

Ich habe in einem Projekt zwei Bänke mit unterschiedlichen Macro Board Profilen. Die nicht benötigte Bank ist dabei im Input Assignment deaktiviert. In jeder Bank gibt es ein Connectionset, wo ich die direkte Zuordnung zu meinem Stream Deck vornehme. So kann ich gedanklich nur durch das Deaktivieren der einen Bank und Aktivieren der anderen Bank direkt die Umschaltung der Zuordnung vornehmen und muss kein Conenctionset ändern. Dies habe ich in dem beigefügten Projekt so einmal nachgebaut. Lade ich das Projekt, erscheint im Kernel immer die folgende Fehlermeldung:

20:09:00 WARN  DuplexStreamHandler - Exception in Delegate Invocation: Void _getMacroBoardProfiles_RequestReceived(System.Object, org.dmxc.lumos.Kernel.Net.gService.RequestEventArgs`1[LumosProtobuf.GetMultipleRequest]) => org.dmxc.lumos.Kernel.Net.gService.MacroBoard_gService.Void _getMacroBoardProfiles_RequestReceived(System.Object, org.dmxc.lumos.Kernel.Net.gService.RequestEventArgs`1[LumosProtobuf.GetMultipleRequest])
System.InvalidOperationException: Object is currently in use elsewhere.
   at System.Drawing.Image.Save(Stream stream, ImageCodecInfo encoder, EncoderParameters encoderParams)
   at System.Drawing.Image.Save(Stream stream, ImageFormat format)
   at LumosLIB.GUI.Windows.PropertyGrid.SerializableBitmap.getArrayFromBitmap() in D:\Jenkins\workspace\Lumos_Pipeline_3.3\LumosLIB\src\GUI\Windows\PropertyGrid\SerializableBitmap.cs:line 112
   at LumosLIB.GUI.Windows.PropertyGrid.SerializableBitmap.get_SerializedBitmap() in D:\Jenkins\workspace\Lumos_Pipeline_3.3\LumosLIB\src\GUI\Windows\PropertyGrid\SerializableBitmap.cs:line 42
   at org.dmxc.lumos.Kernel.Devices.Descriptor.DescriptorTools.FromProfile(IMacroBoardProfile profile, IEnumerable`1 imagesToInclude, Boolean includeAllImages) in D:\Jenkins\workspace\Lumos_Pipeline_3.3\Lumos\src\Kernel\Devices\Descriptor\DescriptorTools.cs:line 0
   at org.dmxc.lumos.Kernel.Net.gService.MacroBoard_gService.<>c.<_getMacroBoardProfiles_RequestReceived>b__14_1(IMacroBoardProfile c) in D:\Jenkins\workspace\Lumos_Pipeline_3.3\Lumos\src\Kernel\Net\gService\MacroBoard_gService.cs:line 174
   at System.Linq.Enumerable.SelectIListIterator`2.MoveNext()
   at Google.Protobuf.Collections.RepeatedField`1.AddRange(IEnumerable`1 values)
   at org.dmxc.lumos.Kernel.Net.gService.MacroBoard_gService._getMacroBoardProfiles_RequestReceived(Object sender, RequestEventArgs`1 args) in D:\Jenkins\workspace\Lumos_Pipeline_3.3\Lumos\src\Kernel\Net\gService\MacroBoard_gService.cs:line 174
   at LumosToolsLIB.Tools.EventTools.<>c__DisplayClass4_0`1.<InvokeFailSafe>b__0(EventHandler`1 a) in D:\Jenkins\workspace\Lumos_Pipeline_3.3\LumosToolsLIB\src\Tools\EventTools.cs:line 67
   at LumosToolsLIB.Tools.EventTools.InvokeFailSaveGeneric[TDelegate](TDelegate delegate, Action`1 invoker, ILumosLog elog) in D:\Jenkins\workspace\Lumos_Pipeline_3.3\LumosToolsLIB\src\Tools\EventTools.cs:line 154

Neben dem Projekt sind anbei die Logs eines Zyklus DMXC starten, Projekt laden und wieder herunterfahren beigefügt.

Marcel hat eine neue Version der Nodle_USB.dll erstellt. Diese Anpassung muss in DMXControl 3 selbst noch entsprechend vorgenommen werden.

Die neue Version wird im Nodle Config Tool bereits verwendet.