Bugtracker DMXControl 3

Wenn bestimmte Optionen in den Cuelistsettings nicht nicht verwendet werden, sollten diese entweder nicht angezeigt werden oder noch besser ausgegraut werden:

1. Wenn “Use Cue Time as Back Time” auf true steht, dann “Go Back Time” ausgrauen
2. Wenn “Use Cue Time as GoTo Time” auf true steht, dann “GoTo Time” ausgrauen

Mein Problem war, es war eine GoTo Time eingestellt, aber die Option war an. Das erkennt man derzeit so einfach nicht.

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.

analog zum Cuelistmonitor eine Anischt aller Cues innerhalb einer Cuelist (per Input Assingment wird die ID vorgegeben)

Mit Klick auf die Cue wird GoTo ausgeführt.

s. Überschrift

Ich stehe vor dem Problem, dass ich eine etwas aufwendigere Logikfunktion in verschiedenen Connectionsets benötige. Das Klonen funktioniert, ist aber eigentlich unnötig und sollte ich da mal Änderungen dran machen, muss ich alle 16 Sets immer wieder neu anfassen. Hier wäre ein “Interner Speicher” extrem nützlich.

Ich stelle mir ein Node vor, den ich Parametrieren kann mit z.b. “Merker 1” oder “DefaultBackroundColor” oder so und da schiebe ich in den Eingang einen RGB Wert rein und kann in einem 2. Connectionset diesen Wert mithilfe des Nodes verwenden.

Für die Kommunikation mit Energiezählern wird standardmäßig die Kommunikation über Modbus RTU / TCP hergestellt. Z.b. Siemens Sentron
Die Register für die einzelnen Adressen sind allerdings nicht bei jedem Gerät identisch. Somit muss für jeden Datenpunkt der Datentyp und die Registeradresse eingegeben werden können.

Ich würde mir ein Softdesk Control für das Electricity Feature wünschen.
Hintergrund ist die Anzeige der Verschachtelung der Sources. Dies ist im aktuellen Fenster nicht Erkennbar. Außerdem kann man die Amperemter nicht frei positionieren, wodurch die Anzeige schnell unübersichtlich werden kann.

In einem Beispiel habe ich mal meine Standard Stromverteilungen angelegt und als Screenshot hier eingefügt:

Die Funktion Snapshots im Programmer sind total nice. Das Problem ist nur, wenn ich drei vier Snapshots mal anlegen sollte, dann muss ich mir die Uhrzeit merken. Da wäre eine Möglichkeit zur manuellen Beschriftung sehr hilfreich (Analog zum Add Device Dialog - Group Name)

Derzeit ist es etwas aufwändig neue Cuelists schnell und ordentlich anzulegen. Meistens gehe ich dazu in den Projekt Explorer, lege einen Ordner an (z. B. MH Spots) und packe da meine Cuelists rein. Danach gehe ich in die Stage View, stelle meine Werte ein, öffne die Cuelist und speichere dann die Werte über Add in die Cuelist.

Um das ganze etwas zu beschleunigen haben Stefan und ich folgendes überlegt:

An der linken Seite werden die Buttons “Add Preset” und “Add Cuelist…” entfernt. Stattdessen gibt es nur noch “Add” oder “Store” oder “Record” was auch immer. Danach geht dann ein Popup Fenster auf (siehe Bild 1), in der man zwischen den Optionen wählen kann:

1. in offener Cuelist speichern
2. in (neue) Cuelist mit zusätzlichem Dropdown Liste aller Cuelists
3. in Executor
4. in Preset

Die Dropdown Liste aus dem zweiten Eintrag soll Analog zum “Group Name” aus dem “Add Device” Dialog funktionieren. Entweder man tippt einen Text ein, oder es werden alle existierenden Cuelists angezeigt, wenn man die Liste öffnet (siehe Bild 2). Was noch geklärt werden müsste, wie sich das mit Cuelists in Unterordnern verhält.

Die Auswahl sollte dabei gespeichert werden, falls jemand immer die gleiche Aktion ausführen möchte.

Es wäre hilfreich, wenn bereits verwendete Nodes eine Markierung erhalten, dass sie bereits irgendwo verwendet worden sind.

Folgendes Szenario:
Man hat ein 24 Kanal DMX Pult als Input und möchte wissen, ob ich bereits alle Fader verbraten hab, oder ob noch 1/2 frei sind. Dadurch hätte man einen guten Überblick.

Lösungsvorschlag:
Sobald Node irgendwo benutzt wurde, wird der Pfeil orange eingefärbt.

Einige Elemente in der Gui müssten für eine bessere Bedienung für Touch optimiert werden. Die Fader sind z.b. schwierig zu bedienen und im PE rumklicken ist etwas fummelig.
Vlt könnte man dort die Navigation auf 1x Klick umstellen und die Größe anpassbar machen.

Ich kann in Unterordnern keine Cuelists/Cuelist Groiups/ Devices/ Device Groups/ etc. über das Kontextmenü hinzufügen.

Außerdem werden neue o.g. immer im Hauptordner angelegt, die mit dem Button “Create XYZ” in der Menüleiste erstellt werden.

Edit: Patrick: Memo an mich. Das trift auf alle Nodes zu !!!!

Fehlerbeschreibung

Erwartetes Verhalten

Hinweise

Wenn man während einer laufenden Cuelist Kanalwerte anpasst, springt der Wert bei einer Änderung durch die Cuelist zurück auf den letzten von der Cuelist gesetzten Wert und fadet von dort zum neuen Wert.

Beispiel:
Generic Dimmer, Cuelist mit 2 Cues: Dimmer 100% und Dimmer 0%, Cuelist auf “Priority update on Go” und Programmer-Priority auf Normal

Fall 1: Änderungen vor Start der Cuelist
Über Programmer Dimmer auf 50% - Dimmer 50%
Cue 1 (Dimmer 100%) → Dimmer fadet von 50% auf 100% (So soll es sein)

Fall 2: Änderungen während laufender Cuelist
Cue 1 (Dimmer 100%) → Dimmer 100%
Über Programmer Dimmer auf 50% → Dimmer 50%
Cue 2 (Dimmer 0%) → Dimmer springt zurück auf 100% (Cue 1) und fadet von dort auf 0% (So sollte es nicht sein)

https://forum.dmxcontrol-projects.org/index.php?thread/13013

Fehlerbeschreibung

Erwartetes Verhalten

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).

Wenn ich mit der Maus per Drag&Drop ein oder mehrere Geräte in eine “Device Group” ziehe, dann bekomme ich kein Feedback. Ich sehe im Projekt Explorer keine Änderung und muss erst die Gruppe öffnen, damit ich sehe, dass beim Hinzufügen alles geklappt hat.

Für den Benutzer wäre es hilfreich, eine Reaktion vom Programm zu bekommen.

Eine Möglichkeit wäre, dass nach dem Drag&Drop die Gruppe kurz das Aussehen verändert. (Irgendwo habe ich einmal eine pulsierende Reaktion in einem anderen Programm nach einem Drag&Drop gesehen, das ziemlich ansprechend war)
Eine andere Möglichkeit wäre, dass im Tree vom Projekt Explorer mit angezeigt würde, wieviele Geräte aktuell in der Gruppe drin sind. Diese Anzahl würde sich dann natürlich nach dem Hinzufügen veränden.

Wenn ich z.B. in den Properties von einem Gerät oder einer Gerätegruppe bin und den Text anpassen möchte, dann kann ich mittels Maus nicht einfach den ganzen Inhalt des Textfeldes mittels 3 Klicks der Maus auswählen, wenn dieser Leerzeichen enthält.
Bei den meisten heutigen Programmen ist es üblich, dass man mittels 3 schneller Klicks hintereinander mit der Maus in das gleiche Feld alle Inhalte einer Zelle (oder zumindest einer Zeile) auswählen kann.

Es wäre schön, wenn DMXControl auch diese Funktion bieten könnte.

Fehlerbeschreibung

Erwartetes Verhalten

Hinweise

Fehlerbeschreibung

Erwartetes Verhalten

Fehlerbeschreibung

Erwartetes Verhalten

Hinweise

Fehlerbeschreibung

Erwartetes Verhalten

Hinweise

Fehlerbeschreibung

Erwartetes Verhalten

Hinweise

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

Fehlerbeschreibung

Hallo,
ich war, als ich den vorletzten News Artikel (https://forum.dmxcontrol-projects.org/core/index.php?article/774-schon-gewusst-34-vieles-ist-relativ-auch-der-programmer-knoten/) gelesen hab kurz verwirrt. Anhand der Überschrift dachte ich, man könnte die Werte die man in den Node schmeißt relativ interpretieren lassen (wie im Device Control).

Daher ist meine Idee in dem Zusammenhang mit dem Programmer-Node (den man zwischen normierten Werten und absoluten Werten umstellen kann), eher mit dem Wort normiert zu belegen, anstatt relativ.
Die Verwirrung war nur kurz da und hat hat sich beim Lesen des Artikels auch behoben. Aber dennoch kann ich mir vorstellen, dass neue Benutzer, die sich in die Thematik einarbeiten, auch verwirrt sein können.

Beste Grüße, Ludwig

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

Sinnvoll wäre es Variablen in Eigenschaften unterbringen zu können. Eine Variable könnte dann zum Beispiel so aussehen:

$BeispielVariable

Wenn ich so eine Variable nun zum Beispiel einer Phase von einem Effekt zuweise:

0<$BeispielPhase

Könnte ich, wenn ich die Variable einen Input zuweisen könnte, noch nachträglich die Phase des Effektes verändern.
Oder wenn ich meine Movingheads auffächere mit

-20<20

könnte ich dank

-$Fächer<$Fächer

die Fächerung hinterher noch justieren und so mein gespeicherten Szenen super einfach live variieren.

Schneller passiert als man denkt,
einmal nicht aufgepaßt welches Node man gerade ausgewählt hat und schon löscht man das falsche Node mit allen dazu gehörigen Verbindungen.

Ein Undo Redo kann hier ungewollten Schaden verhindern.

AKtuell ist es nicht möglich ein Excportiertes Rulset wieder zu importieren.

Beim Anlegen von 80 Buttons wäre das aber hilfreich, wenn man es exportieren → mit Notepadd++ editieren und wieder Importieren könnte.

wenn ich im Inputassignment nodes verschieben möchte muss ich diese vorher einmal mit der Maus anklicken (auswählen) bevor ich sie per drag&drop verschieben kann.

ist es evtl. möglich die nodes schon mit dem ersten Mausklick (gedrückt halten) zu markieren?

Der Powermeter Name verdeckt das Powermeter.

wird das noch geändert?

Bei “Buttons” wird immer nur die Funktion zu Verfügung gestellt die nötig ist. ( Eingang oder Ausgang)
Bei “Programmer” werden immer alle Funktionen (Eingang und Ausgang) Verfügbar gemacht.

Will man also einen Button beleuchten muss dieser 2 mal hinzugefügt werden.

Es sollte egal ob ich den Node ausm Eingang oder Ausgang auswähle immer alle Funktionen (Eingänge & Ausgänge) zur Verfügung stehen.

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 - 

die Toolbar im MidiManager hat keine Icons. Das sollte konsistent sein, wie im Project Explorer, Presets, DMX Interfaces, etc.

gruenes Plus fuer Add Rule Set (Add Interface bei DMX Interfaces)
rotes X fuer Delete Rule Set (Delete Interface bei DMX Interfaces oder auch Delete Selection im Programmer)
blauer Doppelpfeil fuer Update Devices (Refresh im Project Explorer oder auch Update in der QuickBar links)
blaues i fuer Info (wie unter Hilfe → Info im menu)
Wrench-Icon fuer Tools (keine Referenz0

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

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.

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….

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.

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.

Starte ich die Software mit aktivertem VPN bleibt der Network-Explorer leer und es kann keine Verbindung zwischen den Programmteilen hergestellt werden.
Deaktiviere ich das VPN, in meinem Fall Wireguard, und starte die Software erneut klappt es. Wenn die Verbindung steht kann ich das VPN wieder aktivieren und die Software funktioniert weiter.

Wie im Livechat am 19.1. diskutiert fände ich gut wenn es ein Grouphandling gäbe mit dem ich Geräte in einer Gruppe als ein Gerät betrachten kann und gleichzeitig in der “Hauptgruppe” auch einzelne Geräte haben kann. Siehe auch mein Kommentar in ( FS#674 ).

Folgendes Vorgehen löst den Fehler aus, auch in der 3.3 Alpha6 vorhanden, Logs der 3.3 anbei.

Device Group mit Generic RGB, Farbe auf Rot in Cuelist speichern. → funktioniert wie erwartet
Anschließend alle Devices aus der Gruppe löschen, Projekt speichern und neu laden.
Projekt neu laden, wieder Geräte in die Gruppe hinzufügen, Cuelist starten → keine Farbe mehr vorhanden, bei “Edit in Programmer” wird keine Eigenschaft aufgerufen, der Programmer bleibt leer.

Hintergund:
Ich habe für mich ein Standard-Projekt erstellt, dieses hat 4 Gruppen und je nach Veranstaltung werden andere Geräte in die Gruppen aufgeteilt, teils mit vollkommen unterschiedlichen Setups. Mir ist es nun schon passiert das ich mir beim Anpassen des Projektes alles zerstört habe weil ich erst einmal alle Gruppen geleert haben.
Beim letzten Mal wollte ich das ganze verhindern und habe ein Gerät in die Gruppe gesteckt das ich sonst nicht nutze, leider tritt der Fehler auch auf wenn das Gerät keine Farbeigenschaft hatte, daher hat mir die Nebelmaschine in der Gruppe auch nicht vor dem Verlust geschützt.

Beim Auswählen innerhalb eines Poperties im Input Assigment muss der Wert ausgewählt werden und anschließend mit OK bestätigt werden, hier werde eine Auswahl mit Doppelklick und automatischem schließen des Fensters schön.

zB: Parametermaster-Node, in den Einstellungen einen Parametermaster auswählen

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.

Ich sende aus Virtual DJ über MIDI alles, und ich meine hier wirklich alles an DMX Control.
Z.B. habe ich in der Virtual DJ Bibliothek auch immer ein Feld in dem mögliche Tänze zum Lied stehen. Z.B. eben für Tanzveranstaltungen. Diese sind wie im Turniersport üblich mit RB Rumba, DF Discofox und so weiter kodiert. In DMX Control habe ich dann ein paar Cuelists die z.B. passendes Licht für eben Rumba oder Discofox machen. Diese werden automatisch gestartet, wenn Virtual DJ über MIDI eben die Buchstaben RB oder DF überträgt. Das funktioniert aktuell einfach über eine ASCII kodierte MIDI Controller Nachricht. Aus Virtual DJ heraus kann ich problemlos quasi beliebig lange strings als MIDI Nachrichten, also byte Array senden.

In DMX Control kann ich aber nur einzelne Bytes empfangen und keine Arrays.
Im Moment muss ich ich hier ziemlich in die Trickkiste greifen. Und das klappt auch nur weil es im Moment “nur” ein paar Zeichen sind, die ich auswerte. Siehe Bild.

Ich würde mir Wünschen, dass eine zusätzliche Regeln eingeführt wird in der man sagen kann “empfang die Bytes von hier bis hier” oder Startindex und Länge oder so.
Außerdem müssten diese Bytes natürlich verarbeitet werden. Also z.B. ToInt64 oder ToString oder so.

Ich stolpere aktuell an einigen Stellen auch das immer gleiche Problem:
Ich “rechne” in einem Connectionset irgendwas halbwegs kompliziertes aus, was ich dann an mehreren Stellen verwenden will.
Manche Sachen lassen sich prima über einen ParameterMaster von einem Connectionset ins nächste bringen.
Aber bei anderen Sachen macht es nicht wirklich Sinn einen “guten” ParameterMaster zu “verschwenden”.
Außerdem sind keine Strings oder andere komplexere Datentypen möglich.

Ich würde mir daher wieder in Anlehnung an Matlab/Simulink einen Node Goto/From wünschen.
Hier kann in einem Node Goto ein Wert reingehen und an vielen From Nodes die an den gewünschen Goto verlinkt sind wieder raus.