Bugtracker DMXControl 3

G1: D1, D2
G2: D3, D4
G12: G1, G2

SDG = G12, D5, D3, Dimmer At 0 > 100

       | Dimmer
-------|-------------
-G12   |
  -G1  |
    D1 |   0
    D2 |  25
  -G2  |
    D3 |   -
    D4 |  50
D5     |  75
D3     | 100

SDG = G12, Dimmer At 0 > 100

       | Dimmer
-------|-------------
-G12   | 0 > 100
  -G1  |
    D1 |   0
    D2 |  33,33
  -G2  |
    D3 |  66,66
    D4 | 100

zusätzlich SDG = G2, Color At 0,0,0 > 255,0,0

       | Dimmer  | Color
-------|---------|------------
-G12   | 0 > 100 |
  -G1  |         |
    D1 |   0     |
    D2 |  33,33  |
  -G2  |         | 0,0,0>255,0,0,0
    D3 |  66,66  | 0,0,0
    D4 | 100     | 255,0,0

SDG = G12, G1, D3, D1 Dimmer At 0 > 100

       | Dimmer
-------|-------------
-G12   | 
  -G1  |   -
    D1 |   -
    D2 |   -
  -G2  | 
    D3 |   -
    D4 |   0
-G1    | 
  D1   | 
  D2   |  33,33
D3     |  66,66
D1     | 100

Zusätzlich
SDG = G12 Color 0;0;0 > 255;0;0

       | Dimmer | Color
-------|--------|------------
-G12   |        | 0;0;0 > 255;0;0
  -G1  |   -    |
    D1 |   -    | 0;0;0
    D2 |   -    | x;0;0
  -G2  |        |
    D3 |   -    | y;0;0
    D4 |   0    | 255;0;0
-G1    |        |
  D1   |        |
  D2   |  33,33 |
D3     |  66,66 |
D1     | 100    |

Zusätzlich
SDG = D4, G1, D1, Iris 0 > 255

       | Dimmer | Color           | Iris
-------|--------|-----------------|-----
-G12   |        | 0;0;0 > 255;0;0 |
  -G1  |   -    |                 |
    D1 |   -    | 0;0;0           |
    D2 |   -    | x;0;0           |
  -G2  |        |                 |
    D3 |   -    | y;0;0           |
    D4 |   0    | 255;0;0         |
-G1    |        |                 |
  D1   |        |                 | -
  D2   |  33,33 |                 | 1
D3     |  66,66 |                 |
D1     | 100    |                 | 2
D4     |        |                 | 0

Zusätzlich
SDG = D2, G2, Zoom 0 > 255

       | Dimmer | Color           | Iris
-------|--------|-----------------|-----
-G12   |        | 0;0;0 > 255;0;0 |
  -G1  |   -    |                 |
    D1 |   -    | 0;0;0           |
    D2 |   -    | x;0;0           |
  -G2  |        |                 |
    D3 |   -    | y;0;0           |
    D4 |   0    | 255;0;0         |
-G1    |        |                 |
  D1   |        |                 | -
  D2   |  33,33 |                 | 1
D3     |  66,66 |                 |
D1     | 100    |                 | 2
D4     |        |                 | 0
D2     |        |                 |       |  0
-G2    |        |                 |       |
  D1   |        |                 |       | 50
  D2   |        |                 |       | 100

Vorschlag (siehe Kommentar):
SGD = G12, Dimmer At 100

       | Dimmer
-------|-------------
-G12   | 100
  -G1  | 100
    D1 | 100
    D2 | 100
  -G2  | 100
    D3 | 100
    D4 | 100

Die Darstellung oben wird schnell sehr unschön.
Ich denke folgendes wäre besser.
Es gibt 2 Ansichten.
In der ersten sieht man seine Selektionen. Für jede Selektion eine eigene Reihe.
Wird die Selektion mehrfach verwendet, (Color, Zoom) werden die Werte in schon vorhandene Reihe geschrieben.
In einer weiteren Ansicht werden nur die Geräte mit den gefannten Werten dargestellt. Da könnte man z.B. noch ein Tooltip einbauen, das aufgeht wenn man länger auf einer Zelle bleibt, wo drinsteht, wo der Wert herkommt. D1 Dimmer: G12, G1, D3, D1 0 > 100. Ich denke so macht das mehr Sinn und ist übersichtlicher.

(Detail Expanded)

                 | Dimmer  | Color           | Iris    | Zoom
-----------------|---------|-----------------|---------|---------
-G12, G1, D3, D1 | 0 > 100 |                 |         |
  -G12           |         |                 |         |
    -G1          |   -     |                 |         |
      D1         |   -     |                 |         |
      D2         |   -     |                 |         |
    -G2          |         |                 |         |
      D3         |   -     |                 |         |
      D4         |   0     |                 |         |
  -G1            |         |                 |         |
    D1           |   -     |                 |         |
    D2           |  33,33  |                 |         |
  D3             |  66,66  |                 |         |
  D1             | 100     |                 |         |
-G12             |         | 0;0;0 > 255;0;0 |         | 0 > 100
  -G1            |         |                 |         |
    -D1          |         |   0;0;0         |         |   0
    -D2          |         |   x;0;0         |         |  25
  -G2            |         |                 |         |
    -D3          |         |   y;0;0         |         |  50
    -D4          |         | 255;0;0         |         | 100
-D4, G1, D1      |         |                 | 0 > 100 |
  -D4            |         |                 |   0     |
  -G1            |         |                 |         |
    -D1          |         |                 |   -     |
    -D2          |         |                 |  50     |
  -D1            |         |                 | 100     |

(Detail, Collapsed)

                 | Dimmer  | Color           | Iris    | Zoom
-----------------|---------|-----------------|---------|---------
+G12, G1, D3, D1 | 0 > 100 |                 |         |
+G12             |         | 0;0;0 > 255;0;0 |         | 0 > 100
+D4, G1, D1      |         |                 | 0 > 100 |

(Device view, collapsed)

   | Dimmer | Color   | Iris | Zoom
----|--------|---------|------|------
+D1 | 100    |   0;0;0 | 100  |   0       <-  Tooltip für Dimmer: G12, G1, D3, D1: 0 > 100 
+D2 |  33,33 |   x;0;0 |  50  |  25
+D3 |  66,66 |   y;0;0 |      |  50
+D4 |   0    | 255;0;0 |   0  | 100

Kommentare?

Edit: 09.06.14
(Device view, with details expanded)

                   | Dimmer  | Color           | Iris    | Zoom
-------------------|---------|-----------------|---------|--------
-D1                | 100     | 0;0;0           | 100     |   0
  -G12, G1, D3, D1 | 0 > 100 |                 |         |
  -G12             |         | 0;0;0 > 255;0;0 |         | 0 > 100
  -D4, G1, D1      |         |                 | 0 > 100 |
-D2                |  33,33  | x;0;0           |  50     |  25
  -G12, G1, D3, D1 | 0 > 100 |                 |         |
  -G12             |         | 0;0;0 > 255;0;0 |         | 0 > 100
  -D4, G1, D1      |         |                 | 0 > 100 |
-D3                |  66,66  | y;0;0           |         |  50
  -G12, G1, D3, D1 | 0 > 100 |                 |         |
  -G12             |         | 0;0;0 > 255;0;0 |         | 0 > 100
-D4                |   0     | 255;0;0         |   0     | 100
  -G12, G1, D3, D1 | 0 > 100 |                 |         |
  -G12             |         | 0;0;0 > 255;0;0 |         | 0 > 100
  -D4, G1, D1      |         |                 | 0 > 100 |

In der Cuelist sollte es bei jedem Cue ersichtlich sein, ob eine Property Fade/Delay Zeit eingestellt wurde. (aus  FS#704 )

Letzten Monat oder habe ich über Effekte nachgedacht, und da das jetzt auch im Forum aufgeschlagen ist:

Ich möchte auf Position einen Circle haben.
Und auf den Schutter einen Rectangle. Der Shutter soll ab einer bestimmten Position zugehen und ab einer anderen wieder aufgehen.
Ich möchte diese Positionen einmal am Rectangle einstellen und ab dann werden die Effekte automatisch synchronisiert. D.h. wenn ich beim Circle die Phase/Frequenz/etc. ändere sollen diese auch beim Rectangle so eingestellt werden, dass sich die Positionen nicht veändern.

Natürlich müssen die Positionen auch beim abspielen der Cues reproduzierbar sein.

Anderes Beispiel wäre_
Auf Tilt befindet sich ein Sawtooth. Abwärtsbewegung langsam und sichtbar und die Aufwärtsbewegung soll so schnell wie möglich sein. Während dieser Bewegung soll der Shutter geschlossen sein.

Wird eine Cueliste (1) durch eine andere Cueliste (2) gestoppt, sollte es möglich sein, dass die Cueliste 1 statt ihre eigene Release Zeit die GoTo Zeit von Cueliste 2 verwendet.

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

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.

Meines Wissens nach kann derzeit im TCP ausschließlich mit dem TC aus dem TCP gearbeitet werden. Um die Arbeit mit einer externen Software zu erleichtern wünsche ich mir die Möglichkeit TC zu empfangen (also Netzwerk- und/oder MIDI-Timecode von einem anderen Gerät in DMXC einspeisen um damit Shows im TCP auf andere Sachen zu synchronisieren) und TC zu senden (also Netzwerk- und/oder MIDI-Timecode ausgeben um damit externe Geräte auf das Licht zu synchronisieren).

Parameter Master in Group Handling ermöglichen. In Verbindung mit Effekten die z.B. ein Fanning von 0#100 haben würden sich viele odd and even Effekte in deutlich weniger Cuelisten bauen lassen.

Autosave ist standardmäßig deaktiviert. Bei neuen Installationen ist dies dementsprechend nicht aktiv und führt zu Problemen wenn mans vergisst zu aktivieren.

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.

Wunsch: Parameter-/Speed-Master in Release Time von cuelists ermöglichen.

Beim Bedienen von Slidern im Softdesk springt der Wert zu der Stelle, auf die man gedrückt hat und folgt dem Cursor direkt (oder dem Finger bei einem Touchscreen). Deswegen wäre ein zusätzlicher relativer Bedienungsmodus praktisch, bei dem man egal wo auf den Slider klicken und ihn dann hoch und runter schieben kann.

Das kann gerne auch für Maus und Touch einzeln ausgewählt werden, wie bei dem Capture Modus.

AudioAnalyser als Auswahlmöglichkeit für BeatSource der CueList hinzufügen. Das ermöglicht vom AudioAnalyser erzeugte Beat-Steuerung, die nicht einen gleichmäßigen Beat erzeugt (wie ManuelBeat oder Speedmaster).
Die Erweiterung ermöglicht evtl. auch anderen Erweiterungen/Plugins sich an dieser Stelle einzubinden.

AL: Vorbereitung erledigt. Frank muss Plugin anpassen

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

Schlosssymbol Funktion in Kamera Steuerung. Aktivieren/Deaktivieren “Kamera fixieren”

Im Moment ist das Icon für “fixiert die Icons”

Fixieren der Icons sollte weiterhin möglich sein aber vieleicht an anderer Stelle.
Als Vorschlag aus “Icons” ein Drobdown Menue was Icons betrifft, Alias-Icon hinzufügen, Alias-Icon löschen, Icons fixieren. Ähnlich wie bei Anzeigen/Ausblenden.

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

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

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

So zum Beispiel:

XOOO
OXOO
OOXO
OOOX
XOOX
OXOX
OOXX
XOXX
OXXX
XXXX

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

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

Hallo liebe DMXControler,

ich hätte eine Idee für den zukünftigen Timecodeplayer in DMXC3.
Wenn im TICOP (faule Bezeichnung für TImeCOdePlayer ) ein Audiofile abgespielt wird, soll dieser ja verschiedene Effekte bzw. Szenen für das Licht abspulen.
Gleichzeitig könnten in dem Player noch ein paar Spuren (ähnlich wie in einer DAW) integriert werden, in denen man MIDI-Signale an externe Geräte schicken könnte.
Z.B. wäre es dann möglich, dass beim Abspielen des Audiofiles gleichzeitig noch Midi-Signale an einen Mixer mit Motorfadern gesendet werden, welcher die angeschlossenen Mikrofone steuert. Dies wäre ein sehr nützliches Features für Theatherproduktionen.

LG
Jelu

P.S. Momentan benutze ich Ableton als Steuerprogramm für DMXC2 (Audioplayer) und eines Digitalmixers (Behringer X32). Wenn das direkt mit integriert wäre, könnte man eine Drittsoftware wie Ableton weglassen.

Effekte können ja schon vieualisiert werden. Es wäre aber auch gut, wenn das “Ergebnis” mehrerer überlagerter Effekte visualisiert werden könnte. Wenn ich also beispielsweie auf der Position eine Epizykloide und ein Lissakour überlagert habe, möche ich im Effektvisualizer das Ergebnis sehen, wenn ich “Position” selektiere. Gerne auch noch mit der Verschiebung beispielsweise durch die Werte bei “Pan” und “Tilt”. Denn die Auswirkungen auf die Properties sind genauso interessant wie die reinen Effekte.

Aktuell gibt es keine Möglichkeit festzustellen, welche Cuelist, Programmer etc. aktuell eine Eigenschaft eines Gerätes wie z.B. die Position ansteuert. Es sollte daher ein neues Fenster geben, welches zum einen ähnlich wie der Programmer alle Geräteeigenschaften auflistet, die verändert wurden. Dabei sollte aber bei diesem Fenster die generelle Ausgabe im Vordergrund stehen. Wenn mehrere Quellen etwas z.B. auf eine MH-Position ausgeben, sollten alle Quellen in einer Liste dargestellt werden. Dabei sollten diese Werte wenn möglich visuell dargestellt werden (z.B. die entsprechenden Farben oder Gobos darstellen). Die Darstellung der einzelnen Quellen erfolgt in Listenform mit klarer Reihenfolge der (virtuellen) Prioritäten. Sprich hier soll aufgezeigt werden, welche Quelle als nächstes im Eingriff ist, wenn die aktuelle Quelle nicht mehr auf die Geräteeigenschaft ausgibt (daher virtuelle Priorität, da dies auch bei LTP-Mischung angezeigt werden sollte). Des weiteren sollte es auch möglich sein, eine Quelle zu muten (mindestens folgende Optionen: bis zum Beenden der Quelle, dauerhaft muten) und die Reihenfolge der Quellen z.B. per Drag&Drop anzupassen (dann aber evtl. auch mit definierbarer Überblendzeit).

Es sollte eine Möglichkeit geben, Funktionen, die ein Plugin nachgerüstet hat als solche zu identifizieren. Hintergrund ist, dass das MIDI-Plugin Dynamic Executors in das Input Assignment hinzufügt, es aber nicht klar wird, dass diese aus dem MIDI-Plugin stammen. Daher sollte es wo möglich eine (wie auch immer geartete) Anzeige geben, die diesen Umstand mitteilt. Sonst erzeugen nämlich Plugins neue Funktionen in der Software und es wird nicht ersichtlich, woher diese Funktionen kommen bzw. die User könnten für diese Funktionen Support verlangen, obwohl das Team diesen nicht liefern kann.

Autoprepare funktioniert nur, wenn der Dimmer und der Shutter in der ersten Cue einer Cuelist auf 0 bzw. closed gespeichert werden. Dadurch kann man aber AP in der ersten Cue nicht verwenden und man muss wieder eine zusätzliche Preparation-Cue einfügen. Wenn aber der aktuelle Gerätezustand als virtuelle 0. Cue behandelt wird, kann auch die erste Cue von AP profitieren. Wenn dabei auch die Triggertime berücksichtigt wird, macht das auch bei der ersten Cue in einer Cuelist nichts aus. Außerdem löst man noch frei Haus zusätzlich das Problem, dass man beim Einblenden eines LED-Scheinwerfers jedes mal die Fadetime der Farbe auf 0 setzen muss, damit das sauber aussieht.

Der Update-Button sollte zusätzlich in den Header des Cuelist-Editors und des Preset-Fensters eingetragen werden. Der Button sollte kontextsensitiv sein. Sprich nur in dem Fenster, aus dem die zu aktualisierende Cue kommt, darf der Button nicht ausgegraut sein. Alle anderen sind ausgegraut.

Der Button im linken Schnell-Menü sollte kontextsensitiv sein. Sprich der Name der aktuellen Cue / des aktuellen Presets sollte angezeigt werden.

Folgender Aufbau einer Cuelist:
- Cue1 Follow, Triggervalue 0ms Fadetime 2s
- Cue2 Follow, Triggervalue 0ms Fadetime 4s
- Cue3 Wait, Triggervalue 500ms Fadetime 0ms
- Cue4 Wait, Triggervalue 500ms Fadetime 0ms
- Cue5 Wait, Triggervalue 500ms Fadetime 0ms

Die Cue2 braucht also länger, als Cue3 - Cue5 zusammen. Nun wird die Cuelist nach dem Ende von Cue5 released, auch wenn Cue 2 noch läuft.

Bei normalen Cues wird deren Status (Zeit bis zum Einblenden, Einblendvorgang etc.) mit den verschiedenfarbigen Statusbars dargestellt. Es wäre gut, wenn es bei Audio Cues in dieser Statusbar auch eine Anzeige für die Restlaufzeit der Audio Cue gäbe.

Aus diesem Thread: https://forum.dmxcontrol-projects.org/index.php?thread/15425-par-strahler-lauflicht-mit-geschwindigkeitssteuerung/ kam mir die Idee von "Dimmerkur​ven" für den Trapezeffekt? Sprich der Effekt wird um zwei Dropdown-Einträge erweitert, mit denen man für Fade Up und Fade Down jeweils bestimmen, mit welcher Kurve gefadet wird (linear, Sinus-ähnlich, ….). Dadurch hätte man deutlich mehr Kontrolle über das Verhalten. Das macht natürlich die anderen Effekte nicht überflüssig, weil man da natürlich noch eine feinere Einstellmöglichkeit hat.

Test/Idee: Wenn möglich, sollten alle Effekte einen Schalter für “Bounce” bekommen, wodurch der mathematische Effekt umgekehrt durchlaufen wird. Außerdem sollte die “Laufweite” (Anfangswinkel und Endwinkel) des mathematischen Effekts einstellbar sein.

Der Wertebereich der Pan- und Tilt-Eigenschaften von Geräten sollte jeweils mittels einer Ober- und Untergrenze eingeschränkt werden können.

Immer wieder kommt es vor, das man einen Graphen im Input Assignment eines Users debuggen muss. Hierfür braucht man zwingend ein Bild. Allerdings ist das bei komplexeren Graphen manchmal schlecht bis gar nicht zu lesen. Daher wäre es für diese Arbeit sehr wichtig, wenn man einfach die anzuzeigenden Nodes auswählen könnte, dann einen Rechtsklick auf einen der Nodes machen könnte und das als Bild exportieren könnte (egal ob png, jpeg etc.). Hierbei sollte die Auflösung immer so sein, dass man den Text auf jeden Fall lesen kann (also durchaus eine Standardaufösung möglich, dann wird halt das Bild etwas größer). Am Besten wäre es, wenn man auch noch den Ausschnitt mit den Inputs und Outputs der ausgewählten Nodes drauf hat. Wählt man keinen Node aus und exportiert das Bild, dann wird einfach der ganze Graph gespeichert.

Mit einem Doppelklick werden ja Geräte eingeschaltet (Dimmer auf 100% und Shutter auf). Allerdings gibt es keine Maus- und/oder Tastenkombination, mit der man “Nox” betätigen kann. Das würde dann auch im Programmer landen, was für manche Situationen (Theater) sinnvoll ist. Für andere aber nicht. Daher bräuchte es auch noch eine dritte Kombination, um entweder die Dimmer- und Shutter-Werte oder alle Parameter für das entsprechende Gerät aus dem Programmer zu löschen.

Was definitiv im Softdesk fehlt ist eine “Center”-Funktion. Sprich ich möchte ein Control einerseits bezüglich des aktuell zur Verfügung stehenden Softdesk-Bereichs zentern und andererseits auch bezüglich anderer Objekte. Wenn ich also mehr als zwei Objekte auswähle, möchte ich, dass diese zwischen dem zuerst und zuletzt ausgewählten / am weitesten links und rechts befindliche Objekt gleichmäßig verteilt werden (welches von den beiden muss noch überlegt werden). So habe ich dann auch gleich eine Zentrierfunktion, wenn ich drei Objekte auswähle.

Ich fände es gut, wenn das Snapping (pinke Linie) nicht nur beim Verschieben wirken würde, sondern auch bei der Änderung der Größe eines Controls oder Labels.

In DMXC 3.2.2 können bei der Angabe von Mastern im Device Control schon Rechnungen angegeben werden und hier gibt es auch einen Parameter für die Anzahl der Geräte in der angesteuerten Gerätegruppe (CONST). Ich fände es gut, wenn man Rechnungen auch direkt in den Properties angeben könnte. Dies ist dann sinnvoll, wenn beispielsweise ein Effekt per Fanning auf der Phase auf 8 Scheinwerfer verteilt werden soll. Aktuell muss man hier das Fanning entsprechend angeben, wodurch es angepasst werden muss, wenn sich die Anzahl der Geräte in der Gruppe ändert. Durch einen Parameter wie den COUNT Parameter könnte man dies elegant umgehen.

Ein weiterer Anwendungsfall wäre, wenn mehrere Effekte überlagert werden sollen. In diesem Fall muss man das Fanning per Offset verschieben. Man könnte sich Arbeit sparen, wenn man das Offset per Rechnung angeben könnte (natürlich auch für gefannte Werte, um das ganze Fanning zu verschieben). Die Frage wäre noch, ob die Rechnung wenn möglich aufgelöst werden soll oder nicht. Beides hätte seine Vorzüge. Das Auflösen ist übersichtlicher, nicht auflösen könnte bei Offsets deutlich einfacher sein.

Matrix-Filter sollten eine Index-Property erhalten, die das selbe macht wie bei einer Gobo-Index Funktion. Sprich die Ausrichtung von Matrix-Filtern soll entsprechend rotiert werden können. Wenn das zu aufwändig ist, sollte zumindest in einem ersten Schritt eine Drehung in 45 / 90° Schritten möglich sein.

Es gibt ja Matrixfilter, die gerichtet (Bewegung in eine Richtung) und ungerichtet (keine Bewegung / Bewegung um zentralen Punkt herum) sind. Hierfür sollte es eine Kategorisierung ähnlich der 1D, 2D, etc. Effekte geben um die Übersichtlichkeit zu erhöhen.

In diesem Ticket werden verschiedene Matrix-Effekte gesammelt.

Color Wave

Wave

Effekt-Wrapper

Sea Waves

2D Spektrometer

Möchte man mit einem Projekt an verschiedenen Locations arbeiten, muss man einfach die nicht benutzten Geräte deaktivieren. Hat man aber recht viele Geräte, kann das durchaus auch einmal länger dauern, bis man alle entsprechenden Geräte deaktiviert / aktiviert hat. Daher wäre es gut, wenn man auf irgendeine Art und Weise “Locations” (Name TBD, alternativ tatsächlich “Mute Groups”) im Projekt hinterlegen kann, denen dann einzelne Scheinwerfer zugewiesen werden können. Aktiviert man eine “Location”, werden alle anderen Scheinwerfer deaktiviert, die nicht in der “Location” sind. So muss man nur noch einmalig die einzelnen “Locations” definieren und kann recht schnell zwischen verschiedenen Veranstaltungsorten wechseln.

Weitere Erwartungshaltungen:
- Man kann trotzdem ein anderes Gerät wieder aktivieren, auch wenn es nicht in einer “Location” enthalten ist. Das muss dann händisch passieren und es hat keine Auswirkung auf die Locationzugehörigkeit (beim nächsten Mal muss man es wieder händisch aktivieren, wenn das gewünscht ist)
- Es können auch mehrere “Locations” aktiv sein. Die aktiven “Locations” werden verodert.
- Deaktiviert man alle “Location”, werden alle Geräte aktiviert

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

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.

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

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

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

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

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.

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

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

Seit Implementierung von  FS#4973  wird immer die Projekt Administration geöffnet, wenn sich die GUI verbindet und noch kein Projekt geladen ist. Nun soll dieses Verhalten erweitert und einstellbar gemacht werden. Es wird ein GUI Setting benötigt, um wählen zu können, ob die Projekt Administration geöffnet wird (bisheriger Case), ein gewisses Default-Projekt geladen wird (z.B. für Festinstallationen) oder nichts passiert. Für Case 2 muss noch in der Projekt Administration und im Project Store integriert werden, dass ein Default-Projekt ausgewählt werden kann.

Im Timecode Player sind nur Cuelists mit Timecode Trigger erlaubt. Daher können bestehende Cuelists, in denen auch andere Trigger verwendet werden, nicht in den Timecodeplayer eingefügt werden. Es wäre gut, wenn es hierfür eine Art Konvertierung gibt, die das ermöglicht. Am besten mit Abfrage, ob dieser Eingriff wirklich gemacht werden soll, weil das die Cuelist grundlegend ändert. Das aber nur anbieten, wenn das wirklich geht, denn Manual- oder Beat-Trigger können nicht konvertiert werden. Zu klären ist nur noch, ob der Fade-Speed mit eingerechnet wird oder nicht. Möglich wäre auch, diese Funktion als Konvertierungsfunktion im Menü der Cuelist anzubieten