Bugtracker DMXControl 3

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

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.

Aktuell werden die Zeiten beim Trapezoid-Effekt für alle vier Segmente (Fade up, Top, Fade down, Bottom) als absolute Zeitwerte eingegeben. Dies macht die Nutzung von Speedmastern an dieser Stelle unübersichtlich, weil ich in jedem der vier Parameter mit den Speedmastern rechnen muss. Und das teilweise doppelt, da ich zum einen erst die Gesamtgeschwindigkeit reduzieren und dann noch den Wert für die vier Parameter anpassen muss.

Um hier eine effektivere Nutzung des Speedmasters oder auch die einfachere Festlegung der Gesamtwiederholdauer zu ermöglichen, würde ich mir folgende zusätzliche Parameter im Trapezoid-Effekt wünschen:

• Neuer Parameter zur Umschaltung zwischen den absoluten Zeitanteilen in Millisekunden und den relativen Zeitanteilen in % oder 0 bis 1 für die Dauer der vier Segmente. Je nach Einstellung dieses Parameters werden die vier Parameter umgeschaltet.
• Im Falle der Wahl des Parameters “relative Zeitanteile” erscheint der neue Parameter Dauer (Duration), in dem die Gesamtdauer eines Durchlaufs angegeben wird, wo wie eingangs gesagt auch der Speedmaster zum Einsatz kommen kann.
• Parameter zum Festlegen des Bezugspunkts für den Takt. Aktuell liegt dieser Punkt fest beim Beginn des Fade Ups. Grundsätzlich lässt sich dieser Punkt zwar über den Offset-Parameter verschieben, aber spätestens bei ungleichen Dauern der vier Segmente muss man zu einem Taschenrechner greifen, um genau den Punkt “Ende Pause Top” zu bestimmen.

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.

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.

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.

Ein findiger User hat herausgefunden, dass man die Softdesks mit einem Workaround dazu bewegen kann, beim Laden des Projekts direkt im Vollbildmodus zu starten. Für die genaue Vorgesehensweise siehe https://forum.dmxcontrol-projects.org/index.php?thread/15151/&postID=128003#post128003.

Damit dies Workaround aber nicht als dauerhaft bestehen bleiben muss, würde ich mir hier eine gezielte Einstellung wünschen. Man kann zum Beispiel in den Einstellungen eines Softdesks festlegen, ob dieses normal oder im Vollbildmodus aufgerufen wird. Dies hätte den Vorteil, dass man sich ein entsprechendes Layout für die GUI abspeichern und dieses reproduzierbar wieder aufrufen kann.

Folgende Features sollte der Zeitplaner haben:

• Mehrere Einträge
• Cron-Syntax als Hintergrund und vom User eingebbar sein
• UI soll aber auch so sein, dass einfache Eingaben möglich sind
  • An spezifischen Tagen
  • Jeder n-te Tag in der Woche / Monat
  • Gewisse Wochentage
• Der Zeitplaner soll folgendes triggern können
  • Cuelists
  • Trigger im Input Assignment
  • Evtl. Executoren

Ich hatte das Problem, dass ich nicht wusste wie mein geladenes DDF funktioniert. Hier wäre es praktisch, wenn man sich das XML des angelegten Gerätes direkt in DMXC anzeigen lassen kann.

no task description

Wenn ich ein Preset auf Teile einer Szene angewendet habe, gibt es keine Möglichkeit, diese Werte vom Preset zu entkoppeln. Sprich, die Werte des Presets sollen dann kopiert werden, aber nicht mehr mit dem Preset verknüpft sein.

Wenn Button für Pause verwendet wurde, auch mit Pause-Button wieder Show laufen lassen.

Damit man nicht zum Starten immer mit der Maus hin und her rutschen muss zwischen Pause und Play.

Gruß Steff

Aktuell verfügen Cuelists nur über die Play Modes “Once”, “Loop”, “Bounce” und “Random”. Hier vermisste ich kürzlich den Play Mode “Reverse”, woraufhin ich die Reihenfolge der Cues selbst anpassen musste, um das gewünschte zu erreichen.

Mittlerweile gibt es ja beim neuen Chaser weitere gute Play Modes. Die Play Modes “Switch” und eben “Reverse” kann ich mir ebenfalls sehr gut als Play Modes für Cuelists vorstellen. Vielleicht lassen sich auch noch weitere Play Modes vom Chaser auf die Cuelists adaptieren - inklusive der Icons.

Wird aktuell ein Projekt aus einer neueren DMXC-Version in einer älteren Version geöffnet, gibt es (wohl) nur eine Warnung im Kernel-Log.
Es wäre besser, den Benutzer auch in der GUI auf das Problem hinzuweisen.

Spielt man im angehängten Projekt die Cuelist ab, erscheinen mehrere Fehlermeldungen und Warnungen im Kernel

00:13:12 WARN  SceneList - Cue Play: Begrüßung.WAV of Type org.dmxc.lumos.Kernel.Audio.AudioScene returned empty OutputValues. This can cause unintended behaviour.
00:13:12 INFO  AudioManager - Start playing Begrüßung.WAV
00:13:24 INFO  AudioManager - Abourt playing of Begrüßung.WAV
00:13:24 ERROR AudioManager - Exception at Play: Begrüßung.WAV
00:13:24 WARN  SceneList - Cue Stop: Begrüßung.WAV of Type org.dmxc.lumos.Kernel.Audio.AudioScene returned empty OutputValues. This can cause unintended behaviour.
00:13:48 INFO  Session - Saved Project to GUI KUECOREI7JPKLT, Path E:\DMXControl 3\Projects\Audiofile Demo 3.2.1 Beta4.zip
00:16:19 WARN  SceneList - Cue Play: Ansage.mp3 of Type org.dmxc.lumos.Kernel.Audio.AudioScene returned empty OutputValues. This can cause unintended behaviour.
00:16:19 INFO  AudioManager - Start playing Ansage.mp3
00:16:21 ERROR AudioManager - Exception at Play: Ansage.mp3
00:16:21 INFO  AudioManager - Abourt playing of Ansage.mp3
00:16:21 WARN  SceneList - Cue Stop: Ansage.mp3 of Type org.dmxc.lumos.Kernel.Audio.AudioScene returned empty OutputValues. This can cause unintended behaviour.

In einem mir zur Verfügung gestellten Testprojekt ist folgender Fehler im GUI-Log aufgetaucht:

2019-03-28 22:32:43,413 [Log-Thread] WARN  org.dmxc.lumos.XNAViews.GraphicsDeviceControl - Failed to Draw!
System.InvalidOperationException: An unexpected error has occurred.
   bei Microsoft.Xna.Framework.Graphics.GraphicsDevice.CreateDevice(GraphicsAdapter adapter, PresentationParameters presentationParameters)
   bei Microsoft.Xna.Framework.Graphics.GraphicsDevice..ctor(GraphicsAdapter adapter, GraphicsProfile graphicsProfile, PresentationParameters presentationParameters)
   bei org.dmxc.lumos.XNAViews.GraphicsDeviceService.ResetDevice(Int32 width, Int32 height, Boolean withoutEvent, Nullable`1 handler, Boolean hardReset) in D:\Jenkins\workspace\Lumos_3.2_Release\Lumos\LumosLIB\src\XNA\GraphicsDeviceService.cs:Zeile 146.
   bei org.dmxc.lumos.XNAViews.GraphicsDeviceControl.OnPaint(PaintEventArgs e) in D:\Jenkins\workspace\Lumos_3.2_Release\Lumos\XNAViews\src\XNAViews\GraphicsDeviceControl.cs:Zeile 449.

Das zugehörige Projekt kann ich bei Bedarf intern zur Verfügung stellen.

DMXControl 3 hat unterschiedliche Properties. Diese müssen visualisiert werden. Im folgenden sollen Vorschläge gesammelt werden, wie diese Visualisierung aussehen soll. Dabei sollen alle wichtigen Visualisierungen mit einem +++ versehen werden Bereits erledigte Visualisierungen sind als solche markiert.

• Color +++ (erledigt)
• ColorTemp (erledigt)
• Cool
• Dimmer +++ (erledigt)
• Effectwheel
• Fan –> num. Fann.
• Filter
• Focus –> num. Fann.
• Fog
• Frost –> num. Fann.
• Gobo +++ (WIP)
• Heat
• Index –> num. Fann. +/-
• Iris –> Darstellung als Iris-Blende analog zur Stage View
• Matrix –> Idealerweise Vorschau der Matrix, welche in dem Eintrag abgebildet ist
• Position +++ (erledigt)
• Prism –> kurzfristig keine Visualisierung, langfristig über ein generisch erzeugtes Bild auf Basis der DDF-Definition
• PTSpeed –> num. Fann.
• Radix –> Idealerweise Vorschau der Radix, welche in dem Eintrag abgebildet ist
• Raw –> num. Fann.
• Rotation –> num. Fann. +/-
• Scale
• Shutter +++
• Strobe +++
• Switch +++ (erledigt)
• Zoom –> Visualisierung eines Lichtkegels analog zum Programmer

Anmerkungen
Num. Fann –> Darstellung als Fanning einfacher numerischer Werte
+/- –> Darstellung wie num. Fanning, jedoch mit positiven und negativen Wertebereich, sodass der 0-Wert auf halber Höhe liegt

Für Theateraufführungen oder anderweitige Programme mit fester Abfolge wäre es sehr praktisch zu sehen was im nächsten Cue passiert. Dies könnte entweder grafisch oder in Form einer Tabelle wie z.B. im Programmer dargestellt werden. Welche Form der Darstellung gewählt wird oder beide oder gar keine Implementierung des Features, wäre noch zu entscheiden.

Wenn ich mit der Maus per Drag&amp;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&amp;Drop die Gruppe kurz das Aussehen verändert. (Irgendwo habe ich einmal eine pulsierende Reaktion in einem anderen Programm nach einem Drag&amp;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.

Es wäre cool, wenn man über das Input Assignment die Sichtbarkeit von einzelnen Softdesk Elementen ein- und ausstellen könnte.
Visibility True/ False, kennt man so zum Beispiel aus den UserForms in VBA.

Damit kann man einen Softdesk anlegen und beispielsweise zwischen Experten und Standardbedienung umschalten.
Je nach Modus würden dann unterschiedliche Softdesk-Elemente ein oder ausgeblendet werden.

Das ist hilfreich, wenn das Projekt nicht nur vom Ersteller, sondern auch von unerfahrenen Nutzern benutzt wird, die mit zu vielen Optionen überfordert wären.
In meinen Fall nutzen wir die Software in unserer Kirchengemeinde und die anderen Nutzer brauchen nicht so viele Effektmöglichkeiten wie ich.

Aus Nutzersicht wäre es super, “virtuelle” Eingänge (z.B. Go / Stop  FS#3321 ) zu haben, die im Hintergrund einen Graphen generieren. Dadurch könnten viele Standard Fälle abgedeckt werden, ohne das Input Assignment zu verschandeln.

Starte ich DMXControl 3 erstmals auf dem PC (mit Default-Einstellungen) oder ändere das Arbeitsverzeichnis über eine Umgebungsvariable, sollte hierbei überprüft werden, ob die folgenden Verzeichnisse bereits existieren:

• Pictures
• UserDevices
  • Icons
  • Images

Für den Fall, dass diese Verzeichnisse nicht existieren, sollte der Kernel diese dort automatisch anlegen - auch wenn sie anfangs leer sind. Dies ist insbesondere für die UserDevices wichtig, da ansonsten die Verknüpfung im Startmenü “ins Leere läuft” und folglich nicht funktioniert. Hierzu gab es im Forum immer wieder Mal Rückfragen, wo die Antwort dann lautete “Bitte selbst unter … anlegen”.

Wenn ich ein Preset nutze, halte ich im Nachgang keinerlei Info darüber, in welcher Form das jeweilige Preset in der Cue hinterlegt wurde. Insbesondere bei Device Presets und Property Presets lässt sich dies weder im Programmer, noch im Programmer Filter, im Device Control oder in der Cue nachvollziehen. Im Programmer wird aktuell nur mitgeteilt, dass ein bestimmtes Preset verwendet wurde.

Bei einem Reference Preset ist die Verwendungsart durch die Benennung der Cue selbst klar ersichtlich.

Ich habe an einem Projekt zuletzt viel im Input Assignment gearbeitet und wunderte mich dann, dass ein Button eines Softdesks nicht mehr funktionierte. Der Kernel sagte dann folgendes:

22:15:27 WARN  InputManager - Following Graphs are orphaned and will be removed:
S1-510-3121
S1-510-0901
S1-210-0901
S1-211-3121

Hierzu habe ich die Erwartungshalten, dass erstmal nicht grundsätzlich angenommen wird, dass verwaiste Graphen entfernt werden können. Vielmehr bedarf es hier einer Info, wie hiermit umgegangen werden soll.

Ob sich dieses Verhalten mit dem Projekt, an dem ich gerade arbeite, reproduzieren lässt, muss ich später klären und dann Logfiles und Projekt beifügen.

Getestet mit Build 1402

Der Installer legt aktuell noch nicht die Verknüpfung im Startmenü zu den eigenen DDFs an.

Moin,
wenn man im Connectionset etwas rausgezoomt hat, um die verbindungen besser zu sehen, kann es manschmal schwer sein die Verbindung zu sehen.

Gruß
Max

Wenn DMXControl 3.2 läuft, verbindet es sich mit allen vorhandenen Midi Ports. Die Folge ist, dass andere Programme, die danach gestartet werden, sich nicht mehr mit den Midi Ports verbinden können.

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.

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

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.

Es fehlt eine Kamerasteuerung wie in der Stageview.
Es fehlt ein Raster an dem man sich orientieren kann.
Es fehlt die Möglichkeit bei den Verbindungslinien Zwischenpunkte an zu legen um Verbindungen von Logiken runter ziehen zu können "saubere Kabelverlegung".

Neben dem Grandmaster wird es einen Speed (Effektgeschwindigkeit) und einen Timingmaster (Fade/Delay Zeiten) geben.

Wie bereits mehrfach besprochen sollte DMXC mehrere Modi unterstützen (Anfänger, Fortgeschrittener) sowie evtl. unterschiedliche Standard layouts (Theather, Disko,…)

Entsprechend sollten Elemente angezeigt oder ausgeblendet werden.

Hierzu muss folgendes durchgeführt werden:

1. Definition, welche Gruppen es gibt
2. Definition, was diese Gruppen sehen und was nicht
3. Implementierung des Models

Wichtig ist, dass diese Auswahl nur initial das System konfiguriert. Der User kann jederzeit in den Fortgeschrittenen Modus wechseln und dadurch mehr Dinge angezeigt bekommen.

1. Uninstaller löscht nicht alle Inhalte, wenn DMXControl geöffnet ist –> hier sollte überprüft werden, ob DMXC noch geöffnet ist und ggf. ne Info anzeigen
2. Uninstaller löscht den Installer.log nicht und den DMXControl Ordner im Programme Verzeichnis
3. löschen des Appdata Verzeichnisses optional anbieten.

Die neue UNDO/REDO-Edit Funktion im Editor würde ich nicht nach ganz oben im Rechte-Maustaste Kontext-Menü setzen, sondern tiefer.

Außerdem ist das mit der Namensgebung noch etwas unglücklich, weil direkt darunter der Eintrag “Edit in Programmer” kommt. Ich könnte mir vorstellen, dass es da - gerade für Newbies - zu Schwierigkeiten und Missverständnissen kommt.

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.

Im beigefügten Beispielprojekt habe ich vier verschiedene Inputs an das LTP-Node gehängt: Macro Board Profile, Tastatur (Umsch + 1), Push-Button aus Softdesk (Button 2) und MIDI. Lade ich das Projekt, kann ich über den Button 1 bereits die Signal Lamp einschalten, weil der LTP keinen definieren Wert übergibt, da er wiederum keinen definierten Wert von den Inputs erhält.

Dies hat bei anderen Projekten zur Folge, dass zum Beispiel ungewollt Cuelists ausgeführt werden. Zur Zeit lässt sich das nur dadurch beheben, dass ich nach dem Laden einmal alle Tasten betätigte und damit auch eine Neuberechnung des jeweiligen Connectionsset anstoße. Dabei muss ich beachten, dass beim manuellen Triggern alle Bänke aktiv sind, in denen ich die jeweiligen Input nutze. Sobald eine Bank nicht aktiv ist, behält der Input seinen undefinierten Zustand bei, wenn ich die Bank nachträglich aktiviere. Dies hat wiederum zur Folge, dass ich die dort in den Connectionset enthaltenen Inputs erneut manuell triggern muss.

Hierzu hatte sowohl ich das Ticket  FS#3958  sowie @steff das Ticket  FS#4432 . Vielleicht hat eines oder gar beide eine gewisse Relation zu diesem Ticket.

Bei diesem Punkt handelt es sich um ein Verhalten, was sowohl in DMXControl 3.2.3 als auch in DMXControl 3.3 Beta 2 gleichermaßen existiert. Um dies prüfen zu können, ist das Projekt in DMXControl 3.2.3 erstellt.

Betrifft Version 3.2.2.339 (Release)

Beim Starten des DMXControl 3 Kernels taucht folgender Fehler im Log auf, obwohl kein Enttec Interface konfiguriert/verfügbar ist:

ERROR EnttecProFactory - Unable to fetch Enttec Pro List: Entry point was not found.
System.EntryPointNotFoundException: Entry point was not found.
   at System.IDisposable.Dispose()
   at Enttec_Pro_Lib.EnttecProLib.getInterfaces() in D:\Jenkins\workspace\Lumos_DMXPlugins_Pipeline_3.2\Enttec\src\EnttecProLib.cs:line 135
   at org.dmxc.lumos.Kernel.DMX.EnttecProFactory.<get_Interfaces>d__8.MoveNext() in D:\Jenkins\workspace\Lumos_DMXPlugins_Pipeline_3.2\Enttec\src\EnttecFactory.cs:line 73
WARN  EnttecProFactory - Execution of Interfaces took 1150 ms in Factory EnttecProFactory

Hallo,
ich habe mir in meinem “großen Projekt” eine Matrix angelegt und hierzu Device Groups für das Gesamte und Teile der Matrix hinterlegt. Das Projekt wird soweit ohne Probleme geladen. Aber beim beenden hängt sich die GUI auf.

Ich habe das dann etwas kleiner nachgebaut und etwas getestet. Projekt hier von im Anhang.

Ich habe dann Objekte aus den Device Groups gelöscht und wieder hinzu gefügt. Danach kommen beim beenden diverse Fehlermeldungen im Kernel. Logfiles sind angehängt.

Gruß Steff

lch fände es gut wenn eine Möglichkeit implementiert werden würde (Node oder ähnliches) mit der es möglich wird über das Input Assignment zwischen Stage Views umzuschalten.
Dann könnte man mit Buttons im Softdesk, über DMX-In, Midi-In, wegen bestimmten Bedingungen usw. zwischen den angelegten Stage Views umschalten.

lch fände es gut wenn eine Möglichkeit implementiert werden würde (Node oder ähnliches) mit der es möglich wird über das Input Assignment zwischen Soft-Desks umzuschalten.
Dann könnte man mit Buttons im Softdesk, über DMX-In, Midi-In, wegen bestimmten Bedingungen usw. zwischen den angelegten Soft-Desks umschalten.

Moin,
Eine Idee, kann man es Realisieren das die Benennung der Geräte im Stageview ein Zeilenumbruch zu ermöglichen. Als Symbol könnte man im Namen ein Semikolon Nutzen.

Gruß
Max

Ich fände es gut, wenn “Umbra.exe” zukünftig zu “LumosUmbra.exe” würde.

Manchmal muss man ja doch den Taskmanager bemühen, um “übriggebliebene” DMXC-Komponenten abzuschießen oder auch nur nachzusehen, welche Komponenten evtl. noch laufen.
Da ist es etwas unpraktisch und vll. unerwartet, dass es neben “Lumos.exe” und “LumosGUI.exe” ganz unten in der Liste noch eine “Umbra.exe” gibt, die auch noch dazu gehört, aber eben nicht den Namensbestandteil “Lumos” enthält.

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.

Da sich DMXControl 3 an vielen Stellen über Tastatur Shortcuts steuern lässt - unabhängig von der Belegung im Input Assignment - sollte es ggf. in den Einstellungen eine zentrale Übersicht über die verfügbaren Shortcuts geben. Photoshop bringt unter anderem eine solche komplette Übersicht mit. Die Übersicht könnte optional nach den entsprechenden Bereichen gruppiert sein, zum Beispiel Stage View oder Cuelists.

Um während des Live-Betriebs ein unerwünschtes Verhalten der Software zu vermeiden, sollte es in dieser Übersicht einen einzigen einstellbaren Eintrag geben - nämlich die globalen Shortcuts zu aktivieren oder zu deaktivieren. Die restlichen Einträge ist festgesetzt und können vom User nicht geändert werden.

Nach  FS#3870  werden Parametermaster wohl nicht mit allen Properties funktionieren.
Um die Usability zu erhöhen würde ich mir eine Gültigkeitsprüfung der Eingaben im Device-Propertie Fenster wünschen.
Ansonsten ist für den User undurchschaubar wo ein Parametermaster funktioniert und wo nicht.
Evtl. könnte man in die Value not valid Anzeige (siehe Anhang) noch folgende Informationen ergänzen:
Supported Masters:
Parametermaster: yes/no
Speedmaster: yes/no

Beim one shoot sind oftmals so kleine Springer drinnen, z.b. bei einem Chaser mit gefannter Phase, und danach einem Reverse Chaser mit gefannter Phase, dann ist dazwischen mal kurz eine Lampe links und rechts an. Genauso bei einem Kreis Effekt da springt das MH dann mal kurz zur Mitte, während es noch nicht ganz die Bewegung abgefahren hat. Das ganze verhält sich auch bei anderen Effekten ähnlich.

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.

Aus dem Thread Scheinwerfer in der Stage View steuern ging die Frage- bzw. Problemstellung hervor: wie kann ich schnell mehrere Lampen temporär zum Einleuchten aktivieren, wenn ich nur ein Tablet zur Verfügung habe?

Hierfür ist ja bekanntermaßen die Highlight-Funktion gedacht, nur hier muss man explizit die Strg-Taste mit am Mann haben, möchte man mehrere Geräte gleichzeitig aktivieren. Daher formuliere ich hiermit den Wunsch nach einer touchoptimierten Alternative für die Highlight-Funktion. Im Idealfall klicke ich in der Stage View nach dem Aktivieren von Highlight

• einmal auf die Lampe A → sie geht an
• auf die Lampen B und C → diese beiden gehen nun auch an
• das zweite Mal auf die Lampe B → sie geht wieder aus, Lampen A und C sind weiterhin an

Hintergrund ist, dass man beim Einleuchten nicht nur immer eine Lampe für sich einzeln betrachtet, sondern je nach Anwendungsfall auch mehrere zusammen. Szenen werden hierbei ja nicht generiert. Deswegen ist dieser Wunsch nicht unbedingt im direkten Zusammenhang mit Ticket FS#4333 zu sehen.

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