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.

Regelmäßig unregelmäßig kam es in bei mir im York vor, dass ein Tastendruck im Softdesk teilweise mit mehreren Sekunden Verzögerung umgesetzt werden. Dieses Problem kommt und geht über den Abend, ohne dass nicht explizit Änderungen am ausgeführten Projekt durchgeführt werden.

@patme hat in der heutigen Beta-Testerrunde berichtet, dass ihm dieses Problem bei einem seiner letzten Langzeit-Testläufe mit DMXControl 3.3.0 Beta 2 ebenfalls unter die Finger gekommen ist.

Um das Ticket  FS#4525  nicht nochmal komplett zu öffnen, ziehe ich den dort vermerkten Punkt 3 mit etwas abgewandelter Beschreibung nochmal auf, nachdem er mit im Kontext von  FS#4771  bewusst (wieder) aufgefallen ist:

Zwischen dem ersten und zweiten Gerät in der Device Group nicht nahtlos statt findet der Wechsel bzw. die Umschaltung zwischen dem. Hier gibt es einen kurzen Augenblick, bei dem das Gerät 1 bereits aus aber das Gerät 2 noch nicht an ist und so ein Blitz entsteht. Dieser Punkt ist gut in dem beigefügten Projekt sowohl in der Stage View als auch auf meinen LED-Bars in Realität zu sehen. Ich habe hier

• einen Custom Chaser mit nur zwei Schritten, wo das Group Handling auf 2 gesetzt ist sowie
• einen einfachen Chaser mit Playmode Normal, jedoch mit einem “hohen” Wert für das Group Handling

in der Cuelist gespeichert.

In der Summe ist das Phänomen mit (allen) anderen Playmodes reproduzierbar und fällt zunehmend stärker auf, umso größer der Wert für das Group Handling ist.

Für einen Test baute ich kürzlich zusätzlich zum Main-PC noch einen zweiten Backup-PC auf, wovon nur einer der beiden PCs die DMX-Daten über Art-Net ausgeben sollte. Gerade bei Art-Net gibt es ja bekanntermaßen murks, wenn zwei PCs das gleiche Gerät ansprechen wollen.

Wenn alles geregelt läuft, kann ich vor einem Neustart zum Beispiel die Art-Net-Ausgabe deaktivieren. Liegt aber nun ein Fehler vor, wodurch ich das Deaktivieren nicht mehr entsprechend anstoßen kann, sind die DMX-Interfaces wie zuletzt gespeichert beim erneuten Starten des Kernels nur kurze Zeit wieder aktiviert und die Ausgabe wird auf 0 gesetzt - egal ob ein Projekt geladen wurde oder nicht. Dies war im konkreten Fall insofern problematisch, weil das Projekt beim Starten von DMXControl 3 als “Default Project” direkt mit geladen wird und ich während des Ladevorgangs keinen Zugriff auf die DMX-Ausgabe habe. Damit mir nun mein Main-PC nicht in die Suppe spuckt und nichts ausgegeben wird, blieb mir nichts anderes übrig, als im Interface-Rack die Art-Net-Interfaces händisch temporär direkt auf den Backup-PC umzuklemmen.

Um nun im Falle eines unvorhergesehen Neustarts (insbesondere mit einem Default Project, was effektiv gesehen das “Arbeitsprojekt” / “Showprojekt” ist) nicht Hand an der Verdrahtung der Hardware anlegen zu müssen, würde ich mir hier eine Möglichkeit wünschen, dass ich im Idealfall selbst den Zeitpunkt festlegen kann, wann die DMX-Ausgabe auf die Interfaces bzw. die Interfaces selbst aktiviert werden - und zwar unabhängig davon, was in den Einstellungen für die DMX-Ausgabe grundsätzlich gespeichert ist.

* beliebige Cuelist aufrufen
* beliebige Fadezeit anklicken

Die Fadezeit hat nun den Focus, ist lila hinterlegt.

* Nun den Wert ändern wollen, und mit der Tastatur einfach “2000” eingeben

Erwartete Funktion:
* 2000 steht im Eingabefeld drin

Tatsächliche Funktion:
* 000 wird ins Feld eingetragen, der erste Tastendruck also verschluckt

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.

Wir brauchen eine Message Box Advanced.

Neben den üblichen Funktionen der bekannten Message Box (Header, Text, Mehrere Buttons (OK, OK-Cancel, OK-Retry-Cancel, Yes-No, Yes-No-Cancel,….)) sowie Icon stelle ich mir folgendes vor:

1. Auswahl zwischen 1-3 Buttons, sowie beliebige Beschriftung der Buttons
2. Optional Anzeige eines Icons für die MessageBox
3. Optional Anzeige eines kleinen Icons pro Button
4. Definition eines Default Buttons, der beim direkten drücken auf “Enter” gewählt wird. Per Default ist es Button 1
5. Optional Angabe eines Timeouts, welcher den Default Button nach Ablauf von X Sekunden drückt (Text des Buttons = “Button Text (<countdown>)”). Im Button läuft also die Zahl runter, bei 0 wird gedrückt.
6. Optional Anzeige eines “Don’t show Again” Checkbox Elementes
7. ESC Taste schließt die Message Box.

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.

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

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.

Nachdem auf meinem PC der Bildschirmschoner ansprang, hat die GUI das Logfils mit der folgenden Fehlermeldung geflutet, sodass die Datei am Ende auf über 143 MB angewachsen ist.

2019-11-23 15:17:17,144 [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 470.

2019-11-23 15:17:17,158
2019-11-23 15:17:17,171
2019-11-23 15:17:17,185
...
2019-11-23 15:50:20,200
2019-11-23 15:50:20,222
2019-11-23 15:50:20,245

Durch die Größe des Logfiles hat möglicherweise auch dazu geführt, dass die GUI von Windows geschlossen wurde.

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.

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.

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.

Eine per Timecode gesteuerte Cuelist zu erstellen erfordert momentan eine hohe Konzentration.

Stand jetzt:

• Im Dropdown der Triggerauswahl öffnet erst der dritte Einzel/Doppelklick die Auswahlliste. Der erste scheint auszuwählen, der zweite lässt den Rahmen links vom Pfeil verschwinden.
• man kann nicht mehrere Cues auf einmal auf den Trigger Timecode umstellen
• man kann nicht für mehrere Cues auf einmal die Trigger Value einstellen.
• ich war nicht in der Lage über die ApplicationSettings einen Default-Trigger einzustellen. Auch die Option “Trigger: Last Set” hat bei mir keine sofortige Auswirkung.
• ein neuer Cue bekommt immer den Timecode 00:01:00.00
• Das Format für die Eingabe muss immer im Format hh:mm:ss oder hh:mm:ss.ff erfolgen. Dass es 25fps sind, habe ich weder im Tooltip noch im Tutorial gefunden.
• Der erste Doppelklick auf die Zelle wird wie Einfachklick behandelt, erst der zweite Doppelklick öffnet die Eingabe
• Zumindest mit meiner Timecode-App (NET-Timecode per UDP, Auflösung 50ms) werden von mehreren Cues in einer Cueliste mit gleichem Timecode nur die erste abgespielt. Der gleiche Timecode in mehreren parallelen Cuelisten funktioniert.
• Man kann nicht im Timecode springen. Ist der Wert einmal über die Trigger Value der Cue hinaus nützt auch ein springen an den Anfang des Timecodes nichts. Der Cue wird nicht ausgelöst. (Keine doppelte Auslösung könnte ich nachvollziehen)

Gewünschtes Eingabeszenario (zur Diskussion):

• Mehrere ausgewählte Cues lassen sich gemeinsam bearbeiten (Trigger, Trigger Value)
• Man kann einen Default Trigger festlegen mit Default Trigger Value
• Die Eingabe ist flexibel: einzelne Ganzzahl wird immer als Sekunden interpretiert und in das Format hh:ss:mm umgewandelt (analog zu Trigger Wait, auch >59). Daneben ist zulässig:

   mm:ss
hh:mm:ss
  15m32s
        .z
        .zz
        .zzz
      ss.z[zz] (auch >59)
   mm:ss.z[zz]
hh:mm:ss.z[zz]

• Ich arbeite lieber mit Millisekunden, weil dann 5.2 gleich 5.20. Bei DMX reichen wahrscheinlich auch Hundertstel als Auflösung, aber wer weiß, was wir demnächst noch alles mit DMXC3 steuern können Vielleicht ist es möglich, wahlweise auch eine Eingabe mit 25/30 Frames zu erlauben. Dann ist .z und ss.z natürlich nicht mehr zulässig oder muss als s.0z interpretiert werden.
• 0 oder 00:00 ist zulässiger Wert
• Man kann per Click/Taste/Enter bei leerer Value den aktuell /zuletzt empfangenen Timecode Übernehmen (FS#783 )
• Ein Doppelklick auf die Zelle Trigger Value startet den Eingabemodus
• Parallel startende Cues sind in der gleichen Cueliste möglich. Insbesondere um mehrere Effekte/Cuelisten parallel zu starten.

Das wären meine Vorstellungen, Kritik und Ideen sind gern gesehen. Wenn es hilft, trennt das ruhig in mehrere Bugreports auf.

Beste Grüße,
der Lichtheini

(Version 3.1.1.21 auf Win7x64)

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.

I have a simple preset (dimmer and colour values for LED Pars), and this preset is used in a number of cues. When I ‘Edit in programmer’ the preset, change the colour values and then ‘Update’ the preset, the next time I go to play the cuelist the cues won’t play and a series of error reports appear in the kernel output. I’m also unable to save the project after this.

I can’t see a way to attach a log file to this report, but here’s a Dropbox link to the log zip file: https://www.dropbox.com/s/i6we4ho0szycprv/DMXControl3Logs_2022430_213811.zip?dl=0

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.

Ich möchte in einer Cuelist mit mehreren Cues eine der Cues einige Positionen nach oben oder nach unten verschieben. Dies ist aber mit den Up- / Down-Buttons nur bedingt möglich. Ich kann aktuell eine Cue immer nur eine Position nach oben oder nach unten verschieben. Mehrfaches betätigen der Buttons funktioniert an dieser Stelle nicht.

Der aktuelle Workaround besteht darin, dass ich gewissermaßen “invertiert” verschiebe. Konkret heißt das für den Fall, wo ich die Cue 1 zum Beispiel von Position 1 auf Position 5 verschieben möchte, dass ich die Cues 2 bis 5 markierte und eine Position nach oben verschiebe.

Zur Reproduktion kann ein beliebiges Projekt verwendet werden, das eine Cuelist mit mehreren Cues enthält.

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

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.

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

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.

Nachdem ich ein Projekt geschlossen habe, stand plötzlich folgende Meldung im Kernel:

18:55:59 FATAL DMXControl 3 Kernel - Unhandled Exception: Der Wert darf nicht NULL sein.
Parametername: projectID
System.ArgumentNullException: Der Wert darf nicht NULL sein.
Parametername: projectID
   bei org.dmxc.lumos.Kernel.Project.SceneListManager.GetSceneListGroupByID(String sceneListGroupID, String projectID) in D:\Jenkins\workspace\Lumos_Pipeline_3.3\Lumos\src\Kernel\Project\SceneListManager.cs:Zeile 396.
   bei org.dmxc.lumos.Kernel.Project.SceneListManager.GetSceneListGroupByID(String sceneListGroupID) in D:\Jenkins\workspace\Lumos_Pipeline_3.3\Lumos\src\Kernel\Project\SceneListManager.cs:Zeile 381.
   bei org.dmxc.lumos.Kernel.Net.gService.Parameter.ScenelistGroupParameterLookup.Find(String id) in D:\Jenkins\workspace\Lumos_Pipeline_3.3\Lumos\src\Kernel\Net\gService\Parameter\ScenelistGroupParameterLookup.cs:Zeile 11.
   bei org.dmxc.lumos.Kernel.Net.gService.Parameter.AbstractIParameterableLookup`1.<ParametersAsync>d__2.MoveNext() in D:\Jenkins\workspace\Lumos_Pipeline_3.3\Lumos\src\Kernel\Net\gService\Parameter\AbstractIParameterableLookup.cs:Zeile 17.
--- Ende der Stapelüberwachung vom vorhergehenden Ort, an dem die Ausnahme ausgelöst wurde ---
   bei System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
   bei System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   bei System.Runtime.CompilerServices.TaskAwaiter`1.GetResult()
   bei org.dmxc.lumos.Kernel.Net.gService.Parameter_gService.<_parameters_RequestReceived>d__13.MoveNext() in D:\Jenkins\workspace\Lumos_Pipeline_3.3\Lumos\src\Kernel\Net\gService\Parameter\Parameter_gService.cs:Zeile 118.
--- Ende der Stapelüberwachung vom vorhergehenden Ort, an dem die Ausnahme ausgelöst wurde ---
   bei System.Runtime.CompilerServices.AsyncMethodBuilderCore.<>c.<ThrowAsync>b__6_1(Object state)
   bei System.Threading.QueueUserWorkItemCallback.WaitCallback_Context(Object state)
   bei System.Threading.ExecutionContext.RunInternal(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx)
   bei System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx)
   bei System.Threading.QueueUserWorkItemCallback.System.Threading.IThreadPoolWorkItem.ExecuteWorkItem()
   bei System.Threading.ThreadPoolWorkQueue.Dispatch()
   bei System.Threading._ThreadPoolWaitCallback.PerformWaitCallback()
An unhandeled Exception has occoured. DMXControl 3 Kernel has to be terminated. Press Enter to exit.

Trotz dieser Meldung konnte ich aber ein anderes Projekt laden, dieses wieder schließen und dann das Projekt laden, was ich als erstes bearbeitet hatte. Sprich der Kernel ist nicht abgestürzt. Bewusst war mir diese Fehlermeldung aber noch nicht unter die Finger gekommen.

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

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

Das Presetfenster soll ähnlich zum Effektfenster:

• Icons (mit vorbereiteten Bildern, oder freihandzeichnen)
• Sortieren nach Geräteeigenschaften, oder Gerätegruppen etc.
• Favoriten für Presets anlegen
• Vorschau der Presets bei Mouseover etc.

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

Zu der Frage ob das Masterfenster beibehalten werden soll oder nicht, wurde im QRM-Meeting vom 15.05.2021 folgendes verabredet:

• Das Masterfenster bleibt als separates Fenster erhalten und ist auf dem bekannten Weg erreichbar.
• Die Master werden auf Basis der neuen Executor-Controls automatisch in dem Masterfenster und alle horizontal nebeneinander anlegt.
• Das Masterfenster erhält verschiedene Filter, um die Master nur anhand ihres Typs oder / und anhand von bestimmten Werten anzuzeigen.
• Die Anzeige der Group Master orientiert sich weiterhin an den Einstellungen der jeweiligen Device Groups, ob ein Group Master angezeigt werden soll oder nicht.
• Die Belegung der Buttons etc. ist nicht konfigurierbar und basiert auf Basis der Standardeinstellungen, mit denen ein Master auch einem Executor zugeordnet wird.
• Aus den verschiedenen Master-Ordnern kann man das Masterfenster direkt mit einem gesetzten Filter öffnen, um zum Beispiel nur die Group Master oder nur die Parametermaster anzuzeigen.

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.

Im gesamten Programm werden Farben mit “;” dargestellt: 0;0;0
Im softdesk werden Sie mit “,” dargestellt: 0,0,0

Beim Duplizieren einer Cuelist, bei der Tracking deaktiviert ist, wird diese Einstellung nicht in die zweite Cuelist übernommen. Der Haken ist zwar nicht gesetzt, aber trotzdem reagiert die Cuelist wie eine mit aktivem Tracking (siehe Diskussion Arne ⇔ JP)