Bugtracker DMXControl 3

Wenn keine GUI mehr mit Kernel oder Umbra verbunden ist und die Fenster versteckt sind, sollen die Fenster in den Vordergrund geholt werden.

Hintergrund ist, dass man man nicht immer mitbekommt, wenn z.b. der Kernel nicht sauber herunter gefahren sind. (Folgeticket aus  FS#4729 )

Nachdem sich nun Projekt mit “großen” Input Selctoren laden lassen, musste ich feststellen, dass die eingestellten Werte für die Inputs nicht vollständig geladen werden. DMXControl 3 liest immer nur die ersten vier Werte für die Input Selectoren aus, obwohl alle Werte in der Graphs.xml abgespeichert werden.

Im Anhang einmal der Screenshot, so wie es sein soll und das zugehörige Testprojekt.

Seit DMXControl 3.3.0 Beta 2 werden RGB-Werte für Farben vom Input Selector wieder in ein Lumos-Color-Objekt konvertiert.

Dieses Problem hatten wir bereits im Rahmen des Beta-Tests von DMXControl 3.2.2. Seiner Zeit hatte ich es im Ticket  FS#4273  berichtet. Die dort vorhandenen Screenshots sind 1.1 übertragbar, weswegen ich keine neuen Screenshots erstellt habe.

Um die Nutzer bei der Verwendung der Funktion “Zeitpunkt für Aktivierung der DMX-Ausgabe selbst festlegen” aus Ticket  FS#4015  zu unterstützen, aber auch bei weiteren Punkten wie

• Grandmaster, Gruppenmaster etc. unter einem bestimmten Wert
• Blackout aktiv
• Freeze aktiv
• Cuelist-Intensität auf 0

sollen alle Warnungen und Änderungen mit einem “Schweregrad” bzw. Warning-Level versehen werden.

Zur Protokollierung, welche Funktion die Warnung generiert oder das Dirty Flag setzt, soll ein Interface gebaut werden, über das die Wichtigkeit der Änderung an einen zentralen Manager weitergereicht wird. Wie detailliert die Rückmeldung an den Nutzer erfolgt, kann dieser über eine Einstellung festlegen. Diese Einstellung greif dabei die verschiedenen Level der Schwere der Warnung oder der Änderung am Projekt auf.

Wenn ich im folgenden Setup auf PC 1 in einem leeren Projekt Geräte und Gerätegruppen in einer Stage View hinzufüge, so wird die auf PC 2 nicht aktualisiert. Gleiches gilt umgekehrt.

• PC 1: Umbra, Kernel, GUI
• PC 2: GUI

Auch wenn die Icons der Geräte und Gerätegruppen nicht simultan anzeigt werden, so aktualisieren sich zumindest beide GUIs, wenn die Geräte auswähle.

Wenn ich DMX-Interfaces und Ports aus dem Kernel heraus im Code Activiere oder Deaktiviere wird dies nicht an die GUI durchgereicht

Geiler Scheiß, fast fertig….

s.o.

Es ist suboptimal, das die FFT-Analyse die CPU auslastet wärend eines File-Imports, dadurch stockt der Resource-Stream extrem, oder der Kernel wird zwischendurch disconnected…..

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.

Im beigefügten Projekt habe ich in der Cue 1 der Cuelist 1 einen Chaser auf die Gerätegruppe (Device Group) gelegt. Ändere ich nun die Sortierung der Geräte in dieser Gerätegruppe über das Kontextmenü und sortiere sie zum Beispiel zufällig, wird der Chaser trotz Play Mode “Normal” beim erneuten Starten der Cuelist nicht aktualisiert. Aktuell kann ich die Sortierung nur per Drag ‘n’ Drop oder über die Buttons Up und Down ändern. Über letzte habe ich die zur Zeit aktive Reihenfolge realisiert: 1 - 4, 13 - 16, 5 - 12.

Ich hatte im beigefügten Projekt ursprünglich zwei Cuelists angelegt. Die Cuelist 2 hatte ich dabei per Special Cue in die Cuelist 1 referenziert. Die Cuelist 1 enthält neben der Special Cue mit der Referenz zur Cuelist 2 noch zwei weitere “einfache” Cues.

Nun habe ich die Cuelist 2 aus dem Projekt gelöscht und das Projekt gespeichert. Die Special Cue in der Cuelist 1 ist aber weiterhin vorhanden.

Beim erneuten Laden des Projekts wird zwar logischerweise ein Fehler ausgeworfen, dass die Cuelist 2 fehlt und die Referenz entsprechend nicht aufgelöst werden kann. Jedoch im gleichen Zusammenhang der Inhalt der gesamten Cuelist 1 auf den ersten Blick scheinbar nicht mehr geladen. Die Cuelist 1 hat dann 0 Cues. Der Kernel wirft hierbei den folgenden Fehler aus:

07:47:42 WARN  ProjectManager - Error when loading Project 2022-04-27 - Cuelist reference.dmz: Warnings in Project
org.dmxc.lumos.Kernel.Exceptions.ProjectIOException: Warnings in Project
   bei org.dmxc.lumos.Kernel.Resource.LumosIOContext.ThrowOnWarnings() in D:\Jenkins\workspace\Lumos_Pipeline_3.3\Lumos\src\Kernel\Resource\LumosIOContext.cs:Zeile 220.
   bei org.dmxc.lumos.Kernel.Project.ProjectManager.loadProject(String filename, Stream inputStream, Boolean loadId, IProgress`1 progress) in D:\Jenkins\workspace\Lumos_Pipeline_3.3\Lumos\src\Kernel\Project\ProjectManager.cs:Zeile 384.
07:47:42 WARN  ProjectManager - Loading Cue Lists in Project
07:47:42 WARN  ProjectManager - Error loading complete Scenelist Cuelist 1. There could be a loss of information! in Cuelist 1
07:47:42 WARN  ProjectManager - A Cuelist with the ID 70ff8bf9-eb8c-4f62-8ae5-65370c96d2b3 doesn't exist in Go: Cuelist 2
07:47:42 WARN  ProjectManager - Loading Cue Lists in Project
07:47:42 WARN  ProjectManager - Error loading complete Scenelist Cuelist 1. There could be a loss of information! in Cuelist 1
07:47:42 WARN  ProjectManager - A Cuelist with the ID 70ff8bf9-eb8c-4f62-8ae5-65370c96d2b3 doesn't exist in Go: Cuelist 2

Füge ich der Cuelist 1 dann im Nachgang noch eine weitere Cue hinzu, wird deren Inhalt aktualisiert und es tauchen die bereits existierenden wieder auf. Auch der Project Explorer berichtigt die Zahl der in der Cuelist 1 enthaltenen Cues. Alternativ kann ich das Projekt durch manuelles Handanlegen an der Datei Scenenlists.xml wieder ohne Fehlermeldung vollständig zum Laufen bekommen, indem ich dort den zugehörigen Eintrag zur Special Cue entferne.

Im Hinblick auf die Zusammenfassung dieses Tickets, würde ich folgende alternativen Erwartungshaltungen formulieren, um das Problem zumindest dahingehend zu lösen, als dass mir nicht die gesamte Cuelist 1 um die Ohren fliegt:

• Bereits beim Löschen einer Cuelist wird geprüft, ob diese ggf. per Special Cues in anderen Cuelists referenziert ist. Ist dem so, erscheint wie beim Löschen von Geräten oder Gerätegruppen der Reference Manager, wo ich zum einen auf diesem Umstand hingewiesen werde und zum anderen festlegen kann, ob ich die zu löschende Cuelist referenzierenden Special Cues komplett löschen möchte.
• Beim Laden des Projekts bietet mir die “Fehlerbehebung” an, die defekten Special Cues zu löschen anstelle den Fehler nur zu ignorieren. Hierbei wird effektiv gesehen der Schritt nach einer Bestätigung entsprechend vom Programm ausgeführt, den ich wie beschrieben manuell vorgenommen habe.

Zur Nachtverfolgung habe ich das defekte Projekt beigefügt. Da der Eintrag im Kernel eindeutig ist, verzichte ich auf das beifügen weiterer Log-Dateien.

Das beigefügte Projekt kann insofern nicht vollständig geladen werden, als dass die entsprechend zugeordneten Executoren mit ihren Einstellungen nicht geladen werden. Die Bänke sind vorhanden, aber ohne gefüllte Executoren. In den Logfiles sind zahlreiche Einträge zu finden.

Das ursprüngliche Projekt habe ich dabei nur in DMXC 3.3 Beta 2 importiert und aufgerufen. Neu gespeichert wurde es mit der 3.3 nicht.

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

Ich denke, es ist sinnvoll den FileImport abzukürzen, wie bei den FFT-Tiffs, es macht vor allem sinn bei Vielen, oder großen Dateien.
Dies würd weniger Resourcen auf nicht so leistungsstarken rechner binden.
Ich schreibe das Ticket gerade wärend 33 mp3s importiert werden und der laptop ist grad nicht so responsiv xD

Project laden,
SoftDesk Öffnen
MacroBoardProfil öffnen
Converter-Effecct auf die Matrix in der StatgeView legen und warten bis es knallt

Im Softdek kann man einen eingefügten SLider nicht sehen(außer drei Strichen). Ändert man den Style, dann kann man ihn richtig sehen.
Alpha 8

Im Zuge der Programmierung des Projekts für den Club22 fiel mir auf, dass die DMX-Refreshrate sowohl in DMXControl 3.2.2 als auch in DMXControl 3.3 sichtbar absackt, wenn ich in:

• DMXControl 3.2.2 die Farbe über einen Parametermaster mittels des Swatooth-auf-Hue-Workaround live manipulieren möchte
• DMXControl 3.3 direkt hierfür die Colormaster verwende.

Um das Problem zu zeigen habe ich das beigefügte Projekt aufgebaut. Darin sind 375 Generic RGB und eine Gerätegruppe sowie 4 Cuelists enthalten:

• 1: Trapezoid-Effekt auf Dimmer und Colormaster 1 und 2 auf Farbe in einer Cue
• 2: Trapezoid-Effekt mit gleichen Parametern aus Cuelist 1 auf Dimmer
• 3: Colormaster 1 und 2 auf Farbe
• 4: Farbe fest entsprechend der aktuellen Einstellung der Colormaster programmiert, einmal über RGB und einmal über HSV

Führe die Cuelists aus, erhalte ich folgende DMX-Refreshraten entsprechend der Statusmeldung des Kernels:

• nur 1: 21,2 Hz bei 20% CPU-Auslastung und ~16250 DMX-Werten / Sekunde
• nur 2: 25,4 Hz bei 20% CPU-Auslastung und ~27500 DMX-Werten / Sekunde
• 2 und 3: 22,7 Hz bei 19,5% CPU-Auslastung und ~16800 DMX-Werten / Sekunde
• 2 und 4 (RGB): 29,5 Hz bei 18,8% CPU-Auslastung und ~18200 DMX-Werten / Sekunde
• 2 und 4 (HSV): 29,3 Hz bei 17,8% CPU-Auslastung und ~18300 DMX-Werten / Sekunde

Die CPU lief während der Ausgabe mit einem Takt von 1,39 GHz, weil der PC auf Akkubetrieb lief. Selbst im Netzbetrieb vermeldet der Kernel einen merklichen Unterschied, wo die CPU mit 3,15 GHz getaket ist:

• nur 1: 55,9 Hz bei 11,3% CPU-Auslastung und ~21700 DMX-Werten / Sekunde
• 2 und 4 (HSV): 67,1 Hz bei 8,6% CPU-Auslastung und ~21050 DMX-Werten / Sekunde

Dieser Effekt verstärkt sich mit entsprechend zunehmender Anzahl an Geräten im Projekt bis hin zu dem Punkt, dass es bei der Nutzung der Colormaster oder dem Pendant des Workarounds in DMXControl 3.2.2 hier die DMX-Ausgabe merklich sichtbar stockt, während der Weg über das Starten einer Cuelist mit fest eingestellter Farbe beim gleichen Effekt deutlich runder läuft.

Da dieses Problem aktuell noch beide Versionen von DMXControl 3 betrifft, habe ich als “betrifft Version” DMXControl 3.2.2 gewählt.

Marcel hat eine neue Version der Nodle_USB.dll erstellt. Diese Anpassung muss in DMXControl 3 selbst noch entsprechend vorgenommen werden.

Die neue Version wird im Nodle Config Tool bereits verwendet.

Ich hab jetzt ein Update von zwei Nodle U1 auf die Version 1.06 gemacht.
Soweit alles gut, nur als ich beide im DMXC 3.2.1 eingebunden hatte schreibt der Kernel immer bei dem zuletzt in WIN 10 eingebundenen Nodle das er den Heartbeat vermisst.
Wenn ich ein IF in DMXC deaktiviert lasse kommt die Meldung nicht mehr.
Es sind aber beide Interfaces im WIN-Geräte-Manager registriert.
DMXC Forum 2 x Nodle U1 mit V1.06 - Heartbeat-Problem

Ich deregistriere alle Sinks/Sources wenn ich ein Plugin stoppe.
Wenn ich das Plugin wieder starte sollten alle Sources/Sinks die ich registriere die selben IDs haben wie vorher und alle Sinks/Sources sich wieder binden

Im InputAssignment fehlt noch die Strg+U Funktion, um den Wert eines Kästchens auf alle ausgewählten Kästchen zu kopieren, so wie dies bereits in Cuelists funktioniert.

IM angehängten Projekt sind nur 2 Cuelists enthalten, einmal “Cuelist hakt”(das Orignal) und eine Kopie dergleichen. Wenn ich nun die Originale mit Go(cuelist läuft im Loop-Modus) durchklicke, hakt diese spätestens im 4. Komplettdurchlauf bei irgendeiner Cue und bleibt für ein paar Sekunden dort stehen. Dies kann man im Editor an der “Current Cue” gut beobachten.
Bei der Kopie der Cuelist tritt dieses Phänomen nicht auf.

Hinweis: Es handelt sich um ein ehmals großes Projekt, was um alles gekürtzt wurde, was nicht rein muss.

Die Leistungsaufnahme von Geräten, bei denen Effekte auf die Matrix oder Radix gelegt werden, wird in den Ampmetern nicht angezeigt/ berücksichtigt. Dies ist auch bei den Positionsänderungen aufgefallen.

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.

Es sollte eine Option geben, mit der eich einstellen kann, wann die Cuelists gestoppt werden
Immidiantly
AfterFadeIn
AfterFaderIn(Kill)

Ich habe vorgefertigte Presets in einer neuen Cue-Liste eingebaut.

Die Presets bestehen lediglich aus jeweils einer Farbeinstellung, sonst nichts weiter.
Jetzt wollte ich von einer Farbstimmung in die andere überfaden.
Beim Abspielen werden die Fade-Werte aber scheinbar ignoriert.
Es kommt immer zu einem harten Farbwechsel/Übergang.
Was ist falsch?

Screenshots im Anhang

Ich habe die Cuelists A, B und C. Die Cuelists A und C sind bereits einer Cuelist Group zugeordnet. Nun lege ich noch Cuelist D an. Alle Cuelists A bis D möchte im Anschluss nun der gleichen Cuelist Group zuordnen, wähle dazu alle aus und ziehe die Cuelists auf die Cuelist Group. Nun sperrt mir die GUI das Ablegen der Auswahl, da ja bereit eine Cuelist (hier A und C) innerhalb der Auswahl bereits im Ziel (also der Cuelist Group) enthalten ist.

Das “Sperren” ist in dem Sinne unschön (weswegen ich das Ticket als Fehler gekennzeichnet habe) und vom Workflow her ineffektiv ist, dass ich immer vorher erst schauen muss, was ist im “Zielordner” (meist Cuelist Group, Device Group, Stage View und Eletricity Management) bereits enthalten. Im zweiten Schritt muss ich über eine Mehrfachauswahl die Cuelists o. ä. anwählen, die ich dem Zielordner hinzufügen möchte. Hierbei laufe ich aber Gefahr, entweder Cuelists zu vergessen oder ich erwische doch nochmal eine, die bereits in der Cuelist Group enthalten ist, worauf ich die Auswahl nochmal ändern oder möglichst alle Cuelists einzeln der Cuelist Group zuordnen muss.

An dieser Stelle wünsche ich mir einen Workflow, bei dem diese “Vorabkontrolle” entfällt, ob eine Cuelist in einer Cuelist Group enthalten ist oder nicht.

Auch wenn das Verhalten bereits in der 3.1 schon so war, habe ich das Ticket mal mit zur 3.2 gepackt, weil es hier nun nochmal explizit aufgefallen ist.

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.

Die im Screenshot dargestellte Eingabe wird mir als fehlerhaft gekennzeichnet, obwohl ich gemäß des Tooltipps im richtigen Wertebereich liege.

Wenn ich wie im beigefügten Projekt zwischen mehreren Cuelist mit Hilfe einer Cuelist Group direkt (also hart und ohne Fades) wechseln möchte, so erfolgt beim Umschalten kurzzeitig keine Ausgabe. Dies ist sowohl in der Stage View als auch in der Channel Overview zu beobachten.

Im Anhang befindet sich ein entsprechendes Testprojekt. Um das Problem zu reproduzieren, einfach über die Executoren zwischen den drei verlinkten Cuelists wechseln.

Das Ticket entstammt aus einer Rückfrage im Forum, wo das Problem auch schon bei DMXControl 3.1.3 aufgefallen ist.

Aus meiner Sicht könnte es hilfreich sein, wenn die automatischen Regeln zum Erstellen eines Graphen nicht nur im Hintergrund in der Tabellenansicht angewendet werden, sondern auch in der Graphenansicht selbst.

Beispiel: ich ziehe in der Graphenansicht den Button eines Softdesks auf das GO einer Cuelist und einen Slider auf die Intensity. Die erste Verbindung wird gemäß der Standardvorgaben automatisch um den Binary Switcher erweitert, die zweite um einen Rule of Three.

Getestet mit Build 1572

Da durch das Electricity-Feature nun ein weiteres Icon in der Menü-Leiste des Project-Explorers hinzugekommen ist, würde ich nun die generelle Sortierung überdenken und stelle folgenden Vorschlag in den Raum:

1. Create Cuelist
2. Add Device
3. Create Cuelist Group
4. Create Device Group
5. Create Executor Page
6. Add Softdesk
7. Add Power Source
8. Create Stage View
9. Create Item List
10. Import Files

Da die Sortierung meinem persönlichen Empfinden entspricht, habe ich das Ticket mal auf Usability Relevant gestellt und ein paar Personen eingeladen. Die aktuelle Anordnung der Icons in der Menü-Leiste sind im Anhang zu sehen.

Siehe Titel

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.

Im Fenster Device Control ist alternierendes Fanning bei den Werten für die Farbkanäle nur mit zwei Werten möglich, werden mehr als zwei eingegeben (und natürlich durch ‘#’ getrennt) werden beim Bestätigen mit Enter nur die ersten zwei Werte übernommen. Anders ist dies bei der Dimmer-Eigenschaft, hier können auch drei Werte abgewechselt werden. Bitte ausbessern ;)

• Anfang und Ende eines Adressbereichs für ein Gerät besser kennzeichnen, zum Beispiel durch abgerundete Ecken
• Adresse in die Mitte verschieben(Fett), Darunter dann der DMX-Wert
• Vergrößerung der Balken für Kanalwerte(auf voller Breite aber hinter Adresse und Value)
• Highlighting der Kanäle der gerade in der StageView ausgewählten Geräte
• Farbliche Kategorisierung der einzelnen Kanalfunktionen wie Dimmer, Color, Position, Gobo, Strobe / Shutter (ENTSCHEIDUNG)

Hab gesehen, das meine PSX-575 auf Frost und Iris einen Pulse Effekt haben, der Fehlt noch in der HAL.

Evtl. gibts noch andere Eigenschaften die das haben.

Mit einem einfachen Chaser kann man zwar ein Random-Strobe generieren, jedoch sind diese Einstellungen an die Anzahl der aktiven Geräte innerhalb einer Gruppe gebunden und bei dem einfachen Chaser ist immer nur ein Gerät aktiv.
Der Random-Strobe-Chaser geht über den einfachen Chaser hinaus und sollte über folgende Parameter zum Einstellen verfügen. Die nachfolgend genannten Parameter sollen dabei unabhängig von der Anzahl der aktiven Geräte innerhalb der Gruppe gelten.

• Anzahl der gleichzeitig aktiven Geräte
• Zeit Dimmer an
• Zeit Dimmer aus
• Zufällige Pausenzeit
• Maximale Helligkeit
• Zufälliger Helligkeitswert / Mindestwert
• Laufrichtung des Strobes (vorwärts, rückwärts, von der Mitte aus, zur Mitte hin, zufällig)

Die zufällige Pausenzeit soll den Strobe-Effekt zufällig entsprechend unterbrechen, sofern hier ein Wert eingetragen ist.

Ist ein Wert im Feld „zufälliger Helligkeitswert“ gesetzt, soll hier durch jedes Gerät leuchtet immer mit einer anderen zufällig generierten Helligkeit zwischen dem Mindestwert und dem Maximalwert, wobei der Wert „zufälliger Helligkeitswert“ den Mindestwert angibt. Auf diese Weise lässt sich gerade bei einer größeren Zahl an Geräten eine besondere Tiefenwirkung erzielen.

Ein zusätzlicher Clou wäre an dieser Stelle, wenn sich der Wert für die Anzahl gleichzeitig aktiver Geräte live vom Softpult aus beeinflussen ließe, beispielsweise über die Effekt-Speed der Cueliste.

s.o.

Es gibt keine Tests für Autoprepare, das sollten wir ändern.

s.o.

Funktioniert nicht bei:
10 Sharpys per selektion und 10 Generic PARs Per selektion in den selben Cue gespeichert.

Funktioniert bei:
10 Sharpys(diesmal aber als Gruppe) und keine weiteren geräte in einen Cue gespeichert.

P.S.
Jens-Peter soll mal bitte genau testen ;)

MfG
Patrick

Wenn ich die Größe einer Matrix nachträglich über die Properties ändere (egal ob Vergrößerung oder Verkleinerung), kommt diese Änderung im PropertyGrid zahlenmäßig erst an, nachdem ich einmal den Matrix FormEditor geöffnet und mit OK wieder geschlossen habe. Die Matrix-Effekte kommen nach (und auch während) der Änderung allerdings direkt richtig an. In den meisten Fällen sollte dieser Schritt meiner Meinung unnötig sein und könnte aktuell noch zu Verwirrungen führen.

Color

Wheelrotation, Random

Prisma

• Anzahl Facetten im DDF ergänzen

Rotationen

Pulsed Rotations (Können auch gut Simuliert werden)
=⇒ Constant Pulse (Puls immer x HZ (über HAL Settings konfigurierbar) und Geschwindigkeit geht auf Drehgeschwindigkeit)
=⇒ Variable Pulse (Geschwindigkeit immer x % (über HAL Settings) und Pulsfrequenz auf Geschwindigkeit)

=⇒ Kann über Rechteck Effekt auf Rotation nachgebaut werden, daher kleine Priorität.

Virtuelles Farbrad =⇒ Wie normales Farbrad, aber auch bei RGB Geräten möglich

Splitfarben

=⇒ Gehen voll ab! Anpassung überall wo Farben verwendet werden. Eigener Struct mit Start, End Farbe und % Wert

Zoom, Focus, Iris, Frost

⇒ Zoom: Angabe in °, von klein nach groß
⇒ Focus: Angabe in %
⇒ Iris: Angabe in %, von offen nach zu
⇒ Frost: Angabe in %, von kein Frost bis voll Frost

Blendenschieber

⇒ 4 Modi:
1. Pro Blende 2 Ecken
2. Pro Blende Einfahren und Winkel
3. Pro Blende Einfachen und Rotation
4. Pro Blende Einfachen + Gesamtrotation

⇒ 1 und 2 lassen sich gemeinsam behandeln und ineinander umrechnen.

Farbtemperatur

1. Slot auf dem Farbrad
2. Separater DMX Kanal (wie RGBW)
⇒ Korrekturkanäle mit Realwerten (von Kalt nach Warm, also 7000K - 5600K)

RGB+ Geräte

1. Separate Regler für W und A (und sonstige LEDs)
=⇒ Kaltweiß und Warmweiß
2. Bei Weiß 3 Modi:
⇒a. Weiß hinzufügen
⇒b. RGB mit Zunahme von Weiß ausfaden
⇒c. Weiß gar nicht automatisch dazumischen (muss also manuell hinzugefügt werden)

Nebel

⇒ Heat und Cool Kanal ⇒ Fanspeed

Es wäre super, wenn man innerhalb einer Cuelist auch mit absoluten Zeitangaben arbeiten könnte, die relativ zum Start des Abspielens eine Cuelist zu verstehen sind.

Beispiel: eine Cuelist wird manuell gestartet. 9 Sekunden nach Start soll der zweite Schritt beginnen, 20 Sekunden nach Start der dritte Schritt. Dann wäre es prima, wenn man einfach schreiben könnte:

Cue 1 manual
Cue 2 “absolute follow” 9s
Cue 3 “absolute follow” 20s

wobei sich das “absolute follow” 20s der Cue 3 auf t0 von Cue 1 bezieht.

Es wäre ebenfalls schön, einen Trigger “Absolute Wait” hinzuzufügen.
Dieser soll sich - ähnlich wie “Absolute Follow” - auf eine bereits mehrere Cues zurückliegende Cue beziehen.

Beispiel:
Cue 1 Manual
Cue 2 “(Absolute) Wait” 9s
Cue 3 “Absolute Wait” 20s

Der Triggerwert von Cue 3 bezieht sich dabei auf Cue 1.

Eine erste Diskussion hierzu findet bereits im Forum unter

http://www.dmxcontrol.de/forum/index.php?page=Thread&threadID=8599

statt.

Es wird immernoch nicht der Node für Random in Gobowheel und Colorwheel gelesen bzw. wird nich angezeigt und kann deshalb nicht drauf zugreifen.

MfG
Patrick

Die DMX Werte eines geparkten Geräts werden eingefroren. Erst wenn es wieder ausgeparkt ist werden aktuelle Werte übernommen und ausgegeben.

Diskussion zu diesem Punkt hier:
https://forum.dmxcontrol-projects.org/index.php?thread/11895-2016-06-29-entwicklermeeting

Wichtig: Effekte müssen weiterlaufen, Neue Effekte und Programmierung wird nicht auf Geräte übertragen

Wenn ich einen Kreis in einem Cue ändere, wäre es schön, angeben zu können, ob

a) die Änderung ab hier gilt ⇒ neue Wert wird in diesem Cue gespeichert und die Info weiter getrackt
b) die Änderung nur in diesem Cue ⇒ der neue Wert wird in diesem Cue gespeichert, in dem darauffolgenden wird der ursprüngliche Wert eingetragen (Cue only)
c) die Quelle ändern. ⇒ Das Cue, in dem der Kreis ursprünglich auf den wert gesetzt wurde, wird geändert.

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.

Manuelles Überfaden in Szenenliste einbauen über InputLayer Regler