Bugtracker DMXControl 3

Der Installer liefert die Datei libartnet-1.dll möglicherweise im falschen Verzeichnis aus, welche gemäß der Logs aber für das Art-Net-Ausgabeplugin benötigt wird.

2019-03-16 19:13:55,326 [19] ERROR org.dmxc.lumos.Kernel.Plugin.AbstractPluginManager+DMXInterfaceBag - Error setting interface DMXIM: ID Artistic License#ArtNet#0 enabled state to True:
System.DllNotFoundException: Die DLL "libartnet-1.dll": Das angegebene Modul wurde nicht gefunden. (Ausnahme von HRESULT: 0x8007007E) kann nicht geladen werden.
   bei org.dmxc.lumos.Kernel.DMX.ArtNetWrapper.artnet_new(String ip, Int32 verbose)
   bei org.dmxc.lumos.Kernel.DMX.ArtNetInterface.OnEnable() in D:\Jenkins\workspace\Lumos_3.2_Release\DMXPlugins\ArtisticLicenseArtNet\src\ArtNet.cs:Zeile 180.
   bei DMXLIB.AbstractDMXInterface.set_Enabled(Boolean value) in D:\Jenkins\workspace\Lumos_3.2_Release\Lumos\DMXLIB\AbstractDMXInterface.cs:Zeile 91.
   bei org.dmxc.lumos.Kernel.Plugin.AbstractPluginManager.DMXInterfaceBag.SetEnabledInternal(Boolean state) in D:\Jenkins\workspace\Lumos_3.2_Release\Lumos\LumosLIB\src\Kernel\Plugin\DMXInterfaceBag.cs:Zeile 226.
2019-03-16 19:14:17,088 [Log-Thread] DEBUG org.dmxc.lumos.SceneFadeTicker - Registriere: org.dmxc.lumos.Kernel.SceneList.ValuesStack.OutputValuesStack
2019-03-16 19:14:17,123 [Main-Process-Chain] ERROR org.dmxc.lumos.Kernel.Plugin.PluginManager - Exception DllNotFoundException occured 20 times.

Gemäß Installer-Log liegt die Datei in folgendem Verzeichnis:

Zielverzeichnis: C:\Program Files (x86)\DMXControl Projects\DMXControl 3.2\Kernel\Plugins\api-dlls
Wird entpackt: libartnet-1.dll... 100%

Füge ich das Art-Net-Ausgabeplugin neu hinzu, werden die Send- und Recieve-Universen aus meiner Sicht ungünstig adressiert. Im konkreten sieht das wie folgt aus:

Device 1

• Send U1 - U4: Universes 0 - 3
• Revice U1 - U4: Universes 4 - 7

Device 2

• Send U5 - U7: Universes 8 - 11
• Revice U5 - U7: Universes 12 - 15

Möchte ich nun ein 8-Port Art-Net-Node ansprechen, muss ich hier im Device 2 mindestens die Universen für Send neu sortieren. Ich könnte zwar mein Art-Net-Node auch irgendwie umkonfigurieren, aber persönlich finde ich diese Stückelung innerhalb eines Subnet nicht geschickt. Mein erster Vorschlag wäre folgende Standard-Konfiguration:

Device 1

• Send U1 - U4: Universes 0 - 3
• Revice U1 - U4: Universes 8 - 11

Device 2

• Send U5 - U7: Universes 4 - 7
• Revice U5 - U7: Universes 12 - 15

Aktuell ist keine Ausgabe über das “neue” Art-Net-Ausgabeplugin möglich.

Beim Start des Kernels gibt es folgenden Eintrag:

23:29:31 WARN  AssemblyManager - Unable to remove Zone.Identifier from File C:\Program Files (x86)\DMXControl Projects\DMXControl 3.3.0\Kernel\Plugins\ArtisticLicenseArtNet.dll
System.UnauthorizedAccessException: Access to the path 'C:\Program Files (x86)\DMXControl Projects\DMXControl 3.3.0\Kernel\Plugins\ArtisticLicenseArtNet.dll:Zone.Identifier:$DATA' was denied.
   bei Trinet.Core.IO.Ntfs.SafeNativeMethods.ThrowIOError(Int32 errorCode, String path)
   bei Trinet.Core.IO.Ntfs.SafeNativeMethods.ThrowLastIOError(String path)
   bei Trinet.Core.IO.Ntfs.SafeNativeMethods.SafeDeleteFile(String name)
   bei Trinet.Core.IO.Ntfs.AlternateDataStreamInfo.Delete()
   bei org.dmxc.lumos.Kernel.AssemblyScan.AbstractAssemblyManager.TryRemoveZoneIdentifierIfExisting(String file) in D:\Jenkins\workspace\Lumos_Pipeline_master_2\LumosLIB\src\Kernel\AssemblyScan\AbstractAssemblyManager.cs:Zeile 436.

Sobald ich das Plugin deaktiviere, erscheint der folgende Log-Eintrag:

23:31:52 ERROR ArtNetFactory -
System.ObjectDisposedException: Auf das verworfene Objekt kann nicht zugegriffen werden.
Objektname: "System.Net.Sockets.Socket".
   bei System.Net.Sockets.Socket.EndReceiveFrom(IAsyncResult asyncResult, EndPoint& endPoint)
   bei System.Net.Sockets.UdpClient.EndReceive(IAsyncResult asyncResult, IPEndPoint& remoteEP)
   bei org.dmxc.lumos.Kernel.DMX.ArtNetManager.client_receive(IAsyncResult res) in D:\Jenkins\workspace\mos_DMXPlugins_Pipeline_master_2\ArtisticLicenseArtNet\src\ArtNetManager.cs:Zeile 704.

Im Anhang befinden sich die Logs einer Sitzung sowie die Konfiguration des ausgeschalteten Plugings.

Sobald ich das Art-Net-Plugin selbst manuell abschalte oder der Kernel es beim Herunterfahren automatisch abschaltet, erscheint im Log immer der folgende Eintrag.

17:51:13 ERROR ArtNetFactory -
System.ObjectDisposedException: Auf das verworfene Objekt kann nicht zugegriffen werden.
Objektname: "System.Net.Sockets.Socket".
   bei System.Net.Sockets.Socket.EndReceiveFrom(IAsyncResult asyncResult, EndPoint& endPoint)
   bei System.Net.Sockets.UdpClient.EndReceive(IAsyncResult asyncResult, IPEndPoint& remoteEP)
   bei org.dmxc.lumos.Kernel.DMX.ArtNetManager.client_receive(IAsyncResult res) in D:\Jenkins\workspace\mos_DMXPlugins_Pipeline_master_2\ArtisticLicenseArtNet\src\ArtNetManager.cs:Zeile 704.

Aktiviere ich es danach wieder, arbeitet es soweit auch wie erwartet. Die Meldung erweckt jedoch gerade beim Überprüfen der Einstellungen den Eindruck, als ob etwas kaputt ist.

Deaktiviere ich die DMX-Interfaces über den Main-Switch, fliegt im Kernel die folgende Exception

20:54:46 ERROR DMXInterfaceBag - Error setting interface Serial: ArtNet, Model: Art-Net, Vendor: Artistic License enabled state to False:
System.ArgumentOutOfRangeException: Index was out of range. Must be non-negative and less than the size of the collection. (Parameter 'index')
   at System.Collections.Generic.List`1.Remove(T item)
   at org.dmxc.lumos.Kernel.DMX.ArtNetManager.RemovePort(ArtNetInterface port) in D:\Jenkins\workspace\Lumos_DMXPlugins_Pipeline_3.3\ArtisticLicenseArtNet\src\ArtNetManager.cs:line 147
   at org.dmxc.lumos.Kernel.DMX.ArtNetInterface.OnDisable() in D:\Jenkins\workspace\Lumos_DMXPlugins_Pipeline_3.3\ArtisticLicenseArtNet\src\ArtNet.cs:line 150
   at DMXLIB.AbstractDMXInterface.set_Enabled(Boolean value)
   at DMXInterfaceMgmtLIB.DMXInterfaceBag.SetEnabledInternal(Boolean target, Boolean byHeartbeatRestart, Boolean byMainSwitch) in D:\Jenkins\workspace\Lumos_Pipeline_3.3\DMXInterfaceMgmtLIB\DMXInterfaceBag.cs:line 267

Waren die DMX-Interfaces eine Zeit lang aktiv und werden dann über den Main-Switch abgeschaltet, meldet der Kernel wiederkehrend folgende Exception. Es ändert daran auch nichts, dass ich die DMX-Interfaces über den Main-Switch wieder einschalte.

21:41:15 ERROR ArtNetFactory -
System.NullReferenceException: Object reference not set to an instance of an object.
   at org.dmxc.lumos.Kernel.DMX.ArtNetManager.ProcessArtPoll(Byte[] packet, IPEndPoint receivedFrom) in D:\Jenkins\workspace\Lumos_DMXPlugins_Pipeline_3.3\ArtisticLicenseArtNet\src\ArtNetManager.cs:line 667
   at org.dmxc.lumos.Kernel.DMX.ArtNetManager.client_receive(IAsyncResult res) in D:\Jenkins\workspace\Lumos_DMXPlugins_Pipeline_3.3\ArtisticLicenseArtNet\src\ArtNetManager.cs:line 833
21:41:18 ERROR ArtNetFactory -
System.NullReferenceException: Object reference not set to an instance of an object.
   at org.dmxc.lumos.Kernel.DMX.ArtNetManager.ProcessArtPoll(Byte[] packet, IPEndPoint receivedFrom) in D:\Jenkins\workspace\Lumos_DMXPlugins_Pipeline_3.3\ArtisticLicenseArtNet\src\ArtNetManager.cs:line 667
   at org.dmxc.lumos.Kernel.DMX.ArtNetManager.client_receive(IAsyncResult res) in D:\Jenkins\workspace\Lumos_DMXPlugins_Pipeline_3.3\ArtisticLicenseArtNet\src\ArtNetManager.cs:line 833
21:41:20 ERROR ArtNetFactory -
System.NullReferenceException: Object reference not set to an instance of an object.
   at org.dmxc.lumos.Kernel.DMX.ArtNetManager.ProcessArtPoll(Byte[] packet, IPEndPoint receivedFrom) in D:\Jenkins\workspace\Lumos_DMXPlugins_Pipeline_3.3\ArtisticLicenseArtNet\src\ArtNetManager.cs:line 667
   at org.dmxc.lumos.Kernel.DMX.ArtNetManager.client_receive(IAsyncResult res) in D:\Jenkins\workspace\Lumos_DMXPlugins_Pipeline_3.3\ArtisticLicenseArtNet\src\ArtNetManager.cs:line 833
21:41:23 ERROR ArtNetFactory -
System.NullReferenceException: Object reference not set to an instance of an object.
   at org.dmxc.lumos.Kernel.DMX.ArtNetManager.ProcessArtPoll(Byte[] packet, IPEndPoint receivedFrom) in D:\Jenkins\workspace\Lumos_DMXPlugins_Pipeline_3.3\ArtisticLicenseArtNet\src\ArtNetManager.cs:line 667
   at org.dmxc.lumos.Kernel.DMX.ArtNetManager.client_receive(IAsyncResult res) in D:\Jenkins\workspace\Lumos_DMXPlugins_Pipeline_3.3\ArtisticLicenseArtNet\src\ArtNetManager.cs:line 833

Ob es einen Zusammenhang zum Ticket  FS#5326  gibt, vermag ich nicht zu beurteilen. Deswegen habe ich dieses separate Ticket angelegt. Im Anhang finden sich die Logdateien, woraus der Zeitraum hervorgeht, wo ich den Main-Switch betätigt habe. Die Logs enthalten auch die DMX-Interface-Konfiguration.

Das Art-Net-4-Plugin kann beim Start des Kernels nicht initialisiert werden mit folgender Meldung im Kernel:

19:24:14 ERROR AssemblyManager - Unhandled Exception when loading Types in Listener org.dmxc.lumos.Kernel.Plugin.PluginManager: Unable to load one or more of the requested types.
Could not load file or assembly 'System.Runtime, Version=8.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'. Das System kann die angegebene Datei nicht finden.

Datenstand ist das Beta-Paket aus dem Forum vom 04.12.2024 und auch den letzten Jenkins-Jobs.

Ticket wurde nach Rücksprache von @JPK nun nochmal hierher übernommen und dient vornehmlich als Reminder.

Ich nutze auf zwei Laptops die Art-Net 4 Ausgabe. In beiden Laptops habe ich die gleiche Art-Net-Konfiguration, um zwischen beiden Laptops teilweise oder auch vollständig wechseln zu können.

Wenn ich die Art-Net- / DMX-Ausgabe an den drei möglichen Stellen einzeln oder auch an allen drei Stellen komplett ausschalte, wird die Art-Net-Ausgabe nict komplett abgeschaltet. Dies mündet folglich in Störungen auf dem DMX-Bus, wenn ein anderer Laptop den Port des Art-Net-Nodes “übernehmen” soll. Die Lösung war hier das Treffen der Netzwerkverbindung zu den Art-Net-Nodes.

Mit der alten Art-Net-Ausgabe (in DMXControl 3.3.1) konnte ich den Wechsel noch ohne Probleme durchführen und eben auch die Art-Net-Ausgabe vollständig abschalten.

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.

Es braucht einen automatischen Zeilenumbruch für “große” Befehle und / oder Kommentare.

Siehe oben

Der folgende Log-Eintrag taucht beim Starten des Kernels regelmäßig auf:

2019-04-09 22:11:39,807 [Main] WARN  org.dmxc.lumos.Kernel.Plugin.PluginManager - Timeout when fetching Interface List from DMX Interface Factory Enttec
System.TimeoutException: Timeout für den Vorgang wurde überschritten.
   bei DMXLIB.FactoryTimeoutDecorator.get_Interfaces() in D:\Jenkins\workspace\Lumos_3.2_Release\Lumos\DMXLIB\FactoryTimeoutDecorator.cs:Zeile 105.
   bei org.dmxc.lumos.Kernel.Plugin.AbstractPluginManager.loadInterfaces(IDMXInterfaceFactory factory) in D:\Jenkins\workspace\Lumos_3.2_Release\Lumos\LumosLIB\src\Kernel\Plugin\AbstractPluginManager.cs:Zeile 1246.

Füge ich das Ausgabeplugin für EasyView hinzu, um darüber EasyView direkt anzusprechen, wird die Konfiguration zwar ordungsgemäß gespeichert, beim (erneuten) Starten von DMXControl 3 - egal ob Kernel und GUI getrennt oder im NoNetwork-Modus - wird EasyView nicht automatisch mit gestartet. Rufe ich EasyView im Nachgang manuell auf, verbleibt EasyView im Demo-Mode.

Verschiedene DMX-Interfaces, wie zum Beispiel das Nodle U1 oder das Nodle R4S werden nach dem Beenden des Kernels nicht automatisch abgeschaltet, wenn diese zuvor aktiv waren. Die Status-LEDs gehen nicht aus.

Ich lege ein neues Art-Net-Interface an oder aktiviere ein ggf. vorhandenes (wieder). In beiden Fällen erscheint im Kernel nach einigen Aktionen in der Stage View die folgende Fehlermeldung:

19:55:34 FATAL MainProcessRunable - Main Runnable seams stuck in an endless loop! You might have to restart DMXC... Please report this!

Sobald diese Fehlermeldung erscheint, kann ich in der GUI war Geräte in der Stage View auswählen. Setze ich aber die Farbe auf einer Gerätegruppe, werden diese Werte nicht mehr von den einzelnen Geräten wiedergegeben. Das Herunterfahren des Kernels klappt dann auch nicht mehr, da dieser keine Kommandos mehr entgegen nimmt.

Die beigefügten Logs zeigen den Ablauf:

1. DMXC 3.3.0 RC4 starten ohne zuvor konfigurierte DMX-Interfaces
2. Beliebiges Projekt laden
3. Art-Net-Interfaces einrichten
4. Ein paar einfache Aktionen in der Stage View
5. Auftauchen des Fehlers
6. Schließen der GUI und manuelles Anstoßen des Beenden des Umbras
7. Hartes Schließen des Kernels

In den Einstellungen für die Executor-Seiten kann ich festlegen, wie viele Executoren ist pro Seite nutzen möchte. Dieser Wert wird jedoch ignoriert. Egal welchen Wert ich einstelle, es werden grundsätzlich acht Executoren pro Seite angelegt.

Auf das Ticket  FS#4647  aufbauend ist es bei einer bereits angelegten Executor-Seite nicht mehr möglich, die Anzahl der Executoren zu ändern. Die angebotene Option in den Einstellungen für die Seite wird nicht berücksichtigt.

Man kann in den Einstellungen der Executoren festlegen, dass ein Fader und Buttons nicht belegt sind. In diesem Fall könnte aus meiner Sicht die Übersichtlichkeit erhöht werden, wenn diese bei der Einstellung “Empty” ausgegraut werden, also optisch in den Hintergrund treten. Gerade ein unbelegter Fader zeigt dies nicht offensichtlich genug.

Ich habe mir ein Projekt erstellt, um die verschiedenen Executor-Typen zu testen und zu dokumentieren. Die Belegung der verschiedenen Seiten ist in den beigefügten Screenshots zu sehen. Die verschiedenen Executoren enthalten dabei auf allen Seiten mehrfach die gleichen Elemente, damit ich insbesondere auch die zahlreichen Buttons prüfen kann. Soweit ich das überblicke, werden diese Informationen auch richtig in die Datei “ExecutorMemberWrappers.xml” geschrieben.

Beim erneuten Laden des Projekts direkt aus der laufenden Sitzung heraus oder auch beim Laden des Projekts nach einem Neustart von DMXC werden die Belegung der Executor-Pages augenscheinlich unvollständig bzw. gar nicht geladen - insbesondere bei den “hinteren” Executor-Pages (im aktuellen Beispiel Group Master, Parameter Master etc.). Beim Betätigen des Faders des Executor 2.1 (Executor Page Group Master) kann man aber erkennen, dass eine Verknüpfung im Hintergrund noch existiert. Die Fader der Executoren 2.2 und 2.3 bewegen sich mit. Gleiches fällt auf, wenn man die Belegung der Executoren ändern möchte. Es wird erst beim zweiten Ablegen eines Elements auf den Executor wirklich das neue Element angezeigt.

Im Anhang findet sich neben den Screenshots des Sollzustands das zugehörige Projekt sowie die Logfiles, die nach dem Neustart und Laden des Projekts generiert wurden.

Öffne ich das Projekt aus  FS#4656  und starte dann einmal nur die GUI neu, ist das Executor-Fenster komplett leer. Es werden sowohl keine Executor Pages als auch die Executoren selbst nicht angezeigt.

Klicke ich aber auf “Add Page”, merkt das Fenster, dass bereits Executor Pages im geladenen Projekt existieren und beginnt entsprechend nach dem “höchsten” Executor zu zählen. Auch die Seitenzahl beginnt nicht bei 1.

Ist ein Button mit “Empty” belegt, sollten diese so gestaltet werden, dass diese farblich deutlich zurückhaltend gestaltet sind. Aktuell muss man sehr genau schauen, welche Button mit einer “richtigen” Aktion belegt sind.

Für den Position Master sollen folgende Buttons hinzugefügt werden:

• Zero Pan
• Zero Tilt

Aktuell gibt es in den Einstellungen für den Executor zu den Cuelists noch den Eintrag “Release at zero”. Dieser funktioniert nicht und wurde mittlerweile durch “Auto Stop” abgelöst.

Die neuen Executoren unterstützen aktuell noch keine Multi-Touch-Eingabe. Diese Funktion soll auch Basis der Implementierung im Softdesk übernommen werden.

Arbeitet man mit mehreren Seiten, wird der Button der aktuellen ausgewählten Seite immer mittig dargestellt. Dies ist auch der Fall, wenn das Executor-Fenster breit genug ist und alle Buttons dargestellt werden können. Daher sollte aus meiner Sicht das Schieben der Buttons erst aktiviert werden, wenn die Breite des Fensters nicht ausreicht, um alle Buttons darzustellen. Steht genügend Platz zur Verfügung, sollten die Buttons einfach nur statisch zentriert angezeigt werden.

Der neue Fadertyp “Limit” für die Executor-Variante der Cuelist ist in den Einstellungen des Executors noch nicht in der Auswahlliste für den Fader enthalten.

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.

Die Werte für Fade Factor und Speed Factor einer Cuelist umfassen bekanntermaßen einen Wertebereich von 0% bis 1000% (also 0 bis 10). Dies müsste der Cuelist Group Executor an dieser Stelle eigentlich auch unterstützen.

Vom Workflow ist es (zumindest für mich) einfacher, einen Effekt mit einer geringeren Geschwindigkeit zu programmieren und diesen dann auf Wunsch zu beschleunigen als immer von der maximalen Geschwindigkeit auszugehen (Stichwort Headroom).

Unter diesem Gesichtspunkt wurde bereits das Ticket  FS#4325  verfasst, dass sich hier aber vorrangig auf eine funktionelle Erweiterung des Cuelist Group Nodes im Input Assignment bezieht.

Das Feld für die Executor-Nummer sollte mindestens so groß sein, dass drei Ziffern klar angezeigt werden. Diese Zahl kann vergleichsweise schnell erreicht werden.

Wie im beigefügten Screenshot zu sehen, werden aktuell selbst zwei Ziffern nicht vollständig dargestellt. Ich könne daher vorstellen, dass sich die Breite des Feldes an der Breite des Textes orientiert, um so bei wenigen Executoren wiederum noch mehr Platz für den Text zu haben.

Beim Anlegen einer neuen Gruppe aus ausgewählten Geräten wird diese neue Gruppe bei mehreren StageViews immer in der zuerst angelegten StageView eingefügt, aber nicht in der, in der die Geräte für die neue Gruppe ausgewählt wurden.

Wird innerhalb einer StageView in Icon (egal ob Gruppe oder Gerät) mit der Maus verschoben, werden die Positionswerte für das Icon im Properties-Fenster erst nach dem Neuladen der StageView (z. B. durch ein kurzes Wechseln in eine andere Registerkarte) aktualisiert.

Folgende Vorgehensweise führt zu einem Absturz der GUI:

• Einfügen eines neuen Device zum Projekt
• Ändern verschiedener Werte in der StageView
• Anschauen dieser Werte in der ChannelOverview
• Direktes Löschen des Geräts aus dem Projekt, ohne den Programmer etc. zurückzusetzen

Dies ist vielleicht nicht ein alltägliches Szenario. Es ist mir beim Überprüfen der DDFs unter die Finger gekommen.

Bei Effekten wie Rechteck, Trapez oder weiteren, bei denen explizit mit Zeiten gearbeitet wird (fade up time, fade down time, pause) sollte nicht die Phasenverschiebung nicht als Winkel in Grad, sondern als Zeitwert in (Milli-) Sekunden angegeben werden.

Wenn ich die Größe einer Matrix nachträglich über die Properties ändere (egal ob Vergrößerung oder Verkleinerung), kommt diese Änderung im PropertyGrid zahlenmäßig erst an, nachdem ich einmal den Matrix FormEditor geöffnet und mit OK wieder geschlossen habe. Die Matrix-Effekte kommen nach (und auch während) der Änderung allerdings direkt richtig an. In den meisten Fällen sollte dieser Schritt meiner Meinung unnötig sein und könnte aktuell noch zu Verwirrungen führen.

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

Aktuell fehlt die Möglichkeit, eine Polygone als Effekt auf Position zu legen. So können mit nur einem Effekt Dreiecke, Vier- / Rechtecke, Fünfecke etc. zu erstellen. Folgende Parameter sollte der Effekt haben:

• Anzahl der Seiten / Anzahl der Ecken
• Breite und Höhe des Polygons
• Frequenz (Geschwindigkeit)
• Drehung der Figur (Index)
• Phase

Optional könnte der Effekt um die Möglichkeit erweitert werden, über den Parameter Radius die Ecken abzurunden, um abgerundete Rechtecke zu erhalten. Zur Vermeidung von Komplikationen muss der maximale Wert des Radius in Abhängigkeit der Breite / Höhe dynamisch berechnet werden.

EDIT Arne: Was auch geil wäre ist, wenn man das Polygon rotieren lassen könnte, also neben dem festen “Index” noch eine “Rotation” Eigenschaft. Damit könnte man seine Scanner ein drehendes 4-Eck fahren lassen. Das soll die GrandMa mal nachmachen

Es wäre hier von Vorteil, wenn die betreffende Szene entsprechend gekennzeichnet wird, dass für diese der Cue Timing Editor aktiv ist. Ggf. kann dieses durch Einfügen einer zusätzlichen Spalte erfolgen, wo dieser analog zu den Spalten “Cue active”, “Autoprepare” und “Take fades” aktiviert und deaktiviert werden kann. Hierbei wird der Haken automatisch gesetzt, sobald man in den Cue Timing Editor Werte eingetragen und dieses geschlossen hat.

Folgendes wurde behoben:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Wird im Cue Timing Editor für eine Cue eine Fade- und / oder eine Delay-Zeit eingetragen, können diese Werte fortan nur noch dort geändert werden. Ändert man nachträglich die Werte direkt in den betreffenden Spalten in der Cuelist, haben die Werte vom Cue Timing Editor weiterhin bestand.

Es fehlt hier die Möglichkeit, den Cue Timing Editor zu deaktivieren oder zurückzusetzen, zum Beispiel einfach durch löschen aller Einträge in den Feldern.

Aktuell können die Werte vom Cue Timing Editor nur durch das Ersetzen der komplett neu erstellten Szene zurückzusetzen werden. Die Cue nur im Programmer zu editieren reicht nicht aus.

Wird in einer Cuelist bei der Triggerung des ersten Cues mittels follow oder wait, verbunden mit einer Wartezeit gearbeitet, so läuft grundsätzlich immer erst die angegebene Wartezeit ab, bevor die Cuelist etwas ausgibt.

Es mag durchaus Situationen gegeben, in denen dieses Verhalten sinnvoll ist. Im Live-Betrieb in einem Club oder auf einem Konzert wäre es allerdings besser, wenn die Cuelist beim Aufraufen / ersten Start sofort mit der Ausgabe starten und die angegebene Wartezeit ignorieren würde. In Anlehnung an die Diskussion im Forum im Thread Follow trigger schlage ich vor, entweder als globale Option oder einstellbar für jede Cuelist den Punkt: “Ignore trigger value at cuelist start” bzw. “Use trigger value at cuelist start“, sofern letzteres eher der Sonderfall ist. Sollte dieser Punkt für jede Cuelist einstellbar sein, sollte in den globalen Einstellungen ein Standard-Wert auswählbar sein.

Für Color Chaser wäre es hilfreich, diesen über den Beat zu synchronisieren und darüber hinaus die Übergänge faden zu können, ggf. unter der Angabe einer Fadezeit.

Ich setze ich über eine Matrix (in meinem Fall 3 Zeilen und 8 Spalten) eine beliebige Farbe und verringere danach die Größe der Matrix zum Beispiel auf 3 x 3. Danach lässt sich die gesetzte Farbe der nicht mehr einfach über Clear Programmer löschen. Um die Geräte zur “resetten” muss einmal eine beliebige Farbe manuell gesetzt werden, sodass der Programmer “frische” Werte erhält, die dann über Clear Programmer gelöscht werden können.

Hier sollte vor dem aktiv werden der neuen Matrixgröße einmal automatisch der Programmer gelöscht werden.

Aktuell lassen sich Cuelists, Devices, etc. im Project Explorer aktuell nur sortieren, indem man einen Rechtsklick macht und dort aus dem Kontextmenü Sort einen entsprechenden Eintrag zum Sortieren wählt.

Vorteilhafter wäre es, wenn man durch das Klicken auf die jeweilige Überschrift die Einträge entsprechend sortieren kann - ähnlich wie im Windows Explorer.