Bugtracker DMXControl 3

Ich habe festgestellt, dass der Parameter “Play Mode” des Color Chasers sich ausschließlich auf die Wiedergabereihenfolge der zugeordneten Color List bezieht. Ich habe bei aktiviertem “Use Device Index” aber keine Möglichkeit, eben diesen zu beeeinflussen. Egal ob Play Mode “Normal”, “Bounce” oder “Reverse”: die optische Laufrichtung des Color Chasers bleibt immer die selbe.

Daher wünsche ich mir für den Color Chaser im Endeffekt alle Parameter zusätzlich, die in den neuen Chaser Einzug erhalten haben:

• Fade Curve
• Break Steps
• Break Time
• Size
• Step Size
• Play Direction (Play Mode für Device Index)

Hinter dem Parameter Play Direction versteckt sich zum einen eben die bis dato fehlende Ansteuerung des Device Index, zum anderen aber auch die bereits für den einfachen Chaser implementierten Play Modes inklusive der Möglichkeit, per csv-Datei weitere eigene zu hinterlegen. Wenn ich dies richtig überblicke, können die Play Modes des neuen Chasers 1:1 auf den Color Chaser zur Ansteuerung des Device Index übertragen werdem.

Durch dieses Update könnte es eventuell sein, dass der bis dato vorhandene Parameter “Index Offset” überflüssig wird, weil er in einer der neuen aus dem neuen Chaser übergeht.

Stand heute gibt es beim PWM Static nur die Möglichkeit, eine Gruppe von Geräten entsprechend der Position des zugeordneten Parameter Masters “aufzufüllen”. An dieser Stelle wünsche ich mir die Möglichkeit, eine feste Anzahl von Geräten (zum Beispiel 3) mittels des Parameter Masters innerhalb der Gerätegruppe hin- und herzuschieben. Beim Minimal- bzw. Maximalwert des Parameter Masters leuchten dann immer drei Geräte am entsprechend korrespondierenden Ende der Gerätegruppe. Bei 50% würden in der Mitte vier Geräte leuchten (die beiden mittleren mit 100%, die äußeren mit je 50% leuchten), wenn Fade auf True gesetzt ist und die Gruppe eine gerade Anzahl von Geräten umfasst.

Hierzu bedarf es neben dem zusätzlichen Parameter für “Size” auch einen weiteren Eintrag für den Parameter “Direction”, der beispielsweise “Group” lauten könnte. In diesem Zusammenhang wäre zu überlegen, ob nicht eine Umbenennung des Parameters “Direction” in “Play Mode” erfolgt.

Im dynamischen PWM-Effekt müssen diese Ergänzungen nicht vorgenommen werden, weil sich dieses Szenario mit dem neuen Chaser abbilden lässt, sofern der Effekt eben automatisch laufen soll.

Beim Verfassen des Tickets FS#4759 ist mir aufgefallen, dass der neue Chaser um vier weitere Play Modes erweitert werden kann:

• Fill from left (>)
• Fill from right (<)
• Fill from center (<>)
• Fill to center (><)

Diese vier zusätzlichen Play Modes stammen aus dem dynamischen PWM-Effekt. Aus meiner Sicht sind diese vier anderen Play Modes der einzige Unterschied, der zwischen dem neuen Chaser und dem dynamischen PWM-Effekt existiert. Von daher würde ich in diesem Zusammenhang vorschlagen, den dynamischen PWM-Effekt nach der Übernahme der oben genannten Play Modes in den neuen Chaser zu entfernen.

Ich habe in DMXControl 3.2.3 einen Fader im Softdesk der z.B. die Goborotation regelt.
Wenn ich jetzt eine Gerätegruppe in der Bühnenansicht auswähle und die Goborotation über die Gerätesteuerung ändere dann ändert sich auch der Fader im Softdesk.
Es ändert sich allerdings nicht der Fader im Steuerungsfenster für die Gobos.

Ich habe mit LightningBrothers geschrieben und er meint es handelt sich um ein Bug. Er hat mich geben ein Ticket anzulegen. Anbei seine Antwort:

“Ich habe mir das mal angeschaut und festgestellt, dass du einen Bug im Slider gefunden hast. Das Problem tritt auf sobald der Minimalwert unter 0 liegt und du den Style “Rounded” oder “Custom” ausgewählt hast. Änderst du den Style auf “Slim Gnob”, reagiert der Slider auch. Wenn du magst, darfst du hierzu gerne ein Ticket in unserem Bugtracker anlegen, wo du nochmal das Problem beschreibst, im Idealfall ein Beispielprojekt anfügst und auch meine Hinweise / Erkenntnisse mit aufnimmst.”

Im Zuge der Freischaltung der Funktion “Gruppen in Gruppen” (siehe  FS#674 ) soll das Group Handling dahingehend erweitert werden, dass

• eine nachvollziehbare Ansteuerung auch über n Ebenen möglich ist und dabei nicht für jeden Anwendungsfall eine neue Gruppe angelegt werden muss
• ggf. auf unterschiedlichen Ebenen ein unterschiedliches Group Handling ausgewählt werden kann
• das Group Handling weitere Funktionen anbietet

Das beigefügte Projekt soll einen exemplarischen Aufbau zeigen, bei dem die Ansteuerung der insgesamt 100 Beam-MHs und 12 Spot-MHs am Ende durch ein verbessertes und erweitertes Group Handling deutlich variantenreicher erfolgen soll, ohne zusätzliche Gruppen anliegen zu müssen. Insgesamt gibt es bis zur Device-Ebene drei Gruppen-Ebenen. Folgende Szenarien sollten exemplarisch anhand eines Lauflichts einfach darstellbar sein, wobei sich diese Liste ggf. bei weiteren Überlegungen noch beliebig weiterspinnen lässt:
* Lauflicht innerhalb eine gesamte Zeile über die 25 Spalten hinweg (25 Geräte, Laufrichtung links rechts), egal ob nur bezogen auf eine Zeile oder ein paralleles Lauflicht über alle fünf Zeilen
* Lauflicht innerhalb eines Blocks, beginnend oben links, endend unten rechts
* Lauflicht über die fünf / sechs Zeilen hinweg (Laufrichtung oben unten), egal ob nur bezogen auf eine Spalte oder parallel auf allen 20 Spalten
* Lauflicht über alle 24 Einzel-Zeilen, wo immer fünf bzw. drei Geräte gemeinsam ein- und ausgeschaltet werden
* Lauflicht über die vier Blöcke, wo immer 28 Geräte gemeinsam ein- und ausgeschaltet werden
* Gegenläufige Lauflichter aus der oberen Gruppe heraus, wo Zeilen 1, 3 und 5 links-rechts und Zeilen 2 und 4 rechts-links wiedergegeben werden

Hallo Zusammen,
wie im Stream von euch angeboten das Tickes zu einem Zusätzlichen Effekt wie Sparkle.

Unter Wave/ Lauflicht (Chaser/PWM) verstehe ich einen Effekt der auf der Farbe liegt und diese beeinflusst.

Erstmal die Attribute:

• Fade-In Time (ms): Zeit wie lange der Farbwechsel beim einfaden dauert

• On Time (ms): Zeit wie lange die Farbe gehalten wird

• Fade-Out Time (ms): Zeit wie lange der Farbwechsel beim ausfaden dauert

• Duration (ms): Zeit zwischen dem Start der ersten Lampe und dem Start der nächsten Lampe, Idealerweise mit dem „Speed master“ steuerbar, wird nicht von Fade-In Time beeinflusst

• Run: bei loop, der Durchlauf wird wiederholt, bei single, wird nurch einmal durchgelaufen

• Revers: bei nein, ablauf der Schritte hochzählend (1-2-3-4), bei ja, ablauf der Schritte Rückwärts (4-3-2-1)

• Ping-Pong: nein, der Ablauf beginnt wieder von Vorne (1-2-3-4|1-2-3-4|1-2-3-4|…), bei ja läuft der Ablauf einmal Vorwärts und danach rückwärts und dann wieder vorwärts usw. (1-2-3-4-3-2-1-2-3-4)

Revers und Ping-Pong sind ähnlich dem Play Mode im Chaser

Ablauf:
Start bei Beginn der Gruppe
1: X|0|0|0
2: 0|X|0|0
3: 0|0|X|0
4: 0|0|0|X

Start Mittig der Gruppe
1: 0|0|0|X|X|0|0|0 / 0|0|0|X|0|0|0
2: 0|0|X|0|0|X|0|0 / 0|0|X|0|X|0|0
3: 0|X|0|0|0|0|X|0 / 0|X|0|0|0|X|0
4: X|0|0|0|0|0|0|X / X|0|0|0|0|0|X

Bei “Beginn der Gruppe” wurden weniger Lampen gewählt als bei “Mittig der Gruppe”, damit die Anzahl der Schritte gleich sind.

Wenn das Lauflicht sich einholt, dann soll wieder vom aktuellen Punkt wieder Einfaden, hier würden sich die Zeitkurven einer Lampe überlagern, ähnlich der Zeitkurve im Bild 010.png zu sehen. Blau ist der erste Durchlauf, grün der zweite Durchlauf und rot sich der ergebene Ablauf. Falls der überschneidende Bereich nicht existiert, dann bleibt die eingestellte Farbe gleich und der Lampe fehlt Zeit zurück zufaden.

Wenn sich zwei verschiedene Lauflichter sich überlagern, soll vom jetzigen Zeitpunkt, vom ersten Lauflicht in das zweite hineingefadet werden, ähnlich Bild 020.png

Das fanning der Farbe könnte sich nicht auf den Beginn der Grupe bis Ande der Gruppe legen, sondern Beginn des Lauflichtes Schitt 1 bis zum letzten Schritt

Gruß
Max

Edit 1: genauere Beschreibung ergänzt

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.

Ich habe eine einfache Cuelist mit zwei Cues gebaut, die in Schleife wiedergegeben wird:

1. Cue 1: Dimmer [100%], Farbe [ColorMaster 1]
2. Cue 2: Dimmer [100%], Farbe [ColorMaster 2]

Beide Color Master habe ich mir in den verschiedenen Modi RGB, CMY und HSV in eine Executor Page geliegt.

Jenachdem, welchen Color Master Typ ich nutze, um die Farbe einzustellen, ändert sich der Farbübergang zwischen den beiden Cues. Entweder direkt oder entlang des Farbkreises. Dass die Kombination des Farbtypes / Farbmodells den Fade beeinflusst, ist grundsätzlich bekannt (siehe Ticket FS#4279).

An dieser Stelle kann es zu Verwunderungen führen, wenn eben dieses Verhalten nicht bewusst ist. Die Verwunderung kann noch größer sein, wenn man einmal die Farbe per Fader festlegt (der als HSV konfiguriert ist) und dann die Farbe per Button setzt - innerhalb eines Executorzugs. Auch dies beeinflusst den Farbübergang.

Grundsätzlich kann man diesen Punkt dokumentieren, bis er sich bei der Umsetzung des Tickets FS#4279 “erledigt”. Die Frage ist aber, ob dies ein praktikabler Weg ist und ob es nicht besser wäre, dem ColorMaster eine Einstellung mitzugeben, dass er die Farbe nur intern in einem bestimmten Farbmodell vorhält.

Aus der Erfahrung heraus gibt es für LED-Scheinwerfer eine Reihe von Farben, die man gerne wiederverwendet, weil man weiß, dass sie auf den Geräten gut aussehen. Solche Farben sind aber oft Mischfarben. Diese Mischfarben kann man mit einem Fader jedoch nur schwer schnell und reproduzierbar “treffen”.

Grundsätzlich besteht die Möglichkeit, diese Farben in mehreren Cuelists zu speichern, gerade wenn man sie über mehrere Geräte unterschiedlich aufrufen möchte. Um das Projekt flexibler zu gestalten, kam mir daher der Gedanke, dass man durch die Kombination eines Color Masters auf einem Executor mit einer selbst definierten Color List ggf. vereinfachen könnte. Hierzu wähle ich statt eines Faders wie Hue, Saturation, Red oder ähnlich eine meiner vorbereiteten Color Lists aus. Auf Basis dieser Color List erhält man im Bereich des Faders statt des Faders untereinander angeordnete Buttons mit den Farben aus der ausgewählten Color List. Damit ließen sich eigene Farben entsprechend schneller anwählen und man benötigt für einen Color Master auch nur einen Executor-Zug.

Erstelle ich ein Fanning mit den Fanning-Operatoren ?, ?? oder ?# in Kombination mit einem Master, so werden die Werte kontinuierlich neu berechnet, obwohl ich den zugehörigen Master gar nicht anfasse. Das Problem ist mir unter anderem bei folgenden Eingaben aufgefallen:

• Dimmer: 0 ? {ParameterMaster 1}
• Color: 255; 255; 255 ?# {ColorMaster 1}

Die Erwartungshaltung ist an dieser Stelle eigentlich, dass die Werte nur neu berechnet werden, wenn

• die entsprechende Cue erneut aufgerufen wird
• man den Wert des zugehörigen Masters ändert

Wähle ich bei einem Gerät mit zwei Goborädern (hier Futurelight DMH-160) von beiden Goborädern je ein Gobo aus, erscheint im Programmer die folgende Anzeige statt des Klartext “1: Gobo 2, 2: Gobo 7” inklusive des zugehörigen Icons (siehe Bild 1).

Wechsele ich über das Gobo Control in der Gesamtübersicht auf nur ein Gobo, sieht die Anzeige wieder sauber aus. Es fehlt hier aber auch die Vorschau des Gobos (siehe Bild 2). Hierzu erscheint in den Logs der GUI parallel folgender Eintrag:

2022-02-24 18:19:28,125 [Log-Thread] DEBUG Lumos.GUI.Resource.ResourceManager - Resource ICON-001189.png of type Symbol and source Default could not be loaded!
2022-02-24 18:19:28,127 [Log-Thread] DEBUG org.dmxc.lumos.XNAViews.TextureManager - Added Texture: ICON-001189.png

Grundsätzlich die Datei dem Programm sowohl im Installationsverzeichnis als auch über das Projekt entsprechend vor.

Beim Arbeiten mit den neuen Chaser ist mir aufgefallen, dass folgende zusätzlichen Parameter den neuen Chaser noch weiter aufwerten und flexibler gestalten würden:

• Repeat size: Legt fest, ab welcher Geräte-Nummer innerhalb der Gruppe das ausgewählte Muster wiederholt wird. Umfasst meine Gruppe acht Geräte und ich trage in diesem Parameter “4” ein, habe ich beim Play Mode “Normal” quasi zwei Chaser über nur vier Geräte.
• Offset Steps: Legt wie der Name schon sagt einen Offset in Schritten fest. Füge ich den Chaser bei einer Gruppe von acht Geräten zweimal auf den Dimmer ein und trage bei einem der beiden Chaser für diesen Parameter eine “3” ein, folgt dieser Chaser dem anderen mit entsprechenden Verzug von drei Schritten. Damit sind zwischen den beiden hellen Geräten zwei Geräte dunkel.

Mir ist wohl bewusst, dass ich diese Muster grundsätzlich auch mittels eigens programmierter Chaser erstellen kann. Dies ist aber meiner Meinung nach für solche generischen Parameter aber eher der umständliche Weg.

Der Übersicht halber habe ich dieses Ticket mal mit den bereits exitsierenden Tickets zum Chaser verknüpft, die auf eine Funktionserweiterung abzielen.

Beim Einfügen des bereits existierenden List Selectors kam mit der Gedanke zu folgendem neuen Node auf: dem “Item List” Node.

Das Item List Node gehört zur Kategorie der Wrapper-Nodes und ermöglicht das Arbeiten mit im Projekt existierenden Item Lists wie Gobo List, Color List oder Position List. Entsprechend der gewählten Liste stellt es die folgenden Ein- und Ausgänge zur Verfügung.

Eingänge

• Item List: Wählt die Item List mit der entsprechenden ID oder dem Namen
• Select: Übergabe eines ganzzahligen Werts zur Auswahl eines bestimmten Objekts in der Item List
• Previous: Auswahl des vorherigen Objekts
• Next: Auswahl des nachfolgenden Objekts

Ausgänge

• Name: Name der zugeordneten Item List
• ID: ID der Item Liste
• Items: Ausgabe der Liste der enthaltenen Werte wie die verschiedenen Farben bei einer Color List, Gobos der Gobo List etc.
• Item count: Anzahl der Objekte in der Liste
• Selected Item: Ausgabe des ausgewählten Eintrags

Ein möglicher Anwendungsfall für das Item List Node wäre zum Beispiel die “zentrale” Verwaltung von Farben für den Status eines Buttons im Softdesk oder auf einem Makro Board. Bis jetzt ist ein üblicher Weg, die verschiedenen Farben in einem Input Selector zu hinterlegen. Verwendet man die gleichen Farben mehrfach muss auch der Input Selector mehrfach konfiguriert werden. Mit Hilfe des Item List Nodes würde die Farbdefinition zentral im Project Explorer erfolgen. In den betreffenden Connectionsets greift man dann nur noch den Index der Liste auf. Möchte man die Farben im Nachgang nochmal ändern oder mit einer weiteren Farbe arbeiten, muss man hier auch nicht mehr alle Input Selecotren einzeln anfassen und die Farbe hinterlegen. Es muss stattdessen nur dafür gesorgt werden, dass der benötigte Index am Item List Node ankommt, wenn es nicht bereits vorher schon der Fall war.

s.o. (Reminder für JPK, siehe Projekt SpeedMaster Slider Beispiel)

Zum aufräumen im SpeedMaster

Mausrad scrollt, Strg + Mausrad - Zoomen (oder anders rum) –> Aktuell Zoomt man nur mit dem Mausrad

Wenn ich bei einem Executor die Auto Start / Stop Funktion verwende, funktioniert das automatische starten immer mal wieder nicht. Sobald ich den Fader auf null und direkt danach wieder hoch ziehe, startet die Cuelist nicht.

Hällt alle daten cuelists exexutoren, alles und ist im project umschaltbar und kann usern zugeordnet werden

Eine Cueliste die den i halt einer anderen Cueliste 1 zu eins als refferenz übernimmt, aber seperat ausgeführt werden kann

Selection Grid siehe MA
Als Diskussionsgrundlage

S.o.

Ein Lauflicht im Außenkreis wobei der erste Pixel immer der hellste ist und dahinter immer dunkler sind:
https://ak.picdn.net/shutterstock/videos/1034400863/thumb/5.jpg?ip=x480

“Linienscanner” - Ein Senkrechter Strich, der von links nach rechts durchwandert. Der Strich kann im Winkel gedreht werden, sodass bei 90° der Strich waagerecht von oben nach unten durchläuft

Es wäre cool, wenn man mit den Colormastern irgendwie die Radix Pixel ansteuern könnte. Z.b. im Radix Popup die Möglichkeit schaffen für Color 1 und Color 2 einen Colormaster auswählen zu können.
Alternativ nen Filter bauen, wo man zwei CM als Farbe eintragen kann und der dann die Ringe alternierend mit einer Farbe ausfüllt.

Mehreren Nutzern ist aufgefallen, dass der Cuelist Monitor nach dem Laden eines Projekts erst auf die Eingaben per Touchscreen reagiert, wenn man in ihn initial einmal mit der Maus geklickt hat. Beispiele für diese Aussagen sind folgende Threads:

• https://forum.dmxcontrol-projects.org/index.php?thread/16136/&postID=135955#post135955
• https://forum.dmxcontrol-projects.org/index.php?thread/16526/&postID=138901#post138901

Ich baue mir aktuell mehrere Cuelists mit einer höheren Priorität, bei ich laufende Cuelists gezielt für folgende Lichtstimmungen überschreibe:

• Moderationslicht
• Einmarsch
• Siegerehrung
• Spiegelkugel-Ambiente

In allen Fällen nutze ich für die jeweiligen Lichtstimmungen meist die gleichen Geräte, die sonst auch für die allgemeine Show mitlaufen. Habe ich nun solche Mehrfachverwendungen, muss ich aktuell immer manuell dafür sorgen, dass ich in den zugehörigen Cuelists zum Beispiel die Gobos und Prismen herausnehme oder den Strobe gezielt auf 0 setze, wenn ich eine “saubere” Ausgabe haben möchte. Sprich: auch wenn ich einen Strobe-Effekt abfeuere, soll das Gerät für das Moderationslicht nicht mit stroben. Dies wird insbesondere bei Moving Heads mit ein paar mehr Funktionen immer aufwendig.

Um die Programmierung zu vereinfachen, würde ich mir eine Möglichkeit wünschen, bei der ich gezielt festlegen kann, dass für in der Cuelist nicht verwendete Funktionen automatisch die Grundwerte von den verwendeten Geräten herangezogen werden. So müsste ich dann für das Spiegelkugel-Ambiente nur Dimmer, Position, Farbe und Iris festlegen. Andere Funktionen wie Gobo oder Prisma werden beim Starten auf die Werte gesetzt, die die Geräte als Default einnehmen (Gobo offen, kein Prisma, kein Strobe).

Hallo liebes DMXControll 3 Team,
ich hätte eine Anregung für die Stage-View. Ich fände es cool wenn man, eine Gerätegruppe in der StageView aktiviert man die enthaltenen Geräte visuell hervorgehoben werden und die Sortierung der Geräte in der Gerätegruppe wie bei einer manuellen Anwahl in der StageView zu sehen wäre.

Ich freue mich auf ein Update und finde euer Programm super.
Danke LG
Arne

Im Ticket  FS#3722  kam der Wunsch auf, die Ports der Art-Net-Ausgabe etwas sinnvoller zu sortieren, dass immer direkt 8 Universen am Stück adressiert werden. Durch das neue Ausgabe-Plugin hat sich dieser Dialog in der Hinsicht vereinfacht.

Als Folgeproblem hat sich aber nun durch das neue Ausgabe-Plugin für Art-Net ergeben, dass jedes weitere immer mit dem 1. DMX-Universum angelegt wird - und war sowohl innerhalb der Übersicht der DMX-Interfaces als auch in den erweiterten Einstellungen selbst. Um das Anlegen mehrerer Art-Net-Interfaces zu vereinfachen und zu beschleunigen, sollte hier an beiden Stellen bei den DMX-Universen automatisch “hochgezählt” werden. Net und Subnet bleiben konstant.

In den meisten Anwendungen gibt es einen globalen Shortcut [ctrl] + [s], um das aktuelle Dokument zu speichern. Im Idealfall wird der Shortcut auch im Menu angezeigt (siehe Menu von Firefox).

Ich weiss nicht, ob dieses Verhalten Absicht ist, jedenfalls finde ich es verwirrend und counter-intuitive: Im Stage View muss ein Gerät zuerst mit einem Linksklick angewählt werden, um es zu verschieben oder das Kontextmenu mit einem Rechtsklick zu öffnen.
Gegenbeispiel: beim Windowsdesktop ist es nicht nötig, eine Datei/Verknüpfung zuerst explizit auszuwählen. Geradezu verwirrend finde ich es, dass ein Rechtsklick auf ein nicht ausgewähltes Icon das Kontextmenu des StageViews öffnet anstatt des Gerätes.

Rechts oben gibt es einen ‘Netz’ Button und ein weisses Suchfeld (?). Beide sind nicht interaktiv, es gibt kein Tooltip und auch kein Kontextmenu. Als neuer User habe ich keine Ahnung was das ist.

Die Modifier (m/f/c) zum Anordnen der Geräte/Gruppen sind nicht aus DMXC erkennbar, bzw. man muss davon wissen.
Vorschlag: in der Menuleiste drei Toggle-(Radio)-Buttons hinzufügen, welche über die Tasten umgeschalten werden, aber auch per Maus/Touch nutzbar sind.
Es gibt in der Menuleiste genügend Platz dafür.

Bad practice: Bei den vertikalen Buttons auf der linken Seite sind die meisten Tooltiptexte identisch mit den Buttonlabels und somit redundant. Das Tooltip sollte die Buttonaktion erklären, wie z.B. bei ‘Blackout’.

In der Kanalübersicht gibt es links einen vertikalen Slider. Leider gibt es kein Tooltip oder sonstigen Hinweis, was der Slider macht.
Vorschlag: Tooltip und Dokumentation im Wiki hinzufügen

Ich fände es gut, wenn es neben der Releasetime (die letztendlich der Einblendzeit einer Cue aber eben für das Ausblenden entspricht) auch ein Releasedelay gäbe. Hintergrund hierfür ist der Übergang zwischen mehreren Cuelists des selben Typs. Wenn man ein modulares Cuelist-Schema verwendet, hat man mehrere Cuelists, die nur eine Geräteeigenschaft, wie z.B. den Dimmer anspricht. Um einen weichen Übergang zwischen den Cuelists hinzubekommen, muss man die Releasetime der ausblendenden Cuelist und die Fadetime der ersten Cue der einblendenden Cuelist so geschickt wählen, dass der Übergang nicht auffällt. Das Problem ist nämlich, dass man eine zu kurze Releasetime dadurch sieht, dass die Scheinwerfer kurz ausblenden, bis die zweite Cuelist übernimmt und einblendet.

Dieses Problem könnte man mit einem ReleaseDelay und LTP-Cuelists ganz einfach umschiffen, indem man dann das ReleaseDelay auf die gleiche Länge setzt, wie die Fadetime der ersten Cue der einblendenden Cuelist. Die Releasetime würde man dann auf 0 setzen. Dadurch hat man bei LTP einen weichen Übergang, ohne dass die Scheinwerfer kurz ausblenden.

Der Wunsch resultiert aus folgendem Anwendungsfall heraus: ich möchte zum Beispiel einen Moving-Head für eine Szene sehr exakt positionieren, um ein Objekt oder eine Person optimal zu beleuchten. Die grobe Position kann ich noch mit Hilfe des Position Panel oder auch über eine Abschätzung der Positionswerte finden. Geht es aber dann daran, die Position auf ein paar Zentimeter genau einzustellen, muss ich aktuell immer die Werte für Pan und Tilt im Device Control ändern. Die Regler für Pan bzw. Tilt sind hier ebenfalls nicht feinfühlig genug.

Grundsätzlich ist es zwar möglich, dass ich mir im Vorfeld ein entsprechendes Connectionset für diesen Anwendungsfall baue. Dies benötigt jedoch jedes Mal Zeit, wenn man ein neues Projekt erstellt oder muss es in vorhandenen Projekten nachpflegen. Darüber hinaus beschränkt sich dies dann auch immer nur auf bestimmte Funktionen.

Daher wünsche ich mir, dass unter anderem im Device Control die Möglichkeit geschaffen wird, über Tastatur-Shortcuts oder über Buttons mit der Maus die Werte für die Gerätefunktionen inkrementell und mit einer feinen Abstufung zu ändern.

Fehlerbeschreibung

Erwartetes Verhalten

Lösung

Lösungsvorschlag 1

Lösungsvorschlag 2

Fallen Graphen im Input Assignment etwas umfangreicher aus, verschwinden die Inputs und Outsputs zwischen den teilweise großen Nodes. Um die Inputs und Outputs besser im Graphen zu finden, wäre es gut, wenn diese farblich hervorgehoben werden.

Fehlerbeschreibung

{ParameterMaster 1:*360/COUNT*(COUNT-1)}

Erwartetes Verhalten

Hinweise

Wie bereits im Forum mit @JPK besprochen (https://forum.dmxcontrol-projects.org/index.php?thread/16686-probleme-bei-benutzung-berechneter-phase) wäre es praktisch eine Konstante zu haben, die den (Phasen-)Winkel zwischen den Geräten einer Gruppe angibt. Um das umzusetzen müssten folgende Punkte implementiert werden:

* Erlauben von Berechnungen im Device Control
* Einführung der Konstante DEVICEANGLE (wäre wohl als 360/AnzahlAnGeräten zu definieren?)

Die eingestellte Sprache im Drop-Down-Menü des Installers ändert nicht die Sprache der GUI.

Nachdem ich in letzter Zeit bei einigen kleinen Veranstaltungen DMXC vorbereitet habe, habe ich gemerkt dass folgendes für einige User nicht erkenntlich ist: In DMXC sind zwar einige DDFs vorhandenen jedoch gibt es die meisten in der online Lib von der einige Leute nichts wissen. Daher schlage ich vor dass wenn man in DMXC nach einem DDF sucht welches nicht vorhanden ist ein Hinweis mit Link auf die online Lib erscheint.

Bedienen der Stage View mit einem Touchpad ist nur sehr unbequem machbar. Es ist zwar möglich durch herauszoomen und an richtiger Stelle wieder hineinzoomen die Position in der Stage View zu ändern allerdings finde ich das sehr ungeschickt. Als bessere Lösung könnte ich mir beispielsweise Vorstellen durch gedrückte rechte Taste und gleichzeitigem bewegen auf dem Touch Pad die Position zu ändern.

Fehlerbeschreibung

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

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

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.

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

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.

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