Bugtracker DMXControl 3

Aktuell werden in den Executoren die DisplayNames der Button und Fader beim Speichern verwendet und nicht die Names. Das macht dann natürlich die Nutzung der DisplayNames nicht mehr funktional. Hier müssen wir eine Lösung finden.

Genutzt wurde das folgende DDF (”colortemp”-Teil aus Wiki-Eintrag übernommen: https://wiki-de.dmxcontrol-projects.org/index.php?title=Color_(DDF-Syntax)_DMXC3#Farbtemperatur):

<?xml version="1.0" encoding="utf-8"?>
<device dmxaddresscount="1" type="DMXDevice" dmxcversion="3.2" ddfversion="1.0">
	<information>
		<model>Test Device</model>
		<vendor>Test</vendor>
	</information>
	<functions>
		<colortemp dmxchannel="0">
			<step type="off" mindmx="0" maxdmx="5" />
			<range minval="3200" maxval="7000" mindmx="255" maxdmx="6" />
		</colortemp>
	</functions>
</device>

Setzt man den “colortemp”-Kanal auf “Empty”, so wird der DMX-Wert des Minimalwerts der CTC-Range ausgegeben. (Also hier “255”.)
Zu erwarten wäre ein Wert zwischen “0” und “5”.

Der restliche Bereich funktioniert wie zu erwarten.

Starte ich DMXControl 3 erstmals auf dem PC (mit Default-Einstellungen) oder ändere das Arbeitsverzeichnis über eine Umgebungsvariable, sollte hierbei überprüft werden, ob die folgenden Verzeichnisse bereits existieren:

• Pictures
• UserDevices
  • Icons
  • Images

Für den Fall, dass diese Verzeichnisse nicht existieren, sollte der Kernel diese dort automatisch anlegen - auch wenn sie anfangs leer sind. Dies ist insbesondere für die UserDevices wichtig, da ansonsten die Verknüpfung im Startmenü “ins Leere läuft” und folglich nicht funktioniert. Hierzu gab es im Forum immer wieder Mal Rückfragen, wo die Antwort dann lautete “Bitte selbst unter … anlegen”.

Wenn ich ein Preset auf Teile einer Szene angewendet habe, gibt es keine Möglichkeit, diese Werte vom Preset zu entkoppeln. Sprich, die Werte des Presets sollen dann kopiert werden, aber nicht mehr mit dem Preset verknüpft sein.

Ich habe zwei Cuelists mehreren Cuelist Groups zugeordnet. Beide Cuelist groups stehen auf “Single list running”. Wechsele ich zwischen den Cuelists hin- und her, wird in der Regel die Release time der zu beendenden Cuelist ignoriert. Folglich wird die alte Cuelist hart ausgeblendet und nur die neue faded ein. Der Kernel protokolliert in diesem Moment folgendes, wobei klar ersichtlich ist, dass der Release der Cuelists mehrfach getriggert wird:

2025-03-26 20:30:15,492 [Log-Thread] DEBUG org.dmxc.lumos.Kernel.Scene.SceneFadeTicker - Registriere: org.dmxc.lumos.Kernel.SceneList.ValuesStack.OutputValuesStack
2025-03-26 20:30:15,553 [Log-Thread] DEBUG org.dmxc.lumos.Kernel.SceneList.SceneListGroup - Stopping Cuelist Cuelist 2 due to Group Group 1 config.
2025-03-26 20:30:15,553 [Log-Thread] DEBUG org.dmxc.lumos.Kernel.SceneList.SceneListGroup - Stopping Cuelist Cuelist 2 due to Group Group 2 config.
2025-03-26 20:30:15,553 [Log-Thread] WARN  org.dmxc.lumos.Kernel.SceneList.SceneList - Unable to stop Cuelist Cuelist 2, because other Invocation is currently in process
2025-03-26 20:30:15,554 [Log-Thread] DEBUG org.dmxc.lumos.Kernel.Scene.SceneFadeTicker - Registriere: org.dmxc.lumos.Kernel.Scene.Fade.MixerFadeDecorator
2025-03-26 20:30:15,554 [Log-Thread] DEBUG org.dmxc.lumos.Kernel.SceneList.SceneListGroup - Skip Stopping Cuelist Cuelist 1 due to Group Group 1 config as List is releasing.
2025-03-26 20:30:15,608 [Log-Thread] DEBUG org.dmxc.lumos.Kernel.Scene.SceneFadeTicker+TickerParallelBag - Enqueuing for deregistration Auto: org.dmxc.lumos.Kernel.Scene.Fade.MixerFadeDecorator
2025-03-26 20:30:15,608 [Log-Thread] DEBUG org.dmxc.lumos.Kernel.Scene.SceneFadeTicker+TickerParallelBag - Enqueuing for deregistration Auto: org.dmxc.lumos.Kernel.SceneList.ValuesStack.OutputValuesStack
2025-03-26 20:30:15,642 [Log-Thread] DEBUG org.dmxc.lumos.Kernel.Scene.SceneFadeTicker - Deregistriere: org.dmxc.lumos.Kernel.Scene.Fade.MixerFadeDecorator
2025-03-26 20:30:15,642 [Log-Thread] DEBUG org.dmxc.lumos.Kernel.Scene.SceneFadeTicker - Deregistriere: org.dmxc.lumos.Kernel.SceneList.ValuesStack.OutputValuesStack
2025-03-26 20:30:15,710 [Log-Thread] DEBUG org.dmxc.lumos.Kernel.SceneList.SceneListGroup - Skip Stopping Cuelist Cuelist 1 due to Group Group 2 config as List is releasing.
2025-03-26 20:30:16,221 [Log-Thread] DEBUG org.dmxc.lumos.Kernel.Scene.SceneFadeTicker+TickerParallelBag - Enqueuing for deregistration Auto: org.dmxc.lumos.Kernel.Scene.Fade.MixerFadeDecorator
2025-03-26 20:30:16,221 [Log-Thread] DEBUG org.dmxc.lumos.Kernel.Scene.SceneFadeTicker+TickerParallelBag - Enqueuing for deregistration Auto: org.dmxc.lumos.Kernel.SceneList.ValuesStack.OutputValuesStack
2025-03-26 20:30:16,255 [Log-Thread] DEBUG org.dmxc.lumos.Kernel.Scene.SceneFadeTicker - Deregistriere: org.dmxc.lumos.Kernel.Scene.Fade.MixerFadeDecorator
2025-03-26 20:30:16,255 [Log-Thread] DEBUG org.dmxc.lumos.Kernel.Scene.SceneFadeTicker - Deregistriere: org.dmxc.lumos.Kernel.SceneList.ValuesStack.OutputValuesStack

Schalte ich das Single list running bei einer der beiden Cuelist groups aus, erfolgt der Übergang wie erwartet mit der eingestellten Release time sowie mit der Fade time der neuen Cuelist.

An dieser Stelle wäre meine Erwartungshaltung, dass die Zuordnung von Cuelists zu mehreren Cuelist groups mit der Einstellung “Single list running” nicht darauf Einfluss hat, ob der Release einer Cuelist vollständig ausgeführt wird oder nicht. Soll eine Cuelist keine Release time haben, lege ich dies in den Einstellungen der Cuelist fest.

Um das Problem ggf. besser zu verstehen, habe ich das beigefügte Beispielprojekt gebaut. Hierzu einfach zwischen den drei Cuelists hin- und herschalten, die den Executoren zugeordnet sind.

Bei mir fehlen in den General Settings die folgenden Einstellungen für das Project Autosave / Project Administration:

• Keep files per project
• Maximum MB per project
• Warning MB in project store

Ich kann aktuell nicht nachvollziehen, seit wann diese Einstellungen nicht mehr verfügbar sind. Um die Bezeichnungen der verschiedenen Optionen musste ich im Livestream zu gRPC nachschauen, weil wir dort die Einstellungen gezeigt haben.

In der Konfigurations-Datei für den Kernel sind aber noch alle Optionen vorhanden:

<TreeItem Name="PROJECT.AUTO_SAVE_ENABLED">
      <Attribute Name="Value" Type="Primitive" ValueType="String" Value="False" />
    </TreeItem>
    <TreeItem Name="PROJECT.AUTO_SAVE_INTERVAL">
      <Attribute Name="Value" Type="Primitive" ValueType="String" Value="10" />
    </TreeItem>
    <TreeItem Name="PROJECT.AUTO_SAVE_SUSPEND_ON_ACTIVITY">
      <Attribute Name="Value" Type="Primitive" ValueType="String" Value="False" />
    </TreeItem>
    <TreeItem Name="PROJECT.AUTO_SAVE_KEEP_FILES">
      <Attribute Name="Value" Type="Primitive" ValueType="String" Value="50" />
    </TreeItem>
    <TreeItem Name="PROJECT.AUTO_SAVE_MAX_MB">
      <Attribute Name="Value" Type="Primitive" ValueType="String" Value="250" />
    </TreeItem>
    <TreeItem Name="PROJECT.AUTO_SAVE_TOTAL_MAX_MB">
      <Attribute Name="Value" Type="Primitive" ValueType="String" Value="1000" />
    </TreeItem>

Im Anhang habe ich die Logs sowie einen Screenshot beigefügt, der zeigt, dass die Einstellungen fehlen.

Hello!

I wanted to add a point on DDF RADIX DDF Profiles.

It seems that the <angleoffset> parameter has no effect on changing the orientation of pixel start points, or, in the visual GUI.

I have no idea if this was ever working in previous versions, as I have only started using RADIX Recently. Here is a Demo DDF for a fixture I am trying to make it wori with, but, also trying to make DDF for custom layouts and saving it as a full fixture for efficient processing of many ‘dimmers’

For instance. If pixel one starts at the 3:00 position, and I set ‘angle offset’ to 90 clockwise, the GUI, and actual DMX Fixture have no effect. the First pixel is stuck at default position in DMXC.

I am not sure I I am doing something wrong, But I also tested in other strange ways. Nothing seemed to work.

Thank you!

Wie bei anderen Reglern auch wäre es praktisch, die Option zu haben, den Fader mit dem Scrollrad der Maus bedienen zu können.

Fehlerbeschreibung

Erwartetes Verhalten

Weiteres

When using the Matrix Effect: ‘Random’, Changing the value of the ‘Pixel Random’ parameter breaks the effect.

It would be great if the Bitmap Matrix Effect supported animated files including WEBM, GIF, Various Video Files, Live Video Input ETC.

Bitmap Pixel Effect does not recall image from cue.

When saving a bitmap pixel effect to a cue, only the default DMXC Logo appears when recalling the cue. The cue does not recall the Bitmap Source image.

Fehlerbeschreibung

Erwartetes Verhalten

Hinweise

Führt man die Installation auf einem Gerät ohne vorhandene Internetverbindung aus, wird erst zu spät festgestellt, dass diese nicht vorliegt. So werden verschiedene .net-Frameworks nicht installiert bevor man einen Hinweis erhält. Dadurch entsteht der Eindruck, dass bis dahin alles ordnungsgemäß abgelaufen ist.

Im Idealfall prüft der Installer ganz zu Anfang, ob eine Internetverbindung besteht und gibt einen Hinweis, falls diese nicht existiert.

Fehlerbeschreibung

Erwartetes Verhalten

Folgende Features sollte der Zeitplaner haben:

• Mehrere Einträge
• Cron-Syntax als Hintergrund und vom User eingebbar sein
• UI soll aber auch so sein, dass einfache Eingaben möglich sind
  • An spezifischen Tagen
  • Jeder n-te Tag in der Woche / Monat
  • Gewisse Wochentage
• Der Zeitplaner soll folgendes triggern können
  • Cuelists
  • Trigger im Input Assignment
  • Evtl. Executoren

Fehlerbeschreibung

Erwartetes Verhalten

Hinweise

Heute hat der Executor-Fader einer Timecodeshow keine Funktion.

Erwartetes Verhalten

Für die Arbeit im Timecodeplayer wäre es hilfreich, wenn man innerhalb eines Cuelist-Tracks mehrere Cuelists markieren könnte und somit alle markierten Cuelists am Stück, synchron zeitlich verschieben könnte.

Use-Case:
Es wird beispielsweise nachträglich am Anfang ein paar Sekunden Stille benötigt (um z.B. Movingheads vor zu positionieren). Verschiebt man nun das Audio-File in seiner Spur müssen im Moment alle Cuelists einzeln in der Postion korrigiert werden. Könnte man alle markieren, wäre es möglich diese am Stück zu verschieben.

weitere praktische Funktionen wären auch:
- “alle Cuelists rechts vom Postionszeiger markieren (einzelne Spur)” - “alle Cuelists rechts vom Postionszeiger markieren (alle Spuren)” - “alle Cuelists links vom Postionszeiger markieren (einzelne Spur)” - “alle Cuelists links vom Postionszeiger markieren (alle Spuren)”

Fehlerbeschreibung

Erwartetes Verhalten

Hinweise

Version: 3.3 RC5

Fehler:
Bitmap from Resource lädt beim Start von DMX Control nicht die Icons.

Über den Workaround “Manueller Reset des Szenenlisten-Monitors” werden die Icons angezeigt.

Siehe auch Screenshot.

Wird DMXC installiert und ein Programmteil läuft unbeabsichtigt noch, kommt es im Installer zu Fehlermeldungen, die jedoch nicht darauf schließen lassen, dass das Problem ist, dass DMXC - teilweise - noch läuft.

Check in Installer wie schon bereits besprochen

Fehlerbeschreibung

Erwartetes Verhalten

Hinweise

Ich habe über die Startparameter –correlation=cpu und –correlation=gpu die Gobo-Korrelation jeweils manuell angestoßen. In beiden Fällen versucht der Kernel, die zugehörige Datei im Installationsverzeichnis zu speichern statt im Benutzerdatenverzeichnis. Aus diesem Grund erscheint die folgende Fehlermeldung.

14:16:02 WARN  ResourceManager - Unable to save Resource GoboCorrelations_CPU.csv of Type Application
System.UnauthorizedAccessException: Access to the path 'C:\Program Files (x86)\DMXControl Projects\DMXControl 3.3.0\Kernel\Config\GoboCorrelations_CPU.csv' is denied.
   at Microsoft.Win32.SafeHandles.SafeFileHandle.CreateFile(String fullPath, FileMode mode, FileAccess access, FileShare share, FileOptions options)
   at Microsoft.Win32.SafeHandles.SafeFileHandle.Open(String fullPath, FileMode mode, FileAccess access, FileShare share, FileOptions options, Int64 preallocationSize)
   at System.IO.Strategies.OSFileStreamStrategy..ctor(String path, FileMode mode, FileAccess access, FileShare share, FileOptions options, Int64 preallocationSize)
   at System.IO.Strategies.FileStreamHelpers.ChooseStrategy(FileStream fileStream, String path, FileMode mode, FileAccess access, FileShare share, Int32 bufferSize, FileOptions options, Int64 preallocationSize)
   at System.IO.File.Create(String path)
   at org.dmxc.lumos.Kernel.Resource.FileAccessUtil.SaveResourceToFileAsync(String relativePath, Stream data, Boolean useLocalPath, IProgress`1 progress, Boolean throwOnError) in D:\Jenkins\workspace\Lumos_Pipeline_3.3\LumosLIB\src\Kernel\Resource\FileAccessUtil.cs:line 296
   at LumosToolsLIB.Tools.AsyncHelper.RunSync[TResult](Func`1 func) in D:\Jenkins\workspace\Lumos_Pipeline_3.3\LumosToolsLIB\src\Tools\AsyncHelper.cs:line 0
   at org.dmxc.lumos.Kernel.Resource.Datastore.FileBackendDatastore.SaveResourceToStorage(String relativePath, Stream data, IProgress`1 progress) in D:\Jenkins\workspace\Lumos_Pipeline_3.3\Lumos\src\Kernel\Resource\Datastore\FileBackendDatastore.cs:line 498
   at 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:line 488
   at 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:line 230
   at org.dmxc.lumos.Kernel.Resource.AbstractResourceManager.SaveResourceAsync(EResourceType type, LumosResource data, IProgress`1 progress) in D:\Jenkins\workspace\Lumos_Pipeline_3.3\LumosLIB\src\Kernel\Resource\AbstractResourceManager.cs:line 768

Ich würde an dieser Stelle erwarten, dass die GoboCorrelations_CPU.csv und GoboCorrelations_GPU.csv im Butzerdatenverzeichnis abgelegt wird und dabei die dortigen Dateien aktualisiert. Normalerweise dürfen die Daten im Installationsverzeichnis ja nicht verändert werden.

Ich fände es gut, wenn “Umbra.exe” zukünftig zu “LumosUmbra.exe” würde.

Manchmal muss man ja doch den Taskmanager bemühen, um “übriggebliebene” DMXC-Komponenten abzuschießen oder auch nur nachzusehen, welche Komponenten evtl. noch laufen.
Da ist es etwas unpraktisch und vll. unerwartet, dass es neben “Lumos.exe” und “LumosGUI.exe” ganz unten in der Liste noch eine “Umbra.exe” gibt, die auch noch dazu gehört, aber eben nicht den Namensbestandteil “Lumos” enthält.

Fehlerbeschreibung

Forum: https://forum.dmxcontrol-projects.org/index.php?thread/17686-performance-probleme-bei-vielen-cuelists/

Hallo zusammen,

wir verwenden bei uns Szenenlisten, um Lichtstimmungen passend zu einem Lied vor zu programmieren.

Dabei erstellen wir pro Lied eine neue Szenenliste und fügen dieser andere Szenenlisten, wie Beispielsweise einen Bewegungseffekt, Dimmereffekt oder Farbe hinzu um diese mit der Lied- Szenenliste zu starten.

Die Lied- Szenenliste hat dabei nur den Auftrag alle anderen zu starten (erste Cue (andere Szenenliste) auf Manual und dann alle folgenden mit follow 0ms danach), sodass wir dann nur noch die einzelnen Cuelists mit Mastern in ihrer Intensität und Schnelligkeit reinmischen müssen.

Da bei uns regelmäßig unterschiedliche Bands auftreten, kommen da schnell ein paar Lied- Szenenlisten zusammen.

Nun das Problem:

Mir ist aufgefallen, dass nach ca. 120 Lied- Szenenlisten mein Projekt deutlich langsamer läuft.

So fällt bsp. bei Strobe- Effekten auf, die per Tastatur mit “GO” gestartet werden und beim Loslassen der Taste über Binary Switcher über “STOP” gestoppt werden sollen, nicht mehr gestoppt werden und es einem zweiten oder auch dritten Drücken auf die Taste bedarf bis die Cuelists gestoppt wird.
Auch haben unsere Slider, die die Groupmaster steuern ein deutliches Delay (teilweise ca. 3 Sekunden)

Um das Projekt im Live-Betrieb bedienbarer zu machen, löschen wir vor jedem Konzert alle nicht verwendeten Lied-Cuelists raus. Dies hat einen deutlichen Einfluss auf die Performance.

Aktuell sind wir auf der 3.3.0 RC3 auf einem Laptop mit aktuellem AMD Ryzen 5 und 8GB Ram.
Auf der RC2 und einem anderen Rechner mit i7 und 16GB Ram hatten wir aber auch das selbe Problem.

Vielen Dank
Falko

Matrix Ausgabe bleibt stehen sobalt Man eine Farbe ausgewäht hat

Fehlerbeschreibung

Erwartetes Verhalten

Bitte die Möglichkeit innerhalb eines Projektes eoinen Softdesk zu kopieren inkl. aller Zuweisungen um z.B. verschiedene Softdesks im Projekt zu haben für verschiedene Aufbauten.

Ich lade das Projekt im Anhang und drücke ein paar Mal aber nicht schnell hintereinander auf Alle Szenenlisten beenden.
Nach dem dritten oder vierten Mal funktioniert das nicht mehr und ich sehe im Umbra eine Fehlermeldung.
Der Kernel lässt sich dann auch nur noch über den Task Manager beenden.

Dragging the slider bar with the mouse on the beam window’s focus or other slider bar causes it to pull and tremble.

3.3RC3

Fehlerbeschreibung

Hallo,
Im Node für Proceduren eines Devices oder Device Group die Möglichkeit schaffen eigene Proceduren zu verwenden.

Es gibt da in dem Node eine Liste von Proceduren die man verwenden kann.
(Bild von der Liste im Anhang)
Ich hatte einen Teil des DDFs mit dem DDF Creator 3 erstellt. Auch hier gibt es eine Liste mit Proceduren.
(Auch hiervon ein Bild im Anhang)
Es gab da, da das was ich verwenden wollte nicht aufgeführt war, die Möglichkeit eine Procedure “Custom” anzulegen.
Ich habe dafür dann auch zwei Proceduren “Custom” erstellt.
Diese beiden Proceduren kann ich über die Stage View anwählen und ausführen, Im Node für die Proceduren finde ich die aber nicht.

Mein Wunsch wäre:
Entweder, wenn in dem Node ein Device oder eine Device Group ausgewählt wurde, die dafür verwendbaren Proceduren alle anzuzeigen.
Oder
Zusätzliche Proceduren in die Liste zur Verwendung mit aufzunehmen.
In meinem Fall wäre das fan_min und fan_max
Vielleicht gibt es da von anderen noch weitere Wünsche ?

Ich habe mein verwendetes DDF auch mal mit angehängt.

Gruß Steff

Hallo,
Ich wollte den Node für die Prozeduren von Devices oder Device Groups verwenden.
Um eine Device Group oder ein Device für dieses Node auszuwählen muß ich ein Device oder Device Group Node hinzu fügen, dies mit dem Prcedure Node verbinden um entsprechendes auszuwählen.

Hier wäre mein Wunsch:
Das in das Procedure Node eine Möglichkeit eingebaut wird, in den Properties von dem Node ein Device oder Device Group anzuwählen.

Gruß Steff

Fehlerbeschreibung

Erwartetes Verhalten

Ich habe bewusst im Project Store herumgefummelt und dabei eine Projekt-Datei umbenannt. Möchte ich nun diese Version trotzdem laden, erscheint in der GUI nur die allgemeine Fehlermeldung “An error occurred while loading version ??? of …” und das Project Errors Fenster bleibt komplett leer. Der Kernel meldet aber korrekterweise, dass die Version nicht gefunden werden kann.

Von daher wäre es hilfreich, wenn die Info, die der Kernel hat, ebenfalls an die GUI weitergereicht wird - hier also “Unable to find Project ??? in Project Store”.

This Task is to bring attention to the occurrences of random crashing experienced when programming the last project worked on. (v3.2.3)

I cannot pinpoint exactly what causes these issues but I have attached a LOG Export from the project. I hope it is not too late since the bugs occurred to export the LOG.

These crashes ranged anywhere from:

-Cue lists randomly not tracking correctly after some time programming inside the GUI.

-Tracking True / False Not applying to cue lists.

-Fixture Parameters not being able to be selected in the GUI or Programmer.

-Rare, but the whole GUI would sometimes lock up to the point I could not save a project before attempting to restart.

Generally, a full restart of the DMXControl Application would resolve the issues.

Sometimes, a full system restart was required.

Also, it seems the parameter: “Reset When Released” has absolutely no effect on Cue list release behavior.

I did notice this trend: that often when using Fanning Parameters (E.g. -90<>90 … 0>120>0 … 0<>90) in X/Y Moving head parameters, that DMXControl 3.2.3 would then behave extremely erratically, and eventually begin adding its own values in parameter fields, and eventually crash. When closing the application, I would then be presented with a messaged saying: “DMXControl Crashed - This should not have happened. Please Export Log to Bugtracker.”

Dedicated Show and Cue List playback seems extremely stable, it is only in heavy periods of programming that these crashes seem to occur.

Thank You.

Diese Aufgabe soll auf das Auftreten von zufälligen Abstürzen aufmerksam machen, die beim Programmieren des zuletzt bearbeiteten Projekts aufgetreten sind. (v3.2.3)

Ich kann nicht genau sagen, was diese Probleme verursacht, aber ich habe einen LOG-Export aus dem Projekt angehängt. Ich hoffe, es ist nicht zu spät, da die Fehler beim Exportieren des LOG aufgetreten sind.

Diese Abstürze reichten von:

-Cue-Listen werden nach einiger Zeit in der GUI zufällig nicht korrekt verfolgt.

-Tracking True / False Gilt nicht für Cue-Listen.

-Geräteparameter können nicht in der GUI oder im Programmierer ausgewählt werden.

-Selten, aber die gesamte GUI wurde manchmal bis zu dem Punkt gesperrt, an dem ich ein Projekt nicht speichern konnte, bevor ich versuchte, neu zu starten.

Im Allgemeinen würde ein vollständiger Neustart der DMXControl-Anwendung die Probleme beheben.

Manchmal war ein vollständiger Systemneustart erforderlich.

Außerdem scheint der Parameter: “Reset When Released” absolut keinen Einfluss auf das Freigabeverhalten der Cue-Liste zu haben.

Ich habe diesen Trend bemerkt: dass oft bei der Verwendung von Fanning-Parametern (z. B. -90<>90 … 0>120>0 … 0<>90) in X/Y-Moving-Head-Parametern, dass sich DMXControl 3.2.3 dann extrem unberechenbar verhält und schließlich anfängt, seine eigenen Werte in Parameterfeldern hinzuzufügen und schließlich abstürzt. Beim Schließen der Anwendung wurde mir dann eine Meldung angezeigt, die besagt: “DMXControl abgestürzt - Dies hätte nicht passieren dürfen. Bitte exportieren Sie das Protokoll in den Bugtracker.”

Die dedizierte Show- und Cue-List-Wiedergabe scheint extrem stabil zu sein, nur in schweren Programmphasen scheinen diese Abstürze aufzutreten.

Vielen Dank.

Führt man das Ticket FS#5348 gedanklich weiter, dann wäre im Zuge der Umsetzung der dort beschriebenen Funktion zu überlegen, ob das Fenster “Update DDFs in Project” von seiner Funktion her mit in das “Add device” Fenster übertragen wird.

Dies könnte ggf. bei der Neugestaltung des “Add device” Fensters im Rahmen des WPF-Umbaus erfolgen.

Wird ein DDF in einem Projekt bereits verwendet und man fügt weitere bzw. erneut Geräte ein, die dieses DDF verwenden, so wird dieses immer explizit aus dem Projekt herangezogen. Für ein bestehendes Projekt ist diese Regelung durchaus hilfreich, jedoch nicht, wenn man gerade ein neues DDF erstellt. Hier muss man dann immer erst die alte Version aus dem Projekt löschen, um dann die aktualisierte / korrigierte / ergänzte Version des DDFs ins Projekt einfügen zu können.

An dieser Stelle wäre es hilfreich, wenn man beim Hinzufügen explizit sagen könnte, dass die neuere Version aus dem Dateisystem verwendet werden soll. Dabei überschreibt diese Version dann die Version, die bis dato im Projekt existiert.

Jens-Peter und ich haben an einem DDF gearbeitet und dabei den folgenden Code eingefügt - so, wie er auch im Wiki dokumentiert ist.

<rawranges dmxchannel="0" name="Auto show" >
  <step type="Off" mindmx="0" maxdmx="31" />
  <range type="Show 1" mindmx="32" maxdmx="63" minval="0" maxval="100" />
  <range type="Show 2" mindmx="64" maxdmx="95" minval="0" maxval="100" />
</rawranges>

Bei dieser Implementierung ist es so, dass der step-Eintrag im Device Control nicht auswählbar ist. Damit lässt sich die Funktion in Form der verschiedenen Automatik-Shows nicht abschalten. Hierfür muss aktuell der folgende Workaround herhalten:

<rawranges dmxchannel="0" name="Auto show" >
  <range type="Off" mindmx="0" maxdmx="0" minval="0" maxval="100" />
  <range type="Show 1" mindmx="32" maxdmx="63" minval="0" maxval="100" />
  <range type="Show 2" mindmx="64" maxdmx="95" minval="0" maxval="100" />
</rawranges>

Es wäre wie gesagt hilfreich, wenn der beschriebene Workaround nicht erforderlich wäre und direkt step-Einträge bei der Funktion rawranges unterstützt werden.

I have a request for dmx interface settings.

In 3.3RC, all Artnet will be set up one by one to increase the universes.
However, when using a large number of 15 universes, we have to work with IPs, universe numbers, etc. each time we add a new one.
In 3.2, we could specify one IP and one universe at a time, but in 3.3, it becomes quite a tedious task.
Can this be improved?

Aufbauend auf das Ticket  FS#5305  muss der DMXC-Mixer Node ebenfalls ergänzt werden. Aktuell kann ich über den DMXC-Mixer Node nicht ermitteln, ob ein Generic Switch aktiv ist oder nicht. Folgende Wege wären denkbar:

• Der Status wird mit in den Output “Intensity” aufgenommen, dem entsprechend Off = 0 und On = 1
• Das Node erhält einen zusätzlichen Output

Projektmanager und Abfrage “Fenster wie zuletzt laden” erscheinen u.U. nicht auf dem gleichen Monitor wie die GUI.
Weil man z.B. während dem Laden irgendwas anderes am PC macht geht wahrscheinlich der Fokus verloren.
Ich vermute die Fenster starten “CenterScreen” und nicht “CenterOwner”.
Letzteres erscheint mit sinnvoller, weil diese “MessageBoxes” ja nur im Kontext des Owners Sinn machen.

Installiert man DMXControl 3 auf einem weiteren PC komplett neu, erfolgt der erste Start mit allen Standardeinstellungen für die Anwendung selbst als auch bei den Vorgaben für ein neues Projekt. Auch sind keine DMX-Interfaces konfiguriert.

Grundsätzlich ist es möglich, die verschiedenen Konfigurationsdateien vom ersten PC auf den neuen PC zu kopieren. Einfacher wäre es, wenn DMXControl 3 hier mit einer Export- und Importfunktion unterstützt, wie es auch andere Programme machen. Über diese Funktion könnte man sich dann auch so zwischendurch ein Backup seiner Einstellungen machen.

Beim Hinzufügen von Geräten zur Bühnenansicht in 3.3.0 RC2 beginnt das Plot-Layout beim Verschieben oder Auffächern von Gruppen ausgewählter Geräte, alle Geräte zufällig für unendlich im Plot zu verteilen, selbst wenn Maus und Ziehen losgelassen werden. Diese Funktion ist in 3.2.3 vollständig stabil. Wie immer erwähnt, ziehen Sie bitte die dedizierte 64-Bit-Art-Net/sACN-Versionsarchitektur in Betracht, um die vollen Fähigkeiten von DMXC zu nutzen. Vielen Dank!

When adding fixtures to stage view in 3.3.0 RC2, when moving or fanning groups of selected fixtures, the plot layout will start to randomly scatter all the fixtures around the plot for infinity, even after mouse and dragging is released. This feature is completely stable in 3.2.3. As will always mention, please consider 64 bit dedicated Art-Net / sACN version architecture to utilize full capabilities of DMXC. Thank you!

Show-Dateien werden immer größer und so leistungsfähig DMXC auch ist, es ist stark eingeschränkt, wenn es eine 32-Bit-Architektur bleibt. Das Programm beginnt zu verzögern und wird bei großen Mengen an Geräten und Programmen sehr, sehr langsam. Bitte ziehen Sie eine Version ohne Ausgabe-Plugins außer Art-Net und sACN in Betracht, um die volle 64-Bit-Architektur zu nutzen. Bitte erwägen Sie auch, Unterstützung für Easy View 2 Visualizer einzuschließen.

Show files are becoming larger and as powerful as DMXC is, it is severely limited by remaining a 32 bit architecture. Program will begin to lag and become very very slow with large amounts of fixtures and programming. Please consider a version without a need for output plugins except Art-Net and sACN to utilize full 64 bit architecture. Also please consider including support for Easy View 2 visualizer.

Ändere ich insbesondere die Konfiguration der DMX-Interfaces, muss ich danach beim weiteren Arbeiten darauf achten, dass Kernel und GUI ordnungsgemäß beendet werden. Denn diese Daten werden bekanntermaßen ausschließlich beim Beenden gesichert. Hängt sich der Kernel oder die GUI auf, kann die Änderung nicht mehr gespeichert werden. Folglich sind die getätigten Änderungen beim Neustart erneut vorzunehmen.

Um dies zu umgehen wäre mein Vorschlag, die Daten für die Programm- und insbesondere für die Interface-Konfiguration nach einer Änderung bei der nächsten manuellen Sicherung des Projekts ebenfalls zu speichern.

Aktuell muss ich den Wiedergabemarker an eine bestimmte Position setzen, um die exakte Zeit an dieser Stelle herauszufinden.

Ich persönlich fände es hilfreich, wenn mir fortlaufend auch die aktuelle Position der Maus selbst in der Zeitachse als Zeitwert angezeigt werden würde.

In meinem aktuellen Showprojekt kann ich die Timecodes-Show nicht mehr mitten im Song starten, wenn hier bereits eine gewisse Zeit vergangen und / oder eine gewisse Anzahl an Cues abzuwarbeiten waren. Konkret bedeutet das, dass beim Start im Song um die 40. Cue bei 1:31.000 die unten stehende Exception fliegt. Dies hat zur Folge, dass die betreffende (Haupt-) Cuelist der Show nicht mehr auf den vom Timecode-Player verschickten Timecode reagiert und damit nicht mehr ausgegeben wird. Hier muss ich das Projekt einmal komplett neu laden, damit die vollständige Wiedergabe inklusive dieser (Haupt-) Cuelist funktioniert. Andere Cuelists werden aber noch mit dem Timecode gefüttert.

16:02:23 ERROR ThreadManager - Thread TimecodeSceneTrigger exited ThreadStart-Method with Exception: 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.SceneList.ValuesStack.OutputValuesStack.ApplyTimings(OutputValueItem item, Int64 timeOffset, Boolean fadeIn, FadeDelayTimings timings, PropertyFadeDelayTimings propertyTimings, Int32 sourceIndex, Int32 destIndex, EGotoOptions options, Nullable`1 valueNew) in D:\Jenkins\workspace\Lumos_Pipeline_3.3\Lumos\src\Kernel\SceneList\ValuesStack\OutputValuesStack.cs:line 519
   at org.dmxc.lumos.Kernel.SceneList.ValuesStack.OutputValuesStack.FadeItem(OutputValueItem item, Int64 timeOffset, Boolean fadeIn, FadeDelayTimings timings, PropertyFadeDelayTimings propertyTimings, Boolean clone, Int32 sourceIndex, Int32 destIndex, EGotoOptions options, Nullable`1 newValue) in D:\Jenkins\workspace\Lumos_Pipeline_3.3\Lumos\src\Kernel\SceneList\ValuesStack\OutputValuesStack.cs:line 514
   at org.dmxc.lumos.Kernel.SceneList.ValuesStack.OutputValuesStack.AdjustRunningTimings(FadeDelayTimings timings, PropertyFadeDelayTimings propertyTimings, Int64 timeOffset, IDictionary`2 toPlayValues, IDictionary`2 toFadeoutValues, Int32 sourceIndex, Int32 destIndex, EGotoOptions options) in D:\Jenkins\workspace\Lumos_Pipeline_3.3\Lumos\src\Kernel\SceneList\ValuesStack\OutputValuesStack.cs:line 651
   at org.dmxc.lumos.Kernel.SceneList.ValuesStack.OutputValuesStack.goToForward(Int32 destindex, Int32 sourceIndex, EGotoOptions options, Int64 timeOffset, FadeDelayTimings timings, PropertyFadeDelayTimings propertyTimings) in D:\Jenkins\workspace\Lumos_Pipeline_3.3\Lumos\src\Kernel\SceneList\ValuesStack\OutputValuesStack.cs:line 224
   at org.dmxc.lumos.Kernel.SceneList.ValuesStack.OutputValuesStack.goTo(Int32 index, EGotoOptions options, Int64 timeOffset, FadeDelayTimings timings, PropertyFadeDelayTimings propertyTimings) in D:\Jenkins\workspace\Lumos_Pipeline_3.3\Lumos\src\Kernel\SceneList\ValuesStack\OutputValuesStack.cs:line 146
   at org.dmxc.lumos.Kernel.SceneList.SceneList.playSceneForward(IScene newScene, Int32 oldIndex, Int64 newSceneOffset, ETriggerReason reason, FadeDelayTimings timings, PropertyFadeDelayTimings propertyTimings, EGotoOptions options) in D:\Jenkins\workspace\Lumos_Pipeline_3.3\Lumos\src\Kernel\SceneList\SceneList.cs:line 1601
   at org.dmxc.lumos.Kernel.SceneList.SceneList.playScene(Int32 newIndex, Int32 oldIndex, Int64 newSceneOffset, ETriggerReason reason) in D:\Jenkins\workspace\Lumos_Pipeline_3.3\Lumos\src\Kernel\SceneList\SceneList.cs:line 1529
   at org.dmxc.lumos.Kernel.SceneList.SceneList.SceneTrigger_SceneTriggered(Object sender, TriggerEventArgs args) in D:\Jenkins\workspace\Lumos_Pipeline_3.3\Lumos\src\Kernel\SceneList\SceneList.cs:line 1786
   at org.dmxc.lumos.Kernel.Scene.Trigger.AbstractSceneTrigger`1.triggerScene(SceneBag`1 bag, Boolean removeRunning, ETriggerReason reason) in D:\Jenkins\workspace\Lumos_Pipeline_3.3\Lumos\src\Kernel\Scene\Trigger\AbstractSceneTrigger.cs:line 284
   at org.dmxc.lumos.Kernel.Scene.Trigger.TimecodeSceneTrigger.triggerScenesByTimecode(Int64 actualTC, Int64 newTC) in D:\Jenkins\workspace\Lumos_Pipeline_3.3\Lumos\src\Kernel\Scene\Trigger\TimecodeSceneTrigger.cs:line 151
   at org.dmxc.lumos.Kernel.Scene.Trigger.TimecodeSceneTrigger.timecodeThreadRun(RunContext ctx) in D:\Jenkins\workspace\Lumos_Pipeline_3.3\Lumos\src\Kernel\Scene\Trigger\TimecodeSceneTrigger.cs:line 128
   at org.dmxc.lumos.Kernel.Run.ThreadWrapper.WrappedStart() in D:\Jenkins\workspace\Lumos_Pipeline_3.3\Lumos\src\Kernel\Run\Thread\ThreadWrapper.cs:line 213

Das Projekt stelle ich bei Bedarf intern zur Verfügung.

In meinem Showprojekt für das Jahrestreffen musste ich feststellen, dass bestimmte Cuelists mit Timecode-Trigger nach einiger Zeit unsauber wiedergegeben werden. Dies ließ sich sowohl in der StageView als auch in der DMX-Ausgabe real an den Geräten beobachten. Die gewünschten Effekte sehen damit mit zunehmender Wiedergabedauer der Timecodeshow deutlich merklich anderes aus als noch zu Beginn bei den ersten Aufrufen der entsprechenden Cuelists.

Die betreffenden Cuelists sind in dieser besagten Version mehrfach zwei verschiedenen Cuelist-Tracks zugeordnet.

Nachdem ich Cuelists auf die eigenständige Wiedergabe mittels Wait- / Follow-Trigger umgebaut und diese dann über entsprechende Special Cues aufrufe, laufen die Effekte über die komplette Wiedergabe-Dauer der Timecode-Show wie erwartet.

Anmerkung: Das in diesem Ticket beschriebene Phänomen zeige ich am besten live mit der realen Ausgabe und mache dann ggf. auch ein kurzes Video. Dem entsprechend werde ich Projekt und Logs später nachreichen. Die betreffende Version ist gesichert.