Bugtracker DMXControl 3

Durch eine intensive und hochfrequente Beanspruchung des Kernels über einen MIDI-Controller ist dieser am Ende in einen Out-of-Memory-Fehler gelaufen und hat sich selbst beendet. Zuvor stockte die DMX-Ausgabe in zunehmender Intensität, während der Kernel versuchte den Arbeitspeicher freizuräumen.

Detaillierte Logs sowie ein Speicherabbild und ein Video sind intern zur Verfügung.

Speichere ich ein Preset ab, werden zuvor gehighlightete Geräte dunkel geschaltet. Das Problem lässt sich wie folgt reproduzieren:

1. RGB-Devices anlegen und auswählen.
2. Highlight aktivieren.
3. Eine beliebige Farbe im Device Control einstellen.
4. Ein neues Preset anlegen.

Das Ergebnis ist, dass die gewählten Geräte nicht mit gehighlightet sind, obwohl die Funktion aktiv ist. Dies ist deswegen verwunderlich, weil sich dieses Verhalten beim Anlegen einer regulären Cue nicht zeigt. Das Highlight für die gewählten Geräte bleibt weiter aktiv.

Können durch diverse Filter (voreingestellte Filter oder durch manuelle Textfilter aus Suchmaske) keine passenden Ergebnisse gefunden werden, soll hierauf durch einen Text wie “No results found” hingewiesen werden. Im Fall der Gobo List ist es aktuell so, dass dann man nur ein leeres Fenster sieht.

Werden die Adressen manuell vergeben und überschreitet ein Gerät hierbei die Grenze eines DMX-Universums, sollte eine Hinweismeldung ausgegeben werden.

Wie im beigefügten Beispiel zu sehen, wird das komplette Fenster nicht mit der gewählten Hintergrundfarbe ausgefüllt. Dabei ist es egal, ob ich mir das Softdesk im Window Modus oder im Fullscreen anzeigen lasse. In beiden Fällen erscheint am linken und unteren Rand der Standard-Hintergrund, sobald die Controls nur einen Teil des zur Verfügung stehenden Platzes ausfüllen.

Die Hintergrundfarbe des Softdesks kann nicht festgelegt werden. Im hellen Theme ist dieser standardmäßig in einem hellen Grau.

Manchmal könnte es hilfreich sein (insbesondere für Einsteiger), wenn über die Stage View ersichtlich ist, für welche Devices oder Device Groups Werte im Programmer werden. Und gerade, wenn man eine vorhandene Cue oder Preset ändert über den Befehl “Edit in Programmer”, wäre es gut zu sehen, welche Devices oder Device Groups man auswählen muss, damit man den Cue genau richtig ändert.

Dieses Highlighting könnte einfach so aussehen, dass die Icons grün hinterlegt werden.

Patche ich Geräte auf das 2. und folgende DMX-Universum und wähle diese in der Stage View aus, erfolgt das Highlighting des zugehörigen Adressbereichs in Channel Overview immer nur in der Ansicht für das erste DMX-Universum.

Analog zur globalen Highlight-Funktion soll die Highlight-Funktion im Position Mapping standardmäßig ebenfalls aus sein.

Füge ich verschiedene Radix-Geräte einem Projekt hinzu, zum Beispiel das DDF aus  FS#3573  oder die Vorlage-DDFs aus dem internen Testprojekt und wende Highlight auf diese Geräte an, bleiben die Geräte dunkel. Es wird zwar Dimmer und Shutter geöffnet, die Hightlight-Funktion setzt aber keine Werte auf den Farbkanälen, wie sie es bei Matrix-Geräten macht.

Meiner Meinung nach sollte überlegt werden, wie sich vor allem das Group Handling schneller erreichen lässt. Ich finde es ein richtig starkes Feature, was aber aktuell ein wenig zu sehr versteckt ist und deswegen beim produktiven Arbeiten über das Dropdown-Menü etwas umständlich zu erreichen ist. Überlegungen wären hier:

• Das Group Handling erhält einen eigenen Reiter innerhalb des Device Controls (neben den Reitern Properties und Effects).
• Für das Group Handling wird ein komplett separetes Fenster losgelöst vom Device Control geschaffen, sodass (genügend Bildschirmfläche vorausgesetzt) Group Handling und Device Control neben- oder untereinander angezeigt werden können.

Ich habe heute mal ein paar mehr Graphen angeschaut und bin dann wieder in die Tabellenansicht zurückgewechselt. Dabei ist mir aufgefallen, dass sich hierdurch der Anzeigebereich für die Tabelle jedes Mal ein Stück verkleinert.

Ganz schnell lässt sich dies reproduzieren, wenn man in einem leeren Projekt ein leeres Connectionset erzeugt und dann ein paar Mal mit dem Button “Show graph” / “Show table” zwischen den Ansichten wechselt. Nach 10 bis 15 Umschaltungen ist dann klein Platz mehr, um Inhalte in der Tabelle anzuzeigen.

Von meiner Sichtweise würde ich vermuten, dass der Auslöser der aktuell dreizeilige Button “Visible Collumns” ist, weil dieser die Höhe des Anzeigebereichs jedes Mal in dem Sinne ändert, weil die Menüleiste größer wird. Diese Größenänderung wirkt sich aber dauerhaft auf das Fenster aus und verringert so den Anzeigebereich für die Tabelle. Ich könnte mir daher vorstellen, dass das Phänomen mit der korrigierten Beschriftung des Buttons nicht mehr auftaucht, aber das Problem dürfte bestehen bleiben.

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.

Ich habe nach einigen anderen Arbeiten an dem in der Sitzung geladenen Projekt gegen 18:10 Uhr das Master-Fenster in den Vordergrund gerufen. Die Sitzung lief dabei seit rund vier Stunden. Beim Aufbau des Fensters hänge sich die GUI auf. Der Kernel und Umbra liefen weiter und nach dem Neustart der GUI konnte das Projekt “fortgesetzt” werden. Bei dem zweiten in den Vordergrund rufen des Master-Fensters wurde dieses ganz normal geladen.

Das Master-Fenster war Bestandteil des zuletzt geladenen Layouts des Projekts. Hierdurch war das Master-Fenster als weiterer Reiter in einem ausgedockten Fenster im Hintergrund geöffnet. Ich habe dieses Layout in beiden Fällen geladen.

Mehr durch Zufall musste ich feststellen, dass die GUI direkt beim Start mit dem folgenden Logeintrag abstürzt, wenn statt des 3.3er-Kernels der 3.2.3er-Kernel läuft. Auch wenn die Konstellation eher ungewöhnlich ist, sollte diese trotzdem keinen Absturz hervorrufen.

2023-01-07 20:22:54,057 [Main GUI] FATAL Lumos.GUI.Run.GuiRunManager - Unhandled Exception: Der Zugriff auf einen Socket war aufgrund der Zugriffsrechte des Sockets unzulässig
System.Net.Sockets.SocketException (0x80004005): Der Zugriff auf einen Socket war aufgrund der Zugriffsrechte des Sockets unzulässig
   bei System.Net.Sockets.Socket.DoBind(EndPoint endPointSnapshot, SocketAddress socketAddress)
   bei System.Net.Sockets.Socket.Bind(EndPoint localEP)
   bei LumosProtobuf.Udp.UdpListener.StartListen() in D:\Jenkins\workspace\Lumos_Pipeline_3.3\LumosProtobuf\src\UdpListener.cs:Zeile 41.
   bei LumosProtobuf.Udp.UmbraDiscoveryClient.StartDiscovery(IReadOnlyCollection`1 listenAdresses) in D:\Jenkins\workspace\Lumos_Pipeline_3.3\LumosProtobuf\src\UmbraDiscoveryClient.cs:Zeile 66.
   bei org.dmxc.lumos.Kernel.Net.AbstractGrpcManager.NetTools_NetworkChanged(Object sender, EventArgs e) in D:\Jenkins\workspace\Lumos_Pipeline_3.3\LumosLIB\src\Kernel\Net\AbstractGrpcManager.cs:Zeile 175.
   bei org.dmxc.lumos.Kernel.Net.AbstractGrpcManager.StartupFinished() in D:\Jenkins\workspace\Lumos_Pipeline_3.3\LumosLIB\src\Kernel\Net\AbstractGrpcManager.cs:Zeile 167.
   bei org.dmxc.lumos.Kernel.Run.AbstractRunManager`2.InformManagerStartupFinished(TManager m) in D:\Jenkins\workspace\Lumos_Pipeline_3.3\LumosLIB\src\Kernel\Run\AbstractRunManager.cs:Zeile 372.
   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.Run.AbstractRunManager`2.startManager() in D:\Jenkins\workspace\Lumos_Pipeline_3.3\LumosLIB\src\Kernel\Run\AbstractRunManager.cs:Zeile 340.
   bei Lumos.GUI.Run.GuiRunManager.startupGui() in D:\Jenkins\workspace\Lumos_Pipeline_3.3\LumosGUI\src\Run\GuiRunManager.cs:Zeile 62.
   bei Lumos.GUI.Program.runGui() in D:\Jenkins\workspace\Lumos_Pipeline_3.3\LumosGUI\src\Program.cs:Zeile 194.
   bei Lumos.GUI.Program.Main(String[] param) in D:\Jenkins\workspace\Lumos_Pipeline_3.3\LumosGUI\src\Program.cs:Zeile 160.

Reproduzieren lässt sich dies, in dem ich den 3.2.3er Kernel manuell starte und dann Umbra und GUI über den Launcher aufrufe.

Mit dem beigefügten Projekt habe ich eine einfache Ansteuerung der Position von in der Stage View ausgewählten Geräten über meinen MIDI-Controller (Traktor F1) realisiert. Bei schnellen, ruckartigen Werteänderungen stockt GUI bis hin zum Einfrieren. Das Stocken betrifft im konkreten Fall unter anderem das Position Control und das Device Control. Hier liegt bei mir die Vermutung nahe, dass bei einer meiner letzten Nutzung im größeren Umfeld deswegen die GUI auch komplett abgestürzt ist. Der gezeigte Auszug aus den beigefügten Logs entstammt der ersten GUI-Session.

2023-09-15 18:44:42,258 [74] FATAL Lumos.GUI.Run.GuiRunManager - Unhandled Exception: Der Objektverweis wurde nicht auf eine Objektinstanz festgelegt.
System.NullReferenceException: Der Objektverweis wurde nicht auf eine Objektinstanz festgelegt.
   bei Lumos.GUI.Facade.DeviceProperties.DevicePropertyFacade.<OnProgrammerValueChanged>d__71.MoveNext() in D:\Jenkins\workspace\Lumos_Pipeline_3.3\LumosGUI\src\Facade\DeviceProperties\DevicePropertyFacade.cs:Zeile 516.
--- Ende der Stapelüberwachung vom vorhergehenden Ort, an dem die Ausnahme ausgelöst wurde ---
   bei System.Runtime.CompilerServices.AsyncMethodBuilderCore.<>c.<ThrowAsync>b__6_1(Object state)
   bei System.Threading.QueueUserWorkItemCallback.WaitCallback_Context(Object state)
   bei System.Threading.ExecutionContext.RunInternal(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx)
   bei System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx)
   bei System.Threading.QueueUserWorkItemCallback.System.Threading.IThreadPoolWorkItem.ExecuteWorkItem()
   bei System.Threading.ThreadPoolWorkQueue.Dispatch()
   bei System.Threading._ThreadPoolWaitCallback.PerformWaitCallback()

Nutze ich im gleichen Connectionset statt die Fader / Encoder meines MIDI-Controllers die beiden Slider des ebenfalls enthaltenen Softdesks, werden alle Werteänderungen sauber umgesetzt. Sowohl langsame als auch schlagartige Werteänderungen kommen nahezu verzögerungsfrei im Position Control und im Device Control an.

Nutze ich das im Anhang beigefügte DDF, hängt sich die GUI komplett auf, sobald ich den Dialog Add Device schließe. Ersetze ich den vom Kernel bemängelten Code

<ptspeed dmxchannel="8">
  <step type="linear" mindmx="255" maxdmx="0" minval="0" maxval="255" />
</ptspeed>

durch den folgenden, korrigierten Code

<ptspeed dmxchannel="8">
  <range type="linear" mindmx="0" maxdmx="255" minval="100" maxval="0" />
</ptspeed>

lässt sich das DDF ganz regulär hinzufügen und auch die GUI arbeitet ohne Probleme weiter.

Die Logs bis zum Zeitpunkt des Aufhängens der GUI sind ebenfalls beigefügt.

Wenn ich ein beliebiges Projekt schließe, dann crasht jedes Mal die GUI. Dabei spielt es keine Rolle, ob es ein bereits gefülltes Projekt ist, oder wie beigefügt, ein neues und komplett leeres Projekt.

Es gibt zwar ein weiteres Ticket mit einem vergleichbaren Titel unter der Nummer  FS#4986 , allerdings konnte ich das Problem seiner Zeit nicht nachstellen. Außerdem ist der Punkt nun bei mir in der aktuellen Version erst neu aufgetreten.

Im Anhang die Log-Dateien sowie das Projekt.

Ich gebe in die Kommandozeile (Commandline) folgenden Befehl ein:

select executorpage 2 item 6

Die Kommandozeile führt den Teil “select executorpage 2” zwar aus, der Teil “item 6” ist nicht implementiert und liefert kein Ergebnis. Der Befehl wird aber in Gänze mit grün als erfolgreich ausgeführt gekennzeichnet.

Analog zu den Submastern in DMXControl 2 bzw. den Executoren könnte ich mir vorstellen, dass eine Flash-Funktion für die Groupmaster eine nette Ergänzung wäre. Besonders gut kommt dies zur Geltung, wenn der MIDI-Controller Encoder mit Drucktaster verbaut hat.

Diese Funktion bräuchte im ersten Schritt nur im Input Assignment verfügbar sein.

Zur Prüfung des Installers nach den umfangreichen Änderungen habe ich mir auch mal ein paar Projekte angesehen. Dabei ist mir das Problem unter die Finger gekommen, dass im Build 142 die Graphen des Input Assignments nicht gespeichert werden können. Welches Projekt man dabei nimmt, ist vollkommen egal.

Der Fehler lässt sich reproduzieren, wenn man zum Beispiel ein Cuelist- oder ein Macroboard-Node in ein Connectionset schmeißt und dieses Projekt dann speichern will. Dann spuckt der Kernel folgende Fehlermeldung aus:

17:14:53 WARN  ResourceManager - Unable to save Resource Graphs.xml of Type Project
System.InvalidOperationException: 'org.dmxc.lumos.Kernel.Input.v2.NameNumberIDValue' kann nicht serialisiert werden, weil dafür kein parameterloser Konstruktor verfügbar ist.
   bei System.Xml.Serialization.TypeDesc.CheckSupported()
   bei System.Xml.Serialization.TypeScope.GetTypeDesc(Type type, MemberInfo source, Boolean directReference, Boolean throwOnError)
   bei System.Xml.Serialization.ModelScope.GetTypeModel(Type type, Boolean directReference)
   bei System.Xml.Serialization.XmlReflectionImporter.ImportTypeMapping(Type type, XmlRootAttribute root, String defaultNamespace)
   bei System.Xml.Serialization.XmlSerializer..ctor(Type type, String defaultNamespace)
   bei org.dmxc.lumos.Kernel.Resource.Xml2ManagedTreeConverter.GenerateData(String name, Object value, XmlDocument dest) in D:\Jenkins\workspace\Lumos_Pipeline_3.3\LumosLIB\src\Kernel\Resource\Xml2ManagedTreeConverter.cs:Zeile 390.
   bei org.dmxc.lumos.Kernel.Resource.Xml2ManagedTreeConverter.GenerateData(ManagedTreeItem item, XmlDocument dest) in D:\Jenkins\workspace\Lumos_Pipeline_3.3\LumosLIB\src\Kernel\Resource\Xml2ManagedTreeConverter.cs:Zeile 311.
   bei org.dmxc.lumos.Kernel.Resource.Xml2ManagedTreeConverter.GenerateData(ManagedTreeItem item, XmlDocument dest) in D:\Jenkins\workspace\Lumos_Pipeline_3.3\LumosLIB\src\Kernel\Resource\Xml2ManagedTreeConverter.cs:Zeile 317.
   bei org.dmxc.lumos.Kernel.Resource.Xml2ManagedTreeConverter.GenerateData(ManagedTreeItem item, XmlDocument dest) in D:\Jenkins\workspace\Lumos_Pipeline_3.3\LumosLIB\src\Kernel\Resource\Xml2ManagedTreeConverter.cs:Zeile 317.
   bei org.dmxc.lumos.Kernel.Resource.Xml2ManagedTreeConverter.GenerateData(ManagedTreeItem item, XmlDocument dest) in D:\Jenkins\workspace\Lumos_Pipeline_3.3\LumosLIB\src\Kernel\Resource\Xml2ManagedTreeConverter.cs:Zeile 317.
   bei org.dmxc.lumos.Kernel.Resource.Xml2ManagedTreeConverter.GenerateData(ManagedTreeItem item, XmlDocument dest) in D:\Jenkins\workspace\Lumos_Pipeline_3.3\LumosLIB\src\Kernel\Resource\Xml2ManagedTreeConverter.cs:Zeile 317.
   bei org.dmxc.lumos.Kernel.Resource.Xml2ManagedTreeConverter.GenerateData(ManagedTreeItem item) in D:\Jenkins\workspace\Lumos_Pipeline_3.3\LumosLIB\src\Kernel\Resource\Xml2ManagedTreeConverter.cs:Zeile 294.
   bei org.dmxc.lumos.Kernel.Resource.Datastore.FileBackendDatastore.SaveResource(EResourceType type, LumosResource data, IProgress`1 progress) in D:\Jenkins\workspace\Lumos_Pipeline_3.3\Lumos\src\Kernel\Resource\Datastore\FileBackendDatastore.cs:Zeile 480.
   bei org.dmxc.lumos.Kernel.Resource.ResourceManager.SaveResourceInternalAsync(EResourceType type, LumosResource data, IProgress`1 progress) in D:\Jenkins\workspace\Lumos_Pipeline_3.3\Lumos\src\Kernel\Resource\ResourceManager.cs:Zeile 219.
   bei org.dmxc.lumos.Kernel.Resource.AbstractResourceManager.<SaveResourceAsync>d__86.MoveNext() in D:\Jenkins\workspace\Lumos_Pipeline_3.3\LumosLIB\src\Kernel\Resource\AbstractResourceManager.cs:Zeile 732.

Ein neues Testprojekt kann ich auf Grund der Art des Fehlers nicht beifügen. Daher verweise ich auf mein zuletzt für das Ticket  FS#4856  erstelle Projekt.

Da dieses Problem sich aus meiner Sicht unmittelbar als Testblocker herauskristallisieren würde, habe ich mich entschlossen, ausnahmsweise ein Ticket für eine Zwischenversion zu schreiben.

Wenn ich eine neue Gobo Affinity sowohl in einem neuen, leeren Projekt als auch in einem Projekt mit bereits gepatchten Geräten erstelle und hierzu das zu Grunde liegende Gobo auswählen möchte, so wird in dem Auswahlfenster kein Inhalt angezeigt - egal ob der Halen “Included in project” gesetzt ist oder nicht oder ob ich etwas in das Suchfeld eintrage.

Das zusammenstellen der Gobos für eine Goboliste funktioniert dagegen. Dort werden die verfügbaren Gobos angezeigt.

Im Anhang habe ich die Logfiles beigefügt, die den Punkt für ein leeres Projekt protokollieren.

Es sollte besser visualisiert werden, dass man das Gobo auch ändern kann, welches für die jeweilige Gobo Affinity als Bezug herangezogen wird. Aktuell muss man es wissen, dass sich das Gobo Selecotor Window bei einem Klick auf das Gobo erneut öffnet und man folglich keine neue Gobo Affintiy erstellen muss, sollte man ein anderes Gobo benötigen.

Im Gobo Affinity Window soll man auf das Bild des Gobos klicken können, um ein anderes Gobo auszuwählen, was entsprechend der Gobo List ersetzt wird. Dies ist aktuell nicht mölglich.

Im Rahmen einer Rückfrage im Forum erinnere ich mich gerade an eine tolle Sache, die DMXControl 2 beim Beenden der Software besser oder anders macht, als DMXControl 3. Gibt DMXControl 2 nämlich DMX-Werte aus, so bleiben diese im Interface auch noch nach dem Beenden von DMXControl 2 im Interface gesetzt. DMXControl 3 arbeitet hier anders und überschreibt beim Beenden des Kernels alle zuvor gesetzten DMX-Werte mit 0.

In meinen Club-Projekten kann ich dank der Arbeitsweise von DMXControl 2 zum einen den PC nach Feierabend schon vorzeitig herunterfahren, während ein Teil der Scheinwerfer noch als “Putzlicht” eingeschaltet bleibt. Ein zweiter Vorteil ist, dass im Falle eines Neustarts des PCs während der Veranstaltung das Effektlicht während des Neustarts des PCs im letzten Zustand verharrt und die Tanzfläche erst mit dem erneuten Starten von DMXControl 2 kurzzeitig dunkel wird.

Dieses Feature soll mit Hilfe der Freeze-Funktion realisiert werden. Ist diese aktiviert und DMXControl 3 wird beendet, bleiben die eingefrorenen DMX-Werte erhalten, auch wenn der Kernel geschlossen ist. Somit kann universell und leicht zugänglich die Einstellung situationsabhängig gesetzt werden. Für Anwender, die diese Funktion dauerhaft benötigten, wird in den Applications Settings der Eintrag “Freete on exit” für den Kernel mit den Einstellmöglichkeiten “true” oder “false” hinzugefügt.

Ich habe mit der Alpha 7 ein neues Projekt erstellt. Wenn ich dieses speichere, schließe und sowohl innerhalb der laufenden Sitzung als auch nach einem kompletten Neustart von DMXC, kann ich im Anschluss die Namen der Geräte und Gerätegruppen nicht mehr ändern. Der Zweig im Projekt Explorer aktualisiert sich nicht. Aktualisiere ich den Baum durch öffnen eines anderen Ordners oder mittels des Refresh-Buttons, ist der alte Name wieder da. Ändere ich den Namen über die Properties, hängt sich die GUI auf, sodass ich sie hart beenden muss.

Möchte ich Geräte in einen eigenen Ordner verschieben, denen ein Subdevice zugeordnet ist, so lässt DMXControl dieses nicht zu.

Umfasst ein Projekt eine größere Anzahl an Connectionsets, führen diese dazu, dass beim reinen Öffnen des Fenster für das Input Assignments die CPU-Auslastung durch die Prozesse des Kernels und der GUI ca. um den Faktor 2 ansteigt, verbunden mit einer Erhöhung der durchschnittlichen Taktfrequenz von Werten zwischen 1,00 GHz und 1,15 GHz auf Werte zwischen 2,20 GHz und 2,60 GHz (Angaben gemäß Windows Task-Manager). Weitere Aktionen finden zu diesem Zeitpunkt nicht statt. Welche Fenster geöffnet sind, kann den beigefügten Screenshots entnommen werden.

Dieses Verhalten zeigt sich auf verschiedenen PCs, wobei einer hiervon erst kürzlich von Grund auf neu eingerichtet wurde. In diesem arbeitet ein Intel Core i5-4590S mit 4 x 3,00 GHz.

Ich steuere über das Softdesk immer bei zahlreichen Cuelists gemeinsam die Intensität, den Fade Factor und Speed Factor oder Slider an. Die zugehörigen Cuelists liegen meist auch in einer Cuelist Group. Bis dato muss ich aber diesen Slider immer pro Cuelist verdrahten, sodass ich ihn beispielsweise bei 10 Connectionsets für 10 verschiedene Cuelists einbinden muss.

Hier würde ich mir eine Möglichkeit wünschen, dass ich diese drei Werte über eine zentrale Stelle an die Cuelists übergeben kann, natürlich vorzugsweise über bereits vorhandene Nodes.

In gewissen Situationen habe ich gleich mehrere Cuelists, die ich gemeinsam live manipulieren möchte, wie unter anderem Timing (Fade Factor), Effect speed, Limit, Temp. Aktuell muss ich hierzu entsprechend viele Executoren anlegen, kann aber dann die Werte immer noch nicht für mehrere Cuelists gemeinsam setzen.

Um dies zu ermöglichen kamen mir hier zwei mögliche Ansätze in den Sinn:

• Es wird ein neuer Executor-Typ “Cuelist Group” eingeführt. Für alle in dieser Cuelist Group enthaltenen Cuelists kann man dann gemeinsam alle verfügbaren Werte gemeinsam ansprechen. Zusätzlich erhält man Zugriff auf die Funktionen wie “Alle starten” oder “Alle stoppen”, die das Cuelist Group Node bereits anbietet. Dieser Ansatz würde dann auch zu dem Ticket  FS#4325  passen, die genannten Funktionen auch im Node direkt hinzuzufügen.
• Man kann einem Executor mehrere Elemente zuordnen. An dieser Stelle würde es dann ggf. keine Differenzierung geben, dass es bei den Cuelists erlaubt ist, bei den verschiedenen Mastern aber nicht.

Lösche ich ein Softdesk-Control, bleibt dieses bis zum Neuladen des Projekts im Input Assignment enthalten. Erst danach (also mit dem Neuladen des Projekts) wird der Eintrag entfernt.

Entsprechende Logfiles sind beigefügt.

Ich habe ein Softdesk mit mehreren Controls angelegt. Von diesen habe wiederum einige gelöscht und den Softdesk Designer geschlossen. Speichere und schließe ich das Projekt und lade ein neues, bleibt das gelöschte Softdesk Control noch im Input Assignment erhalten, wie im beigefügten Screenshot zu sehen.

Da ich das Problem nicht direkt im gleichen Kontext wie Ticket  FS#4577  sehe, habe ich dieses neue Ticket erstellt.

Im Anhang findet sich das Projekt sowie die Logs der Sitzung.

Ä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.

Ändere ich für ein Device die Default Color, so wird die neue Farbe zwar direkt richtig im Device Control und im Color Picker wiedergegeben, jedoch nicht in der Stage View. hier bleibt die Farbe weiterhin weiß.

Dieses Gerät (und weitere) besitzt mehrere Modus-Kanäle, welche das

• Farbrad (DMX-Kanal 11), Modus über DMX-Kanal 10
• rotierendes Goborad (DMX-Kanal 13), Modus über DMX-Kanal 12
• Goborotation (DMX-Kanal 15), Modus über DMX-Kanal 14
• statisches Goborad (DMX-Kanal 17), Modus über DMX-Kanal 16
• Iris (DMX-Kanal 23), Modus / Effekt über DMX-Kanal 17

unterschiedlich arbeiten lassen. Das heißt abhängig vom gewählten Modus ändert sich die Belegung der zuvor genannten Kanäle. Bei der Iris könnte man an dieser Stelle vielleicht analog zum strobetype arbeiten, da hier nur der Effekt geändert wird.

Aktuell kann zum Beispiel die Richtung der Goborotation nur über einen rawstep angewählt werden.

Im Anhang das DDF für den Extend-Modus sowie die Basic 16bit-Modus sowie die Bedienungsanleitung.

Getestet mit Build 1519

Wir steigern uns: Im Kontextmenü der Stage View gibt es den Eintrag “Add Device” nun gleich fünf Mal.