Bugtracker DMXControl 3

Bei den meisten LED-Scheinwerfern gibt es einen DMX-Kanal, über den man verschiedene Farbmakros / Farbpresets abrufen kann. Geräte in der Preisklasse für (semi-) professionellen haben hier mittlerweile auch mehrere DMX-Kanäle, um Farbmakros / Farbpresets aufrufen zu können und zwar für:

• verschiedene (bunte) Farben mit festen Schritten
• verschiedene Presets für weiß in unterschiedlichen Farbtemperaturen mit festen Schritten
• einen linearen Übergang von warmweiß zu kaltweiß (lineares CTO-Farbpreset)

Alle DMX-Kanäle für die Farbmakros haben gemeinsam, dass immer nur einer von ihnen tatsächlich ausgegeben werden kann und dabei die Werte der RGB-Farbmischung geräteintern überschrieben werden. Aus dieser Entwicklung ergeben sich folgende Problemstellungen, die DMXC aktuell nicht wirklich abbilden kann:

• Hat ein LED-Scheinwerfer mehrere DMX-Kanäle für Farbpresets, kann nicht exklusiv zwischen ihnen gewechselt werden. Implementiert man auf dem bisherigen Weg mehrere DMX-Kanäle als virtuelles Farbrad, möchte DMXC die Farben der verschiedenen Farbräder miteinander vermischen.
• Möchte man den DMX-Kanal für ein lineares Farbpreset einbauen, ist der beste Weg aktuell eigentlich nur über “colortemp”. Bei “colortemp” geht DMXC aber davon aus, dass es sich um einen Filter handelt statt wie so häuft um ein Farbpreset. Folglich wird der Wert aus “colortemp” mit dem aktuellen RGB-Wert verrechnet statt exklusiv auf den DMX-Kanal für das lineare CTO-Farbpreset umzuschalten.

Daher sollte das Ziel sein, DMXC mitteilen zu können, ob es sich bei dem jeweiligen DMX-Kanal um einen DMX-Kanal für ein Farbpreset handelt oder einen klassischen Farbfilter / Farbrad handelt. Bei als Farbpresets gekennzeichnete DMX-Kanäle würde ggf. implizit vorausgesetzt werden, dass immer nur einer von dieses DMX-Kanälen vom Gerät ausgegeben wird. Damit könnte automatisch das Problem umgangen werden, falls die verschiedenen DMX-Kanäle für die Farbpresets wie im Fall des ADJ Encore LP7 IP geräteintern unterschiedliche Prioritäten haben.

Geräte, die aktuell über mehrere DMX-Kanäle verfügen und auf die die beschriebene Thematik zutrifft sind unter anderem:

• ADJ Encore LP7 IP
• Elation KL Panel
• Clay Paky Mini-B

siehe oben

Wenn ein Value negative Werte annehmen kann sollte die Füllung in der Darstellung nicht am Minimum ansetzen sondern bei 0. Wird der Wert negativ füllt sich die Darstellung von 0 nach unten.

Ich habe es nach langer Zeit mal wieder geschafft mich mit DMXC 3.3.2 zu befassen.
Hier bei wollte ich ein Connectionset kopieren.

Dann habe ich für das kopierte Set noch Input, Output und Interface Zuordnung angepasst, aber es hat nicht funktioniert.
Nach etwas suchen musste ich feststellen das die Einstellungen im Input Selector nicht mehr vorhanden waren, er war einfach leer.

Ich hätte eigendlich erwartet das die Einstellungen nach dem kopieren noch vorhanden sind.

Nach dem ich den Input Selector angepasst habe funktionierte es.

Bilder zur Veranschaulichung im Anhang.

Gruß Steff

Man wendet beliebige Werte auf Gerätefunktionen einer Device Group an und speichert dies als Preset. Fügt man der Device Group nun weitere Geräte hinzu oder ändert die Reihenfolge innerhalb der Device Group, wird dies vom Preset nicht berücksichtigt. Würde man die gleichen Werte in eine Cue speichern, berücksichtigt die Cue die Änderungen innerhalb der Device Group. Folglich verhalten sich Presets nicht konsistent wie es sonst von Cues bekannt ist.

Dieses Ticket wurde inhaltlich ausführlich geschildert und besprochen. Es dient daher vornehmlich der Dokumentation der Änderungshistorie für eine zukünftige Version.

Folgender Ablauf führt zu dem angehängten Problem:

1. Einer Gruppe wird eine Farbe und ein Dimmerwert gegeben
2. Einem einzelnen Scheinwerfer aus der Gruppe wird eine andere Farbe gegeben
3. Der Programmer wird geleert
4. Die Gruppe wird ausgewählt und das Preset wird angewendet
5. Diese Lichtstimmung wird in einer Cue gespeichert
6. Das Preset wird im Programmer bearbeitet und die Werte für den separaten Scheinwerfer werden gelöscht
7. Der aktuelle Programmer-Inhalt wird in das bestehende Preset gemerged, welches im Programmer editiert wird

Erwartetes Verhalten:
Die Ansicht im Preset-Window wird aktualisiert und zeigt nun den richtigen Inhalt an

Tatsächliches Verhalten:
Der Preset-Eintrag zeigt weder enthaltene Geräte noch Properties

Folgender Ablauf führt zu dem angehängten Problem:

1. Einer Gruppe wird eine Farbe und ein Dimmerwert gegeben
2. Einem einzelnen Scheinwerfer aus der Gruppe wird eine andere Farbe gegeben
3. Der Programmer wird geleert
4. Die Gruppe wird ausgewählt und das Preset wird angewendet
5. Diese Lichtstimmung wird in einer Cue gespeichert
6. Das Preset wird im Programmer bearbeitet und die Werte für den separaten Scheinwerfer werden gelöscht
7. Das Preset wird über den Update-Button aktualisiert

Erwartetes Verhalten:
Aktualisierung des Presets funktioniert und alle Scheinwerfer zeigen nun Farbe der Gruppe, wenn die Cue ausgeführt wird

Tatsächliches Verhalten:
Das Preset kann nicht aktualisiert werden, da Referenzen in der Cue nicht korrekt aktualisiert werden können

Hallo,
In dem Menue für Label kann ich Custom (was eigenes) oder Clock (Uhr) auswählen.
Ist es möglich das um Date (Datum) zu erweitern.

Gruß Steff

Fehlerbeschreibung

Erwartetes Verhalten

Hallo alle zusammen,
mir schwebt da so seit einiger Zeit eine Abwandlung eines vorhandenen Effekts für die Matrix durch den Kopf.
Es geht im Endeffekt um den schon vorhandenen Color Scroll. Diesen eventuell erweitern oder so abgewandelt als zusätzlichen Effekt. Im Device Control kann man das so schon sehen, deshalb bin ich auch auf die Idee gekommen.

So wie es jetzt ist, ist es ja so wenn ich mehrere verschiedene Bewegungsrichtungen (Direction) nacheinander verwenden möchte, muß man natürlich mehrere Cues in eine Cueliste packen.
Hier sind aber Übergänge nicht so schön.

Meine Idee für die Übergänge wäre, das man als zusätzliche Option in diesem besonderen Color Sroll, das der Wechsel zwischen den Bewegungsrichtungen (Direction) im Color Sroll definiert werden kann. Man könnte hier anklicken welche Richtungen verwendet werden sollen und nach welcher Zeit oder Durchläufe der Übergang gemacht wird. Eventuell kann die Reihenfolge auch auf Linear (Ablauffolge einstellen ?) oder Random gestellt werden.

Wozu das ganze:
Wenn man jetzt im Device Control die Einstellungen für die Bewegungsrichtung (Direction) ändert, rutscht das nun eingestellte so da rein, über das vorherige. Diese Übergänge sehen sehr viel interessanter und schöner aus. Probiert es einfach mal aus.

Gruß Steff

Ich habe folgende Definition erstellt:

<cmy>
  <cyan dmxchannel="3"/>
  <magenta dmxchannel="4"/>
  <yellow dmxchannel="5"/>
</cmy>
<colorwheel dmxchannel="7">
  <step type="enableRGB" mindmx="0" maxdmx="0"/>
  <step type="color" val="L007" mindmx="1" maxdmx="1"/>
  <step type="color" val="L103" mindmx="2" maxdmx="2"/>
  ...
  <wheelrotation>
    <range type="cw" mindmx="201" maxdmx="180" minval="0.1" maxval="8"/>
    <step type="stop" mindmx="202" maxdmx="207"/>
    <range type="ccw" mindmx="208" maxdmx="229" minval="0.1" maxval="8"/>
  </wheelrotation>
  <random>
    <step type="fast" mindmx="235" maxdmx="239"/>
    <step type="medium" mindmx="240" maxdmx="244"/>
    <step type="slow" mindmx="245" maxdmx="249"/>
  </random>
</colorwheel>

Die Umschaltung vom virtuellen Farbrad zurück zu CMY funktioniert aber so nicht, weil der Wert “enableRGB” die CMY-Mischung nicht berücksichtigt. Daher wäre meine Erwartungshaltung:

• entweder wird hier eine entsprechende Unterstützung für virtuelle Farbräder in Kombination mit CMY und HSV ergänzt
• für die anderen Farbmischungen werden eigene Werte ergänzt

Fehlerbeschreibung

Erwartetes Verhalten

Ich füge ein Gerät mit einer Auflösung für die Farbmischung mit 16 bit einem leeren Projekt hinzu wie zum Beispiel dem Robe LEDBeam 150 im Mode 1.

Bewege ich den Punkt mit der Maus und schaue mir die Werte in der Kanalübersicht an, sehe ich, dass die DMX-Werte sowohl für 8 bit als auch 16 bit parallel ein- und ausfaden - der DMX-Kanal für 16 bit verhält sich wie der DMX-Kanal für 8 bit. Gleiches passiert auch, wenn ich im Device Control die Regler für RGB, CMY oder HSV direkt im Dropdown unter Color nutze.

Benutze ich die Regler für die einzelnen Farben, verhält sich die DMX-Ausgabe so wie ich es für 16 bit erwarte. Gleiches gilt auch für das Position Control oder den Regler für Dimmer im Intensity Panel. Daher wäre es gut, wenn der Color Picker im Color Panel sich gleichermaßen verhalten und am Ende die DMX-Werte für die Fine-Channel nach dem bekannten Muster ausgegeben werden.

Fehlerbeschreibung

Erwartetes Verhalten

Zusätzlich zur aktuellen Duration Funktion sollte es eine Triggerzeit z.b. 3000 geben. Dann würden alle 3 Sekunden ein Schritt weitergeschaltet, unabhängig davon, ob die Haltzeit sowie Ein- und Ausblendzeit des vorherigen Schrittes abgelaufen ist.

(Übertrag aus Ticket  FS#303 )

DMXControl 3 besitzt im Projekt Explorer die Funktion, dass Einträge auch auf die ExecutorPage gezogen werden können. Dann werden mehrere Executoren mit den passenden Inhalten angelegt. Dies funktioniert auch, wenn der Executor beim Laden des Projekts leer war. Wenn er jedoch bereits einen Member enthalten hatte, wird der Inhalt der Buttons und des Faders nicht korrekt aktualisiert. Dann werden die Standard-Elemente des MemberWrappers eingefügt und nicht die spezifischen Elemente, die durch das Hinzufügen auf die ExecutorPage vorgegeben werden.

I’ve noticed a cuelist behaviour that seems incorrect

I have a cuelist (we’ll call this the master cuelist), and within that cuelist, I am triggering some other cuelists (we’ll call these sub-cuelists) using the ‘Go’ and ‘Stop’ special cues.

If I use the ‘Go to’ function to jump to a later point in the master cuelist after I have triggered a ‘go’ and then a ‘stop’ on a sub-cuelist, that sub-cuelist remains playing when I believe it should be stopped.

So in the attached example screenshot, if I “Go To” cue 17, I would expect the ‘Petro Alts’ and ‘Petro Zips’ cuelists to be stopped, but instead they are running.

If I play the cuelist from the start, they behave as expected.

Verwende ich beim TCP die Executoren, dann werden alle Knopfdrücker etc. einmal ausgeführt, die vor dem Marker gesetzt sind. Das Sorgt dafür, wenn man 20x nen Trigger gesetzt hat, wird auch 20x dieser ausgelöst. Was zum einen den GUI in die Knie zwingt, als auch unschön bei der DMX Ausgabe ist

Meiner Meinung nach müsste man die Executoren nicht triggern, sondern erst ab dem Zeitpunkt wo man den TCP startet

Folgendes Vorgehen:
Einen Colormaster anlegen, im Input-Assigment über Item-List (Colorlist) und List-Selector die Farbe an den Colormaster geben. Wähle ich nun GoTo auf diese Cue aus wird die Farbe des Colormaster hart gesetzt. Im normalen Ablauf der Cuelist wird gefadet.
Nehme ich die Color aus dem List-Selector, wandle sie nach RGB und wieder zurück nach Color und gebe das an den Colormaster wird er auch bei GoTo korrekt gefadet.
Anbei ein Beispiel-Projekt. Colormaster 1 wird direkt über den ListSelector gesetzt, Colormaster 2 über die Wandlung. CM 1 fadet bei GoTo nicht, CM 2 fadet….

Fehlerbeschreibung

Erwartetes Verhalten

Hinweise

20:56:12 INFO  Timecode - Stopped: [1, New TimecodeShow]
20:56:13 ERROR Timecode -
org.dmxc.lumos.Kernel.Exceptions.AlreadyRegisteredException: Timeslot for ID 12b9c255-1f9f-4a2a-84f5-b9822edec50a-TS already registered
   at org.dmxc.lumos.Kernel.Time.TimeManager.registerFixedTimeSlot(String targetId, ITimeSlot timeSlot) in D:\Jenkins\workspace\Lumos_Pipeline_3.3\Lumos\src\Kernel\Time\TimeManager.cs:line 89
   at org.dmxc.lumos.Kernel.Timecode.Timecode.Play() in D:\Jenkins\workspace\Lumos_Pipeline_3.3\Lumos\src\Kernel\Timecode\Timecode.cs:line 919
20:56:13 INFO  Timecode - Run:     [1, New TimecodeShow]
20:56:13 INFO  Timecode - Start:   [1, New TimecodeShow] Frame:     0
20:56:15 WARN  Timecode - Performing the Frame: 39 takes too much time, it exceeds the max. frame duration 191.4261ms >= 40ms
20:56:19 WARN  Timecode - Performing the Frame: 139 takes too much time, it exceeds the max. frame duration 169.6493ms >= 40ms
20:56:24 WARN  Timecode - Performing the Frame: 263 takes too much time, it exceeds the max. frame duration 155.5815ms >= 40ms
20:56:26 INFO  Timecode - Break:   [1, New TimecodeShow] Frame:   319 Time: 00:00:12.7770985
20:56:41 INFO  Timecode - Stop:    [1, New TimecodeShow] Frame:   319 Time: 00:00:13.5876047
20:56:41 INFO  Timecode - Stopped: [1, New TimecodeShow]
20:56:43 ERROR Timecode -
org.dmxc.lumos.Kernel.Exceptions.AlreadyRegisteredException: Timeslot for ID 12b9c255-1f9f-4a2a-84f5-b9822edec50a-TS already registered
   at org.dmxc.lumos.Kernel.Time.TimeManager.registerFixedTimeSlot(String targetId, ITimeSlot timeSlot) in D:\Jenkins\workspace\Lumos_Pipeline_3.3\Lumos\src\Kernel\Time\TimeManager.cs:line 89
   at org.dmxc.lumos.Kernel.Timecode.Timecode.Play() in D:\Jenkins\workspace\Lumos_Pipeline_3.3\Lumos\src\Kernel\Timecode\Timecode.cs:line 919
20:56:43 INFO  Timecode - Run:     [1, New TimecodeShow]
20:56:43 INFO  Timecode - Start:   [1, New TimecodeShow] Frame:     0
20:56:44 WARN  Timecode - Performing the Frame: 39 takes too much time, it exceeds the max. frame duration 202.5471ms >= 40ms
20:56:48 WARN  Timecode - Performing the Frame: 139 takes too much time, it exceeds the max. frame duration 183.8875ms >= 40ms
20:56:49 INFO  Timecode - Break:   [1, New TimecodeShow] Frame:   182 Time: 00:00:07.2996301
20:56:50 INFO  Timecode - Resume:  [1, New TimecodeShow]
20:56:53 WARN  Timecode - Performing the Frame: 264 takes too much time, it exceeds the max. frame duration 195.172ms >= 40ms
20:56:56 INFO  Timecode - Break:   [1, New TimecodeShow] Frame:   335 Time: 00:00:13.3854502
20:56:58 INFO  Timecode - Stop:    [1, New TimecodeShow] Frame:   335 Time: 00:00:13.5248318
20:56:58 INFO  Timecode - Stopped: [1, New TimecodeShow]
20:56:59 ERROR Timecode -
org.dmxc.lumos.Kernel.Exceptions.AlreadyRegisteredException: Timeslot for ID 12b9c255-1f9f-4a2a-84f5-b9822edec50a-TS already registered
   at org.dmxc.lumos.Kernel.Time.TimeManager.registerFixedTimeSlot(String targetId, ITimeSlot timeSlot) in D:\Jenkins\workspace\Lumos_Pipeline_3.3\Lumos\src\Kernel\Time\TimeManager.cs:line 89
   at org.dmxc.lumos.Kernel.Timecode.Timecode.Play() in D:\Jenkins\workspace\Lumos_Pipeline_3.3\Lumos\src\Kernel\Timecode\Timecode.cs:line 919
20:56:59 INFO  Timecode - Run:     [1, New TimecodeShow]
20:56:59 INFO  Timecode - Start:   [1, New TimecodeShow] Frame:     0
20:57:00 WARN  Timecode - Performing the Frame: 39 takes too much time, it exceeds the max. frame duration 158.7684ms >= 40ms
20:57:04 WARN  Timecode - Performing the Frame: 139 takes too much time, it exceeds the max. frame duration 179.8303ms >= 40ms
20:57:07 INFO  Timecode - Break:   [1, New TimecodeShow] Frame:   236 Time: 00:00:09.4463131
20:57:08 INFO  Timecode - Resume:  [1, New TimecodeShow]
20:57:09 WARN  Timecode - Performing the Frame: 264 takes too much time, it exceeds the max. frame duration 165.9721ms >= 40ms
20:57:12 INFO  Timecode - Break:   [1, New TimecodeShow] Frame:   328 Time: 00:00:13.1409705
20:57:13 INFO  Timecode - Stop:    [1, New TimecodeShow] Frame:   328 Time: 00:00:19.0884693
20:57:13 INFO  Timecode - Stopped: [1, New TimecodeShow]
20:57:15 ERROR Timecode -
org.dmxc.lumos.Kernel.Exceptions.AlreadyRegisteredException: Timeslot for ID 12b9c255-1f9f-4a2a-84f5-b9822edec50a-TS already registered
   at org.dmxc.lumos.Kernel.Time.TimeManager.registerFixedTimeSlot(String targetId, ITimeSlot timeSlot) in D:\Jenkins\workspace\Lumos_Pipeline_3.3\Lumos\src\Kernel\Time\TimeManager.cs:line 89
   at org.dmxc.lumos.Kernel.Timecode.Timecode.Play() in D:\Jenkins\workspace\Lumos_Pipeline_3.3\Lumos\src\Kernel\Timecode\Timecode.cs:line 919
20:57:15 INFO  Timecode - Run:     [1, New TimecodeShow]
20:57:15 INFO  Timecode - Start:   [1, New TimecodeShow] Frame:     0
20:57:15 WARN  Timecode - Performing the Frame: 39 takes too much time, it exceeds the max. frame duration 188.1449ms >= 40ms
20:57:19 WARN  Timecode - Performing the Frame: 139 takes too much time, it exceeds the max. frame duration 165.4547ms >= 40ms
20:57:24 WARN  Timecode - Performing the Frame: 264 takes too much time, it exceeds the max. frame duration 177.6584ms >= 40ms
20:57:26 INFO  Timecode - Break:   [1, New TimecodeShow] Frame:   298 Time: 00:00:11.9164152
20:57:27 INFO  Timecode - Stop:    [1, New TimecodeShow] Frame:   298 Time: 00:00:17.0859307
20:57:27 INFO  Timecode - Stopped: [1, New TimecodeShow]
20:57:29 ERROR Timecode - 

Direkt nach dem Laden eines Projekts, wenn hier bereits ein Gerät / eine Gerätegruppe selektiert ist, kann es in manchen Fällen vorkommen, dass die Property Panel (Intensity, Color, PositionControl,…) nicht auf Änderungen im Programmer reagieren. Erst nach einem deselektieren und erneuten selektieren der Gruppe / des Geräts funktioniert das Update des Panels korrekt. Die Panel hängen sich erfolgreich auf die jeweiligen ProgrammerValueChanged Events der jeweiligen IDevicePropertyFacade. Allerdings wird das Event wenn diese Race Condition auftritt nie gefeuert.

Wenn im Programmer Filter das Erstellen von Presets aktiviert ist, sollte eine zusätzliche Textbox erscheinen, in der man den Namen des zu erstellenden Presets eingeben kann (Name wird u.U. durch DMXC um Nummerierung ergänzt).

Fehlerbeschreibung

Erwartetes Verhalten

Fehlerbeschreibung

Erwartetes Verhalten

Hinweise

Hallo,
Ich verwende DMXC 3.3.1 und habe zum testen eines Gerätes Werte in der Channel Overview eingestellt.
Ausgabe passiert hier in Universum 12 über ArtNet.
Soweit so gut.
Lasse ich diese Werte stehen und beende das Program, werden über ArtNet diese Werte immer noch weiter ausgegeben.

Werden über den Programmer oder über Cuelisten Werte ausgegeben werden diese “ordnungsgemäß” gelöscht.

Ich hätte erwartet das auch diese Werte wie bei der Verwendung vom Programmer und über Cuelisten zurückgesetzt werden.

Gruß Steff

Der Dreisatz-Knoten in der Eingangszuweisung ist ein super tolles Werkzeug, aber mangels Eingängen für die Min- und Max-Werte für Input und Output leider nicht dynamisch anpassbar.

Eine entsprechende Ergänzung wäre mega toll.

Haben Sie einen Fehler entdeckt? Dann nutzen Sie bitte folgendes Template und beachten die Hinweise für eine reibungsfreie Bearbeitung der Tickets.

Fehlerbeschreibung

Erwartetes Verhalten

Hinweise

Hi,

I would like to suggest an improvement to the way times are entered in the cuelist.

Currently, if I wanted to enter a time of 5 seconds 300 milliseconds for a wait cue, I would need to enter “5s300ms” which is quite awkward to type because it’s a mixture of numbers and letters. If I try to enter “5.3” this generates an error message “Trigger value not valid”.

Ideally, decimal numbers would be automatically turned into seconds and milliseconds. Eg “10.244” becomes “10s244ms”, and “0.123” becomes “123ms”.

I create a lot of time-based cuelists with a large number of ‘wait’ cues and it would be much quicker to be able to enter these values entirely on the numeric keypad rather than having to keep typing ‘s’ and ‘ms’ to denote seconds and milliseconds.

This should probably be consistent wherever times are entered - so the fade and delay values should also work the same way. (Currently fade times default to milliseconds but cue times default to seconds which is inconsistent.)

Fehlerbeschreibung

Erwartetes Verhalten

- ColorMaster im IA weiter steuerbar machen (Input für Zusatzfarben, sodass diese z.B. per Slider aus dem Softdesk direkt regelbar sind)
- Executoren für Zusatzfarben nutzbar machen

Bei Projekten mit vielen Cues, (Parameter-) Mastern, Geräten, ist es nur schwer möglich zu identifizieren wo die Master zugeordnet sind, gerade wenn keine eindeutige Beschreibung am Master vorgenommen wurde. Die Parameter lassen sich z. B. nicht löschen, so lange noch eine Zuordnung aktiv ist. Lediglich eine vorhandene Beschreibung, die vom Default abweicht, wird zurückgesetzt.

Daher wäre eine Möglichkeit hilfreich, um zu identifizieren, wo der Master verwendet wird (vielleicht ähnlich der Geräte und Cues).

Nach der Installation des DMXC 3.3.1-Release lies sich auf einem Windows 10-Notebook der Kernel nicht starten. GUI und Umbra liefen.
Das Kernel-Fenster zeigte nur die folgende Fehlermeldung:

It was not possible to find any compatible framework version
The framework 'Microsoft.NETCore.App', version '6.0.0' was not found.
  - The following frameworks were found:
      3.1.32 at [C:\Program Files (x86)\dotnet\shared\Microsoft.NETCore.App]
      5.0.17 at [C:\Program Files (x86)\dotnet\shared\Microsoft.NETCore.App]

You can resolve the problem by installing the specified framework and/or SDK.

The specified framework can be found at:
  - https://aka.ms/dotnet-core-applaunch?framework=Microsoft.NETCore.App&framework_version=6.0.0&arch=x86&rid=win10-x86

Nach der Installation des Frameworks aus dem Link in der Meldung funktionierte auch der Kernel.

Fehlerbeschreibung

Erwartetes Verhalten

Ich würde mir als arbeitsersparnis wünschen, wenn man in der Cuelist eine Cue mit rechtsklick “in programmer bearbeiten” editiert, sich das Programmerfenster automatisch öffnet (wenn es geschlossen ist) oder aktiviert/in den Vordergrund geholt wird.

Mir fällt kein Grund ein, warum ich eine Cue im Programmer bearbeiten wollen würde, ohne danach zum Programmer zu wechseln. Oder gibt es (überwiegend) Fälle, in denen das so ist?

Fehlerbeschreibung

Erwartetes Verhalten

Hinweise

Es braucht ein neues Fenster in DMXC, in dem die DDFs im Projekt verwaltet werden können. Damit soll es möglich sein, sowohl DDFs im Projekt zu aktualisieren, wenn diese auf dem PC neuer sind. Als auch DDFs auf den PC kopieren / aktualisieren, wenn diese im Projekt neuer sind. Dieses Fenster wird vor allem auch dadurch nötig, dass es jetzt nicht mehr so einfach die Möglichkeit gibt, diese aus dem Projekt herauszuziehen.

Wird die Netzwerkkonfiguration geändert, zum Beispiel wird die Statische IP/Subnetzmaske geändert, hängt der Kernel sich auf.

Discord: bastelpichi

Aktuell gibt es zwei Optionen ein Presets zu verwenden:

a) im Programmer laden
b) im Programmer editieren

Leider kann man das nicht so leicht unterscheiden ob man gerade editiert oder das preset verwendet und als Referenz in einer Cue verwendet.

Da wäre es praktisch, wenn man im Presetfenster visualisieren könnte, ob das Preset bearbeitet wird.

Die Werte des Faders des Cuelist Group Executors werden beim Laden eines Projekts nicht wiederhergestellt. Entweder werden diese nicht korrekt gespeichert oder nicht korrekt geladen (noch nicht untersucht).

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.