Bugtracker DMXControl 3

Hallo,
ich schreibe dies als Zusatz zu dem Ticket  FS#4433  Ausprobiert in der 3.3.0 Beta 7

Hier war es je so das, eigene Images die als Gruppen Bilder verwendet wurden nicht mit im Projekt gespeichert wurden.
Dies ist ja jetz behoben. Man kann mit dem Projekt umziehen und hat alles parat.

Was mir in dem Zusammenhang heute aufgefallen ist:
Ändert man diese Gruppen Bilder und verwendet die vorherigen nicht mehr, werden diese aber nicht aus dem Projekt entfernt.
Ich kann diese immer noch auswählen und verwenden.
Obwohl diese nicht mehr auf der Festplatte vorhanden sind.

Dies erzeugt Datenmüll und bläst das Projekt künstlich auf.

Man hat ja auch keine Möglichkeit das selber irgend wie aus dem Projekt zu entfernen.

Ich würde erwarten das diese, nicht mehr verwendeten, Dateien aus dem Projekt automatisch entfert werden oder das man wenigstens gefragt wird ob diese aud dem Projekt entfernt werden sollen.

Im Anhang ein Projekt das ich gerade begonnen habe.
Es geht um die Dateien:
4.png
4R.png
6.png
6R.png
8.png
8R.png
12.png
12R.png
Gruppe 2x2mp.png

Gruss Steff

Ich habe nach der Beschaffung von Geräten mit einem RGBL-Chip (rot, grün, blau und lime) festgestellt, dass das Konzept für die Ansteuerung von RGB+LEDs unvollständig ist - und zwar wenn es um das Mischen von Weiß geht.

Bei dem mir vorliegenden Gerät wird zum Beispiel ein “gutes” Weiß statt über RGB eben unter Zuhilfenahme der Lime-LED gemischt wird. Rot grün und blau sind dabei nicht auf Maximum. Nur durch eine solche Mischung kann ich softwareseitig den angegebenen Farbwiedergabeindex erreichen.

Die Optimalwerte können für ein “gutes” Weiß aber von Gerät zu Gerät abweichen. Daher ist es über die HAL zur Zeit in DMXControl 3 nicht möglich, für unterschiedliche Geräte nahezu die gleiche Farbe zu generieren.

Aus diesem Grund sollte die HAL und ggf. auch die DDFs eine Möglichkeit erhalten, die Farbausgabe dahingehend zu kalibrieren, dass man für die Farben optimale Werte erreicht.

Im Photo- und Videobereich wird dies zum Beispiel über so genannte Farbkarten realisiert, auf der eine gewisse Anzahl an definierten Farben enthalten sind. Der Videosoftware sind dabei die Farben bekannt. So kann das Photo-Videomaterial softwareseitig korrigiert und angeglichen werden. In dem folgenden Video wird dieser Punkt auch nochmal kurz vorgestellt: https://www.youtube.com/watch?v=M934d_P89pQ

Aktuell ist der zulässige Höchstwert für die Phase bei 1080° festgesetzt. Dieser ist mittlerweile zu gering und sollte hochgesetzt werden.

In diesem Zusammenhang wäre dieser Wert als zentrale Konstante zu definieren, statt ihn einzeln in den Effekten zu hinterlegen.

Ich habe an einem Projekt Änderungen vorgenommen, die auch vom DirtyFlag registriert wurden. Schließe ich dieses geänderte Projekt nun, ohne die Änderungen manuell gespeichert zu haben, sind meine Änderungen weg.

Daher sollte (wie bei anderen Programmen auch) die Abfrage erscheinen, ob getätigte Änderungen vor dem Schließen des Projekts noch gespeichert werden sollen.

Aus der Diskussion zwischen Arne und Jens-Peter geht hervor, dass die Abfrage muss an insgesamt vier Stellen erfolgen muss:

• Projekt schließen direkt in der Menüleiste
• Projekt schließen in der PA beim aktiven Projekt
• Beim Laden eines neuen Projekts
• Beim Laden eines neuen Projekts im Kernel über Komandozeilenabfrage

Im Falle der GUI steuert diese den Prozess selbst und fragt den Status des DirtyFlag ab.

Aktuell umfasst das Standard-Layout von DMXC 3.2.3 unten rechts nur das Preset-Fenster. Hier sollte aus folgenden Gründen eine Anpassung des Standard-Layouts vorgenommen werden:

• Die Presets sind sinnvoll, sollten aber nicht direkt als erstes genutzt werden.
• Das Effects und Filters wird mehrheitlich immer mit als Fenster geöffnet und dann über das Preset-Fenster gelegt.

Daher sollte das Standard-Layout wie im Screenshot gezeigt um das Effects und Filters Fenster ergänzt werden, was sich das Panel gemeinsam mit dem Preset-Fenster teilt.

Der Timecode-Player erwartet, dass die im Cuelist-Track verwendeten Cuelists bei allen Cues mit dem Timecode-Trigger versehen sind. Dies schließt auch die Cuelist Defaults ein.

Daher sollten die Defaults für neue Cues auf Rückfrage automatisch aktualisiert werden, sobald man die Cuelist einem Cuelist-Track im Timecode-Player hinzufügt.

Füge ich eine zweite Audiodatei dem Audio-Track hinzu, so wird diese bei 0:00 positioniert. Dies hat dann zur Folge, dass ich die bereits im Audio-Track existierende Audiodatei nicht mehr verschieben kann.

Erst wenn eine bereits vorhandene Audiodatei so weit nach hinten geschoben habe, kann ich beide Audiodateien einzeln wieder verschieben. Aus diesem Grund sollten neue Audiodateien immer hinter die letzte Audiodatei eingefügt werden.

Ich würde mich über eine Möglichkeit freuen, den Wiedergabe-Marker schnell wieder wieder auf den Anfang zu setzen. Folgende Varianten wären einzeln oder auch in Kombination denkbar:

• In der Menüleiste wird ein zusätzlicher Button eingefügt.
• Der Wiedergabe-Marker wird bei einem Doppelklick auf den Startpunkt gesetzt, während ein einfacher Klick ihn auf den Punkt springen lässt, von wo die Wiedergabe zuletzt gestartet wurde.

Fehlerbeschreibung

Erwartetes Verhalten

Beobachtetes Verhalten

Hinweise

Was habe ich vor?

Was finde ich?

Was erwarte ich?

Hinweise

Fehlerbeschreibung

Erwartetes Verhalten

Hinweise

LOG

17:48:42 WARN  ProjectManager - Error when loading Project Temp\c1befaac-c720-475c-9bf3-383b87917310.tmp: Warnings in Project
ProjectLoad: WARNING: Loading Graphs in Project(null)ProjectLoad: WARNING: Unable to load Links in Graph in Copy of Connection set(null)org.dmxc.lumos.Kernel.Exceptions.ProjectLoadException: Warnings in Project
   bei org.dmxc.lumos.Kernel.Project.ProjectManager.loadProject(String filename, Stream inputStream, String sessionName, Boolean loadId) in D:\Jenkins\workspace\Lumos_Pipeline_3.2_2\Lumos\src\Kernel\Project\ProjectManager.cs:Zeile 341.
   bei org.dmxc.lumos.Kernel.Project.ProjectManager.loadProject(String filename, String sessionName) in D:\Jenkins\workspace\Lumos_Pipeline_3.2_2\Lumos\src\Kernel\Project\ProjectManager.cs:Zeile 227.
   bei org.dmxc.lumos.Kernel.Command.KernelCommandFactory.loadProject(String sessionName, String tmpFile) in D:\Jenkins\workspace\Lumos_Pipeline_3.2_2\Lumos\src\Kernel\Command\KernelCommandFactory.cs:Zeile 1419.
17:48:42 WARN  LumosTools - Loading Graphs in Project
17:48:42 WARN  LumosTools - Unable to load Links in Graph in Copy of Connection set
17:48:42 WARN  LumosTools - Loading Graphs in Project
17:48:42 WARN  LumosTools - Unable to load Links in Graph in Copy of Connection set
17:48:42 INFO  InputManager - Processing of Graph Copy of Connection set took 33ms

Ich habe die Tooltips in den Einstellungen deaktiviert. Gebe ich nun im Device Control einen nicht zulässigen Wert ein, werde ich hier weiterhin nicht darauf hingewiesen. Die GUI reagiert dabei so lange nicht, bis ich die Eingabe über Esc abbreche.

Mir ist heute ein Grafik-Fehler bbeim Umbenennen von Devices aufgefallen. Beim Umbenennen wird die Schrift im Project Explorer kleiner, so dass
am Ende noch ein Stück der alten Schrift stehen bleibt (siehe angehängter Screenshot). Das ist auch eher ein Schönheitsfehler und hat keinen Einfluß auf die Funktion.
Dies tritt auch nur bei längeren Namen auf.
Es gibt dazu auch keine Log-Einträge.

Die BPM Anzeige sohwohl in den Executoren und im Master fenster ist teilweise fehlerhaft. Fehler tritt mal auf, mal nicht. Details siehe Video im Anhang.

Wenn die Project Administration geöffnet wird, sollte der Fokus des Cursors direkt im Suchfeld sein, damit ich direkt einen Suchbegriff eingeben kann. Dadurch dass sich die Maus mit dem letzten Klick eher abseits von der Project Administration befindet, ist das Setzen des Cursors in das Suchfeld etwas umständlich.

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.

Beim noch einmal über FS#3974, FS#4870 nachdenken (im Rahmen von https://forum.dmxcontrol-projects.org/index.php?thread/16934-cuelist-freigabezeit-verz%C3%B6gerung-dimmer-farbwert ), kam mir folgende zusammenfassende Überlegung: Ideal wäre es, wenn man die Freigabe einer Cuelist generell als weitere Cue ansehen kann (mit allen daraus resultierenden Vor- und Nachteilen). Mit dieser Release-Cue hätte man einerseits die Möglichkeit FS#4870 umzusetzen. Da jede Cue eine Fade Time und eine Delay Time hat, wäre das hier einfach eingebbar. Man müsste noch überlegen, ob man hier auch ein Fanning zulässt wie das bei den Zeiten für andere Cues auch möglich ist. Aber tatsächlich hätte ich damit eigentlich kein Problem, denn dadurch verschiebt man eben nur den Zeitpunkt für einzelne Geräteeigenschaften, wann sie freigegeben werden. So würde dann auch der Cue Timing Editor funktionieren. Mehr noch kann man den Zeitpunkt der Freigabe der Cuelist dann noch feiner einstellen als bisher, denn dann gäbe es nämlich nicht nur “manual only”, “with go” und “when last cue ends”. Stattdessen kann man dann die ganz normalen Cue-Trigger für das Freigeben verwenden. Das einzige, was man überlegen müsste wäre, wie man “manual only” richtig abdeckt. Aber da dürfte eigentlich ein “No Trigger” Eintrag für diese Art von speziellen Cues reichen. So kann ich nie die Release-Cue triggern und die Cuelist nur beenden, wenn ich auf Stop klicke. Dann wir natürlich trotzdem die “Release-Cue” ausgeführt.

Als Folgeticket aus  FS#4552 

Aus den verschiedenen Master-Ordnern kann man das Masterfenster direkt mit einem gesetzten Filter öffnen, um zum Beispiel nur die Group Master oder nur die Parametermaster anzuzeigen.

Der Launcher kann aktuell nur eine Version erkennen, anzeigen und starten (im selben Ordner bzw. anhand des Registry-Eintrags). Sobald es mit DMXControl 3.3.1 auch offiziell möglich ist, mehrere Versionen parallel zu installieren (Installer packt dann Registry-Einträge von DMXC 3.3.1 in einen separaten Registry-Eintrag zur 3.3.0). Der Launcher muss einerseits diese neue Struktur unterstützen und andererseits so erweitert werden, dass er dann im Zweifelsfall mehrere DMXC-Versionen anzeigen kann.

s.o.
https://sixlabors.com/products/imagesharp/

Beim erfolgreichen Laden eines Projekts erscheint irgendwann eine Abfrage, ob das letzte Layout geladen werden soll. Zukünftig sollte diese Abfrage ein Dropdown umfassen, in dem alle im Projekt enthaltenen Layouts aufgeführt sind. Hier sollte das zuletzt geladene Layout vorausgewählt sein. Es sollte auch eine Möglichkeit geben, das Laden des Layouts abzubrechen. In Hinblick auf FS#4954 (was im Zuge dieser Integration auch umgesetzt werden kann) wäre gut, wenn es drei Optionen gäbe:

• Jedes Mal nachfragen (Ask) (Standardmäßig eingestellt)
• Immer das letzte Layout laden (Load always last Layout)
• Immer “Layout xyz” laden (Load always “Layout xyz”)
• Kein Layout laden (No Default Layout)

Die Abfrage kommt nur im ersten Fall hoch.

Wird ein Projekt erfolgreich geladen, erscheint die Abfrage, ob das vorherige Layout geladen werden soll. Diese Abfrage erscheint jedoch nur in der GUI, in der das Laden des Projekts ausgelöst wurde. Die Abfrage sollte jedoch in allen GUIs erscheinen. Hierfür bräuchte es einen gRPC-Call, der an alle GUIs geht. Dieser sollte dann die AskLoadProjectLayout Funktion im Window Manager ausführen. Die Project Administration soll dann entweder eine neue “AskLoadProjectLayoutInAllGUIs” Funktion oder direkt den gRPC-Call aufrufen.

Es wäre ganz schön wenn man entscheiden könnte ob das Theme mit im Layout abgespeichert werden soll.

Hintergrund wäre, das man zum Beispiel für ein Layout zum Programmieren das Standart (Hell) Theme verwendet.
Für die Show wäre dann dass Dark Theme besser.

Mann könnte dann mit umschalten der Layouts auch automatisch die Themes passend speichern und verwenden.

Man müsste dann nicht beides getrennt einstellen wenn man das anpassen möchte.

So, wie aktuell Projekte grün markiert werden, wenn sie geladen sind, sollte auch die geladene Version grün markiert werden, damit man dies direkt sieht.

Man kann im Input Assigment die Bänke mittels Drag&Drop sortieren.
Diese Sortierung wird nicht gespeichert und es wird auch kein Dirty Flag gesetzt.

Hallo,
bei mir funktioniert der One Shoot Trigger nicht. Ich beginne mit einem Lauflicht über 8 RGB PARs. Danach folgt die Cue mit dem One Shoot Trigger, gefolgt von einer Cue, die die PARs auf eine Farbe einfadet.
Wenn ich die List starte, wird die One Shoot Cue sofort auf gelb gesetzt und das Einfaden beginnt. Währenddessen kann man sehen, dass das Lauflicht läuft bis es von der dritten Cue überschrieben ist.
Es gibt keine Fehlermeldung, weswegen ich auch keine Screenshots beisteuern kann. Ich habe lediglich das letzte Log File und das Projekt zum Anhängen.

Gruß, Herbert

P.S.: Sorry, die untenstehende Verknüpfung war ein Versehen. Ich dachte hier fügt man Verknüpfungen zu anderen Trackern ein, und jetzt kann ich sie nicht mehr löschen

Lege ich zum Beispiel den Sparkle-Effekt auf die Farbe, kann ich pro Effekt immer nur eine Farbe bestimmen, mit der der Effekt arbeiten soll. Möchte ich ich mit mehreren Farben arbeiten, muss ich hierzu mehrere Effekte hinzufügen und diese jeweils einzeln parametrieren.

Um dies zu vereinfachen, könnte es an vielen sinnvoll sein, hier mit einer Color List zu arbeiten. Die gewählte Color List übergibt dann mehrere Farben an den Effekt.

Ich bin hier und in DMXC neu und habe zwei Ideen zur Erweiterung der Chaser-Funktion Lauflicht.

1.: Die vermutlich einfacher zu realisierende ist eine Einstellung wie oft der Lauf wiederholt werden soll.

2.: Ich weiß nicht, ob das im Chaser implementiert werden kann, oder ob dazu eine neue Funktion nötig ist.
Nach dem 1. Durchlauf des Lauflichts soll das letzte Segment weiterleuchten und der Lauf wieder von vorne beginnen. Aber nur bis zum vorletzten Segment, welches dann wieder weiterleuchtet. Und so weiter bis alle leuchten.

So zum Beispiel:

XOOO
OXOO
OOXO
OOOX
XOOX
OXOX
OOXX
XOXX
OXXX
XXXX

Das gleiche Prinzip auch mit fanning von oder zur Mitte und revers, sowie die gleichen Parameter wie beim aktuellen Chaser. (Version 3.2.3.373)

Ich hoffe, diese Beschreibung ist verständlich genug und auch der richtigen Kategorie zugeordnet. Ob ich’s mit anderen verknüpfen soll, weiß ich nicht, und deshalb lasse ich’s bleiben.

Folgender Test-Aufbau:
Softdesk, Colorbar mit Colormaster verdrahtet.
Colormaster mittels “Bitmap from Color” auf Button visualisert. Funktioniert wie erwartet. Lade ich das Projekt neu ist der Button wieder grau, der Colormaster hat weiterhin die zuvor eingestellte Farbe. Gleiches Verhalten wenn die Colorbar in “Bitmap from Color” verschaltet wird. In der 3.2.3. funktioniert dies noch einwandfrei.

Die Master können ja nun mit Hilfe des Display-Name individuell benannt werden.
Daher sollte in den Eigenschaften der Nodes der Display-Name und nicht weiterhin der Name angezeigt werden.

Einen beliebigen Effekt auf ein Gerät ziehen, anschließend editieren.
Dann in den Tab Effects wechseln, dort wird der Effekt angezeigt, allerdings mit den ursprünglichen Werten, die Änderungen werden nicht angezeigt.

Speichere ich den Effekt aus dem Effects-Tab ab wird er mit den korrekten Werten gespeichert.

Aktuell kann man ja jederzeit ein neues / anderes Projekt laden, was “ohne Rücksicht auf Verluste” so auch ausgeführt wird. Dem entsprechend können andere Projekte auch geöffnet werden, wenn eine Show, sprich eine Cuelist läuft.

Um hier ggf. das Bewusstsein zu schärfen, dass entweder sowohl mindestens eine Cuelist aktiv ist oder auch aktuell Werte im Programmer enthalten sind, könnte an dieser Stelle eine Rückfrage hilfreich sein. Diese Rückfrage taucht unter den zuvor genannten Kriterien auf, sobald man ein neues / anderes Projekt laden möchte.

Analog zu anderen Elementen im Project Explorer sollten Master mittels F2 umbenannt werden können.
Gemeint ist hier der Display-Name.
Wie eben in der Betatester-Runde besprochen eventuell die Spalten tauschen und den Display-Name als 1. Spalte setzen.

Das Pfeilkreuz (im hellen Theme blau, im dunklen Theme rot), um das Fenster zum Beispiel in die linke Hälfte bzw. rechte Hälfte zu verschieben, erscheint nur auf dem primären Monitor.

Werden Executoren gleich benannt werden diese im IA unter einem Element dargestellt, die einzelnen Elemte darin werden einfach doppelt in diesem Element angezeigt. Bild hierzu im Anhang.

Selbes Problem, nur noch schlimmer, entsteht wenn zwei Elemte in einem Softdesk gleich heißen, dann weden diese im IA nur noch als ein Element angezeigt, ich habe also zwei Fader im Softdesk aber im IA nur noch einen. Dies hat zur Folge, dass der eine Fader im IA den Output vom zu erst erstellten Fader im Softdesk bekommt, von dem anderen Fader bekommt man gar keinen Output mehr. Selbes Verhalten tritt auch bei Buttons aus dem Softdesk auf, habe mir nicht die Mühe gemacht alle Elemente zu testen, denke sollte aber ähnlich sein.

Logs sind im Anhang, vllt findet da ja jemand mehr als ich^^

Ich habe in meinem Connectionset sowohl das Device Group Node als auch das Group Master Node im Einsatz, die beide die gleiche Device Group referenzieren. Um nur einmal die gewünschte Device Group respektive Group Master auswählen zu müssen, wäre es hilfreich, wenn das Group Master Node als zusätzlichen Eingang die Device Group erhält.

Wenn ich das mir so überlege, gehe ich davon aus, dass jeder Timer-Node die Zeit für sich berechnet, insbesondere wenn er einen Blinken ausgeben soll. Dies hat auch zur Folge, dass über mehrere Connectionssets hinweg das Blinken asynchron abläuft.

Mit dem im folgenden beschriebenen neuen Node habe ich die Hoffnung, dass

• alle Buttons etc., die mit Hilfe des neuen Nodes blinken sollen, dies im gleichen Takt tun.
• durch eine zentrale Zeitvorgabe die Performance insgesamt steigt, weil ggf. nur noch auf Basis eines Wertevergleichs gearbeitet werden muss.

Der Node globale Timer bzw. die globale Uhr hat als Grundlage die Systemzeit. Von der lässt sich ableiten, alle wie viel Sekunden, Minuten oder Stunden der Ausgang auf True geschaltet wird. Die untere Grenze ist dabei abhängig, wie genau man an die Systemzeit herankommt - sprich ob ein kompletter Zyklus von minimal 2 Sekunden oder sogar schneller möglich ist.

Dem entsprechend ergeben sich folgende Ein- und Ausgänge sowie Parameter:

• Eingänge
  • Ein- / Aus (analog zum aktuellen Timer-Node)
• Ausgänge
  • True / False bzw. 0 / 1
  • Systemzeit
• Parameter
  • Zykluszeit oder Einschaltdauer

Es gibt ja aktuell in der 3.3 die Makros, was im Grunde nichts anderes als interne Variablen sind um vom Executor aus ins IA zu kommen.

Die Funktion die ich gerne hätte wäre eine andere Art von Makro.

Ich würde mir wünschen, wenn man Makros aufzeichnen kann, um über einen Knopf mehrere Executoren gleichzeitig abfeuern zu können. Wie das hier in der Software für die Blackmagic Switcher gezeigt wird:

https://youtu.be/ka3hXE30Imk

Auf record drücken, alle Knöpfe einmal drücken die in das Makro rein sollen und dann die Aufzeichnung beenden. Sobald man den Makro Knopf drückt, werden die Executoren in der Reihenfolge gedrückt.

Man könnte noch überlegen ob man timings da noch irgendwie mit einbauen möchte, ist aber glaube gar nicht nötig.

Folgendes Szenario. Man hat eine Palette an Cuelists, Parameter- und Colormaster als Baukastensystem zusammengestellt und möchte damit schnell zwischen verschiedenen Lichtstimmungen umschalten.
Aktuell ist das möglich, indem man Cuelisten baut, die wiederum andere Cuelisten starten, oder man baut im Input Assignment ein aufwändiges CS. Für den Livebetrieb etwas unpraktisch.

Deshalb wäre mir persönlich bei diesem Feature wenn es kommen sollte wichtig, dass man das mit wenigen Handgriffen machen kann.

Legt man eine neue Gobo Affinity an, kann es passieren, dass man erstmal wieder zurück in den Project Explorer zum Zweig Item Lists gehen muss, wenn man zum Beispiel das Anlegen einer entsprechenden Gobo List vergessen hat. Dieses Hin- und Herspringen könnte durch folgende Punkte ggf. vereinfacht werden:

• Das Dropdown-Menü erhält grundsätzlich einen Eintrag zum Anlegen einer neuen Gobo List
• Die gewählte Gobo List kann direkt aus dem Affinity Window heraus editiert werden, zum Beispiel über einen zusätzlichen Button am Ende der Zeile

Wählt man im Affinity window das Gobo aus, welches zu ersetzen ist, erhält man den Filter “Included in project”.

Dieser Filter sollte auch in allen anderen Image Selector Windows angeboten werden, um auf Wunsch das Auswählen von Gerätebildern oder Icons zu vereinfachen und zu beschleunigen. Dieser Filter ist aber Gegensatz zur Auswahl bei der Gobo Affinity standardmäßig deaktiviert.

Mit dem neuen Image selector kann man nach Gobos bzw. Bildern des Geräts suchen. Aktuell hat man als Suchkriterium “nur” den Dateinamen. Bei selbst geschriebenen DDFs ist das weniger problematisch, weil man da noch einen sprechenden Dateinamen für die Bilddateien vergeben kann.

Bei DDFs, die über den Installer oder die DDFLib ausgeliefert werden, erhalten die Bilddateien den neutralen Dateinamen. Sucht man ein bestimmtes Gobo eines bestimmten Geräts bzw. ein bestimmtes Gerät muss man effektiv immer einen Blick direkt ins DDF selbst werfen, um den geänderten Dateinamen herauszufinden.

Um die Suche zu vereinfachen wäre es hilfreich, wenn die Bilddateien zusätzliche Informationen wie Hersteller und Gerätezeichnung in Form von Meta-Daten erhalten würden.

Aktuell detektiert DMXControl 3 jeden Tastendruck, sollten diese Tasten im Input Assignment verwendet werden. Im Livestream zu den kleinen Helfern in DMXControl 3.3.0 (siehe dazu auch: https://youtu.be/aXtpf6tv3Cw?t=8187) kam die Idee auf, einen Tastendruck nur abzufangen, wenn entsprechende Fenster aktiv sind.

Bisher können schon verschiedene Layouts in einem Projekt gespeichert werden. Allerdings ist es noch nicht möglich, eines der Layouts als Startup-Layout für ein Projekt zu definieren. Es sollte eine Einstellungsmöglichkeit geben, in der man auswählen kann, ob ein spezifisches Layout geladen werden soll oder das zuletzt verwendete. Für ersteres muss dann auch noch ein Handling für nicht mehr existierende Layouts implementiert werden. Siehe dazu auch: https://youtu.be/aXtpf6tv3Cw?t=8542

Die neuen Master bieten neben den neun Einstellungen für HSV, CMY und RGB auch die Möglichkeit, die RGB+ Farben einzustellen. Allerdings macht es keinen Sinn, Einen Fader für eine RGB+ Farbe darzustellen, wenn es im Projekt kein Gerät gibt, welches diese ausgeben kann. Es sollte also eine Möglichkeit geben, entweder selbst einzelne Farben auszublenden oder nur diese anzuzeigen, für die es auch Einstellungsmöglichekten bei den Geräten gibt.

Hallo,
im Live Stream am 07.11.2022 wurde für die 3.3.0 das neue Warning Featur vorgestrellt, mit dem angezeigt werden kann warum DMXC keine Ausgabe macht.

Hier für, sagte Arne, gibt es keine Knoten im Input Assignment.

Es wäre sinnvoll einen hierfür einzubauen um die dort angezeiten Warnungen gesamt oder auch einzeln auf Anzeigen öder ähnliches
im Softdesk zum schalten.

Gruss Steff

Analog zum Math- oder zum Logic-Node wünsche ich mir, dass die Anzahl der Eingänge beim Format-Node ebenfalls einstellbar sind. In vielen Situationen reicht ein Eingang bereits aus, da nur ein einiger Wert neu formatiert werden muss oder auch in diesem Zusammenhang durch einen Zusatz ergänzt werden soll. Daher würde ich in diesem Zusammenhang auch vorschlagen, standardmäßig nur einen Eingang anzubieten. In der Summe fallen die Connectionssets an dieser Stelle etwas kompakter aus.

Die “große” Lösung mit der eigenen Definitionslogik wie bei den Input / Output Selectoren entsprechend  FS#4366  bedarf es dann aber nicht.

Normalerweise ist der Kernel ab DMXControl 3.3.0 versteckt beim Start. So sieht man allerdings Fehler nicht mehr direkt, sollten diese im Kernel (oder im Umbra) auftauchen. Solche Fehler sollten zwar nicht so häufig auftreten. Wenn es passiert, sollte ein User in der GUI darüber informiert werden. Allerdings ist es sehr nervig, wenn während der Show ein Fehler auftritt und dann ein Popup / eine Message hochpopt. Daher sollte dafür ein Icon unten rechts als Ausrufezeichen in rot erscheinen, und beim Draufklicken sollte eine Info kommen, wo Fehler aufgetreten sind (nur dass und nicht welche). Man kann vielleicht noch eine “Show Kernel” oder “Show Umbra” Funktion anbieten. Aber das nur optional, wenn das einfach möglich ist

Projekte, die ich angepinnt und damit als Favorit markiert habe, sollten in der Liste der Projekte farblich hervorgehoben oder anderweitig von den nicht angepinnten Projekten separiert werden. Der Stern finde ich als Hinweis drauf ein bisschen zu wenig.

Dieses Ticket steht in gewissen Teilen auch im Zusammenhang mit Ticket FS#4927, da ich von meiner Seite davon ausgehe, dass die angepinnten Projekte immer oben in der Liste angezeigt werden.

Beim Eingeben von längeren Tags für ein Projekt können sich durch Tippfehler schnell Fehler einschleichen und man findest das Projekt nicht über diesen Tag. Zudem benötigt die Eingabe von längeren Tags entsprechend mehr Zeit.

Hier fände ich es gut, wenn mir bei der Eingabe die zuletzt genutzten Tags automatisch vorgeschlagen werden. Konkret dachte ich da ein Verhalten analog

• zu unserem Forum beim Verlinken eines Nutzers oder
• beim Schreiben einer News, wo nach dem Eingeben einer bestimmten Anzahl an Zeichen in den Tags ebenfalls die bisher verwendeten Tags vorgeschlagen werden

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