Bugtracker DMXControl 3

Über die Buttons half und double kann man den aktuellen BPM-Wert faktorisieren. Hier wäre es gut, wenn dieser Faktor angezeigt wird. Ein typisches Anwendungsbeispiel ist, dass ich mehrere Speedmaster zwar gleichzeitig Lerne bzw. Synchronisiere, aber jeden Speedmaster einzeln faktorisiere.

Zur weiteren Steigerung der Qualität der DDFs sollte der Kernel alle Attribute kennzeichnen, die nicht der “offiziellen” Schreibweise einer im Kernel hinterlegten Liste entsprechen. Aktuelles Beispiel ist hier:

• minddmx (das zweite d ist hier fehl am Platz)

gebe ich in ein Textfeld einen falschen Wert ein: Z.b. bei einer Nummerneingabe nen Text ein, kann in dieser Zeit kein anderes Textfeld bearbeitet werden, bis entweder eine richtige Eingabe getätigt wurde, oder mit Escape die Eingabe abgebrochen wurde. Das ist echt doof, weil sich die GUI dadurch nicht bedienen lässt, bis die Fehleingabe behoben wurde.

Meine Vorschläge dazu:

1. Wenn eine fehleingabe gemacht wird, wird ein Tooltip/Popup gezeigt, dass es eine Fehleingabe ist und der alte Wert, der vorher in dem Textfeld stand wird wieder hergestellt. –> s. MS Office: einfach mal bei der Schriftgröße nen Buchstaben eintragen… 2. Man grenzt die Eingabemöglichkeiten so ein, dass man z.b. in nen Nummernfeld keine Buchstaben eintragen kann.

Im Kontextmenu Projektexplorer → Master → z.B. Speedmaster haben die Einträge “Sortieren” und alles mit “hinzufügen” das gleiche Icon.
An allen andern Stellen in der GUI wenn irgendwas hinzugefügt werden soll ist da so ein kleines grünes Plus wie im Bild.
Ich würde das hier auch erwarten um konsistent zu sein.
Vielleicht könnte man den Mastern auch unterschiedliche Icons geben.
Vorschlag:
- Colormaster einfach nicht nur blau, sondern vllt Regenbogenfarbverlauf von unten nach oben
- Groupmaster das Icon der Gerätegruppe dazu
- Parametermaster vllt so ein f(x) oder so dazu irgendwas “mathematisches” - Positionsmaster ein Fadenkreuz?
- Specialmaster weis ich grad auch nicht ^^
- Speedmaster Tachonadel?

Moin,
wenn ich den Button um 90° oder 270° drehe kann er dicht an anderen Elementen ausgerichtet werden.
Grund fürs drehen ist einen Schmalen Button zu bekommen mit einer Seitlich lesbaren Schrift.

Bild zeigt die Position wo er hinspringt.

Gruß
Max

Bei der Phase kann man zwar den Wert fannen,
z.B. {parametermaster 1} > 0
Das funktioniert auch. Wenn man die Szene abspeichert und das
Projekt wieder öffnet erscheint eine Fehlermeldung:
Value kann nicht für Parameter: Phase geladen werden.

{parametermaster 1} > {parametermaster 1:*2} funktioniert aber.

Wunsch: Fanning Operatoren in Release-Time von Cuelists nutzen.

Will ich z.B. einen Sweep bauen, dessen delay time der cuelist z.b. 0<>200ms ist und will nun, dass diese auch genau so wieder ausgehen, muss ich das Tracking der Cuelist deaktivieren, eine zweite dummy cue erstellen die leer ist und dieser wieder eine delay time von 0<>200ms geben. Die Möglichkeit Fanning Operatoren in der Release Time zu nutzen würde hier vieles verinfachen und viel Arbeit sparen.

Schön wäre ein “Werkzeug” einzubauen, das beim faden von z.B. Rot auf Blau der Farbverlauf nicht über weiß fadet. Ich kenne das so das man z.B. sagt, fade über eine dunkle Farbe. Oder auch beim faden von Rot auf Blau wird an dem Punkt wo Weiß kommt, würde der Scheinwerfer in den Moment automatisch runtergedimmt werden.

Ich habe mir zwei Cues angelegt, welche zwischen langsam exemplarisch zwischen der Farbe gelb und blau hin- und herfaden. Gebe ich die Farben im:

• RGB-Modus oder im CMY-Modus an, so wird direkt von gelb nach blau gefaded
• HSV-Modus an, erfolgt der Fade von gelb über grün und hellblau nach blau

An dieser Stelle hätte ich jetzt nicht erwartet, dass der Wechsel der Art der Eingabe für die Farbe sich auf auf den Fade der Cues auswirkt und im HSV-Modus über Zwischenfarben gefaded wird. Bis jetzt hatte ich gedacht, dass der Wechsel zwischen RGB, CMY und HSV nur eine andere Art der Eingabe ist, um zum Beispiel mittels HSV einen statischen Regenbogen zu erzeugen.

Als Ergänzung hierzu: teile ich die Cues auf zwei Cuelists auf (also Cuelist 1: gelb, Cuelist 2: blau) und schalte die Cuelists mit Hilfe einer Cuelist Group um, erfolgt der Übergang zwischen den Farben wieder direkt, sprich wie ich es auch vom RGB-Modus kenne.

Ich habe nun auch noch ein Beispielprojekt in der 3.2.2 erstellt. Wenn beim Öffnen das letzte Fensterlayout geladen wird, können über die ersten drei Executoren die automatisch laufenden Farbwechsel von gelb nach blau und zurück für die Modelle RGB, CMY und HSV gestartet werden. Die letzten vier Executoren dienen dem manuellen Wechseln zwischen gelb und blau - einmal im RGB-Modus und einmal im HSV-Modus.

Following discussion with JP on the forum, I’m posting this feature request here.

It would be useful to be able to achieve the following effect using the chaser effects:

https://vimeo.com/676900437/6d03543b2e

JP suggested this could be implemented as a ‘Fill’ option on the chasers.

As an example using the Colour chaser, the chaser should change the colour of each device to the next colour on the colour list, in selection order, until all devices have been changed, and then repeat with the next colour on the list.

This should work in combination with the play mode to set the direction that the fill happens in - forward, reverse, bounce or random.

This could also work with the standard chaser to apply the fill effect to dimmer intensity.

Zum Color Grid hätte ich folgende Featurewünsche:

1. Anzahl der Buttons einstellbar machen.
2. Angabe der Anzahl der Buttons pro Zeile (die Anzahl benötigten Zeilen ergibt sich aus der Gesamtzahl der Buttons und wäre keine notwendige Einstelloption).
3. Nutzung eigener Farblisten als Preset für das Color Grid.

Bei Punkt 3 wäre hier der Gedankengang, die bereits existierende Colorlist aufzugreifen. Wenn man dann noch weiterspinnt, könnte ich mir sogar eine Weiterentwicklung des Color Grids dahingehend vorstellen, ähnlich auch mit einer Gobolist verfahren zu können.

Fehlerbeschreibung

Erwartetes Verhalten

Hinweise

Hallo,

ich glaube wieder einen Bug gefunden zu haben.

Die erste Cue wird nicht geladen, wenn im Loop-Modus, der Trigger für die erste Cue mit follow oder wait und 0ms und letzte Cue mit Fade-Time 0 eingestellt ist.

Zum Reproduzieren:
Projekt erstellen, Gerät(e) hinzufügen (auch bei Gruppen), Cuelist mit 4 Farben hinzufügen, alle Cues als Trigger follow einstellen mit 0 ms. Die Zweite und letzte Cue mit 0ms Fade-Time einstellen. Mode der Culist auf Loop stellen, und abspielen (ich hoffe keinen Schritt vergessen zu haben).

Das Verhalten tritt auch auf bei Trigger auf Wait eingestellt.

Der Anwendungsfall ist wahrscheinlich sehr selten, und es lässt sich umgehen, indem eine Zeit auf 1ms gesetzt wird.

Beste Grüße, Ludwig

3.3 RC2

Fehlemreldung im Kernel und keine Reaktion mehr von DMXC nachdem Cue 19 in den Programmer geladen wurde und anschließen gereplacet wurde.

Kernel ließ sich mit den Befehlen nicht schließen - auch nicht nach einem von JP angeregten Rechtsklick - und wurde dann via Task Maneger hart beendet.

Logs und Projekt im Anhang.
0.2.61 = letztes gespeichertes Projekt, lässt sich aber nicht mehr laden
0.2.60 = letzter Stand vor Fehler

Der Fehlerdialog ist schlecht designed!

Fehlerbeschreibung

Eine fehlerhafte Validierung der Eigenschaften eines Nodes im IA lässt die GUI unbedienbar werden. Weder ein Abbrechen, noch ein schließen des Fensters ist möglich, bis der Wert entsprechend korrigiert wurde. Für mich als User ist nicht erkennbar, warum das UI unbedienbar wird.
Vorschlag: zulassen des “Abbrechen” Button sowie schließen des Fensters und einblendung eines Tooltips mit einem Hinweis auf fehlerhafte Werteingabe inkl. dem zulässigen Wertebereich (Angelehnt an das Verhalten im Device Control).
Beispiel für das “einfrieren” Eingabe eines negativen Wertes für das Delay Node.

Lege ich in den allgemeinen Optionen für ein Softdesk eine definierte Größe für dieses Softdesk fest, werden die Werte nach dem Schließen und erneuten Öffnen des Softdesk Editors nicht übernommen und auf NdN gesetzt.

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.

es wäre nice, wenn im Masterfenster der Filter gespeichert werden könnte (also die Auswahlboxen).

Bei manchen Input-Werten kann es vorkommen, dass diese etwas schwanken, gerade bei analogen Spannungswerten. Diese Schwankungen sorgen jedes Mal für eine Werteänderung und triggern so ein Update des ConnectionSets, obwohl dies vielleicht nicht nötig wäre. Daher wäre es gut, wenn es ein Filter-Node gäbe, welches einen Input entsprechend glättet. Hier sollten zumindest ein paar der Glättungsverfahren / Filtertypen implementiert werden (siehe https://de.wikipedia.org/wiki/Gl%C3%A4tten_(Mathematik))

Da wir immer mehr eigene Hardware anbieten und auch hin und wieder neue Funktionen in die Devices kommen, welche z.T. eng mit DMXC verknüpft sind (Nodle U1, Sync ausgabe, heartbeat), wäre es vielleicht sinnvoll die jeweils aktuellste Firmware für z.B. das Nodle U1 und dann auch das R4S und zukünftige mit DMXC 3 auszuliefern und eventuell beim Start den User darauf hinzuweisen, das eine neue FW verfügbar ist.

DMXC3 müsste dafür nur eine Datei pro HW haben, in welcher die aktuellen FWs stehen und diese beim Verbinden mit dem Interface abgleichen.
Wurde eine ältere Firmware im Device erkannt, kann wird beim Start der Software und verbinden der HW eine MessageBox geworfen und die Verbindung abgebrochen mit Hinweis auf die neue FW.

Der User kann nun entscheiden ob er die Hardware mit der alten FW verbinden will oder zunächst ein Update machen will.
Bei Update-Entscheidung muss DMXC nur ein kleines von uns mitgeliefertes Programm/Tool/exe starten, welches in einem definierten Pfad im Kernel oder GUI liegt.

z.B. beim U1: kernel/hardware/nodle_u1/update.exe –Serialnumber
oder beim R4S: kernel/hardware/nodle_r4s/update.exe –Serialnumber

Das Programm “update.exe” ruft dann die nötigen subprogramme/Funktionen/etc aus dem Ordner auf, um den User durch den Flashvorgang zu leiten.
Wenn erfolgreich, meldet das Programm “exit 0” oder so zurück und DMXC3 kann mit dem Verbindungsaufbau zur HW fortfahren.
Die Seriennummer oder eine andere Geraetekennung (je nach Device) dient dazu mehrere angeschlossene Geräte zu unterscheiden.

Je nach Gerät passiert das alles nach dem druck auf “Ja Update Jetzt” automatisch, weil der User keine Interaktion mit der HW benötigt.
Die spezifischen Unterschiede für jede Hardware sind von DMXC3 komplett entkoppelt und nur in der update.exe pro Hardware zu warten.
Damit ist das jederzeit austauschbar/anpassbar ohne DMXC und dessen Hardware-Treiber zu beeinflussen.

Als Luxus-Variante könnte in dem “neue FW-Fenster” noch der Changelog bzw. die neuen Funktionen des Firmware drin stehen, die sich DMXC aus besagter Versionsdatei in dem jeweiligen Verzeichnis ziehen kann.

in Folgedem Beispiel wurde eine “Stairville AF-250” verwendet
Beim Timer wird der DMX Kanal immer auf 100% gesetzt für die Aktive Zeit.

Schön wäre es wenn man auch die Menge auswählen könnte wie, 25%, 50%, 75%, 100%. Oder vielleicht sogar eine frei wählbare Menge an Ausstoß.

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.

Als zum Ticket  FS#3167  ergänzende Funktion soll es möglich sein, bei einem beliebigen DMX-Ausgabe-Plugin nachträglich die Ausgangs- und Eingangs-Universen neu zu patchen, ohne dabei das betreffende und bereits konfigurierte DMX-Ausgabe-Plugin entfernen zu müssen. Angedacht ist hier ein Fenster, in dem man angeben kann, ab welchen DMX-Universium bzw. DMX-Adresse die verfügbaren Ports entsprechend fortlaufend belegt werden sollen. Sprich soll das Art-Net-Ausgabeplugin fortlaufend ab DMX-Universum 3 Werte ausgeben oder erst ab dem 5. DMX-Universum.

Aktuell ist es so, dass man im Patching-Dialog nur Gerät für Gerät den Patch ändern kann. In manchen Situation ist es aber vom Handling her einfacher, direkt für mehrere Geräte den Patch zu ändern. Daraus abgeleitet, wären folgende zusätzlichen Funktionen erforderlich:

• Auswahl von mehreren Geräten in ein anderes DMX-Universum umpatchen. Die Adressen innerhalb des Universums werden 1-zu-1 übernommen. Der User gibt nur das Ziel-Universum an.
• Auswahl von mehreren Geräten ab einer bestimmten DMX-Adresse neu patchen. Für das erste Gerät der Auswahl gibt der User die Start-Adresse sowie den Freiraum zwischen zwei Geräten an.
• Aktivierung der Auswahlmöglichkeit von mehren Geräten in der Kanalübersicht des Patching-Dialogs.

* Auswahl von mehreren Geräten ab einen bestimmten Wert eine neue Device-ID zuweisen. Für das erste Gerät der Auswahl gibt der User den Start-Wert sowie den Freiraum zwischen zwei Geräten an. ⇒ Hat nix mit DMX Patching zu tun

Ergänzung: Grundlegend sollte die Vergabe der neuen DMX-Adressen immer an Hand der Sortierung der Spalten erfolgen, die jeweils im Patching-Dialog vor dem Starten der automatischen Patching-Funktion gesetzt ist.

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

s.o.

Drehe ich ein Control um einen beliebigen Winkel und verändere dann mit der Maus dessen Größe, beginnt sich das gesamte Control in einem gewissen Rahmen zu bewegen. Der Bezugspunkt wird beim Skalieren mit der Maus nicht ausreichend “fixiert”, weil dieser bekanntermaßen zur Zeit weiterhin von einem nicht gedrehten Control ausgeht.

Ausgangssituation: Es gibt mehrere Moving Heads, die zeitversetzt eine Welle (Sinus auf Tilt) durchlaufen sollen. Hierzu gibt es drei Cues, einen mit dem Sinus auf dem Tilt, die One Shot-Cue und eine statische Cue, um die Welle zu beenden. Da es ein gefanntes Delay für alle drei Cues eingetragen ist, bin ich davon ausgegangen, dass nun auch alle Heads die Welle zeitversetzt durchlaufen und jeder mit seinem entsprechenden Delay wieder zum stehen kommt. Das ist aber nicht der Fall. Nachdem der erste Moving Head die Welle durchlaufen hat, beenden alle die Welle irgendwo mitten drin und gehen gleichzeitig direkt auf die statische Stimmung.

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.

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

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

Aus der GUI geht sowohl im Programmer auch nicht im Device Control hervor, welches Farbmodell man für eine Device Group oder einem Device genutzt hat. Hier würde ich mit eine entsprechende Kennzeichnung wünschen.

Wenn man beim Anlegen eines Gerätes einen Namen für Gerät oder Gruppe angibt, der länger ist als die Länge des Felds, läuft der Text über die Anzeige hinaus. Man kann allerdings nicht per Pfeiltasten im Feld scrollen. Der Rest der Eingabe wird somit unsichtbar.

Zwei Punkte:

a) Beim Hinzufügen der Open DMX-Schnittstelle von Enttec muss zum einen in dem sich öffnenden Fenster in dem leeren Parameterfeld für den Parameter <Gerät>

FT232R USB UART [A60185MM]

ausgewählt werden. Es ist keinerlei Hinweis sichtbar, dass hier überhaupt eine Auswahl vorgenommen werden muss. Das leere Parameterfeld wird nicht als Combobox dargestellt.

b) Werden GUI und Kernel unter Sicherung des Projekts beendet und GUI und Kernel wieder gestartet, wird zwar unter dem Reiter DMX-Schnittellen der Enttec OpenDMX als ein Zeileneintrag dargestellt. Klicken auf <Erweiterte Schnittstellenbeschreibungen> führt jedoch zur Fehlermeldung “Schnittstelle nicht verfügbar”.
Die Schnittstelle muss komplett gelöscht werden und wie unter a) neu angelegt werden.
Sicherung des Projekts hat auf das Verhalten kein Einfluss.
Wird nur die GUI beendet, tritt der Effekt nicht auf. Es muss der Kernel beendet werden.

Es wäre schön, wenn es eine Möglichkeit gäbe einzustellen, dass ein Gerät nur von einem Control (z.B. Submaster) verändert werden kann.

z.B. Umgangslicht befindet sich in einem Submaster. Ich kann noch so viel Mist eingeben und verändern, oder beim Prgrammieren ist mir ein Fehler unterlaufen, dem Gerät passiert trotzdem nichts. Nur dieser Sub kontrolliert das Gerät.

In der Stageview sollten selektierte Geräte und Gruppen mit Rechtsklick → Entfernen von der Stageview entfernt werden können.
Eventuell auch mit druck auf die Entf-Taste, wobei das eventuell zu unsicher ist.

Zweiter Contextmenü-Eintrag sollte sein “Copy to StageView X” und “Move to StageView X”

Es wäre schön, wenn es eine Möglichkeit gäbe, einzelne Geräte für Records zu sperren, soll heißen, egal welchen Wert diese haben, oder ob die verändert werden, sie werden nicht gespeichert.

z.B. für Saallicht, Arbeitslicht, Umgangslicht.

Weis nicht ob das jetzt überflüssig ist aber ich würd gerne auf das Brainstorming:Gerätefunktionen.
Wäre echt geil wenn dasd alles balt gehen würde.

Die Fanning-Operatoren ? und ?? sollen liefern einen zufälligen Wert zurück. Soll dieser Wert seine Gültigkeit behalten

• für die gesamte Laufzeit einer Cuelist?
• nur für die einzelne Cue und somit mit jedem Aufruf einer oder auch der selben Cue direkt neu generiert werden?

Diese Situation betrifft nicht nur die Properties selbst, sondern zum Beispiel auch die Werte für Fade, Delay etc. in den Cuelists selbst. Diese Frage bzw. das Verhalten dieser Operatoren sollte ggf. nochmal diskutiert werden.

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^^

Eine Möglichkeit, ähnlich dem Trigger, der FadeTime nicht eine feste Größe sondern eine Variable/Input aus dem Inputassignment zuweisen zu können
und durch dieses global eine fade Zeit (wie in guten alten Zeiten beim SceneSetter48) einstellen zu können

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

Die Einbindung der Icons für die Gobos erfolgt über einen Button auf dem Softdesk welchem im Input Assignment ein “Bitmap from Resource”-Node zugefügt wird.
Trotz Speicherns ist das Icon auf dem Softdesk nach Neustart weg.

Es ist nicht möglich, RAW und gobowheel auf den gleichen Kanal zugreifen zulassen. Das Goborad hat dann keine Funktion in dmxc3

https://forum.dmxcontrol-projects.org/index.php?thread/11994-gobo-und-raw-auf-einem-channel/&postID=100316#post100316

s.o.

Wie die CPU-Load anzeige im Monitoring fenster, zusätzlich die GPU-Load einbauen für GUI und Kernel

Hab da auch eine Lib die alle gängigen Grafik-Karten-Hersteller abdeckt, aber die bekommen wir nur auf direkte anfrage.
https://www.techpowerup.com/gpuz/

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.

Fehlerbeschreibung

Wenn ein Graph Fehler wirft oder in der Verarbeitung zu lange läuft sollte nach z.B. 10 Fehlern der Graph abgeschaltet werden, um nicht das ganze System auf zu halten.

Das Input Assignment ist in einem floating Window zusammen mit einem Softdesk (IA oben, Softdesk unten). Nachdem ich einige Zeit im Projekt gearbeitet hab (Wechseln zwischen Graphen und Tabellen-Ansicht, verschieben der Grenze zwischen IA und Softdesk), ist mir in der Tabellen-Ansicht die auf dem Bild 1 zu sehende graue (im Bild rot markierte) Fläche aufgefallen. Diese überdeckt alle sich darunter befindenden Connectionsets und wird relativ zu der Grenze IA und Softdesk verschoben (Bild 2). Außerdem wandert die mit der Zeit nach oben (also jetzt nicht kontinuierlich, sondern irgendwie während dem Arbeiten). Öffne ich ein Connectionset, dann verschwindet sie und ich kann ganz normal im CS arbeiten, beim öffnen der Tabellenansicht ist sie wieder da. Mit Schließen und Öffnen des IA geht die Fläche auch nicht weg. Lediglich mit einem Neustart der Software verschwindet es wieder (Projekt neu laden hab ich jetzt nicht probiert.