Egal ob in Version 3.3.1 oder 3.3.2 wenn man einen Colormaster über das Input Assigment fadet ruckelt der Colormasterfader und dessen Wert.
Ebenfalls spielt es keine Rolle ob man es über Executoren fadet oder direkt. Ich habe beide Versionen im Screenshot beigefügt. Wird der Colormaster ganz rechts (Colormaster 1) nicht angeschlossen, dann funktioniert der Fade smooth.
Eigentlich sollte der Colorfader smooth gefadet werden.
Zusätzlich zur aktuellen Duration Funktion sollte es eine Triggerzeit z.b. 3000 geben. Dann würden alle 3 Sekunden ein Schritt weitergeschaltet, unabhängig davon, ob die Haltzeit sowie Ein- und Ausblendzeit des vorherigen Schrittes abgelaufen ist.
(Übertrag aus Ticket FS#303 )
Ich nutze auf zwei Laptops die Art-Net 4 Ausgabe. In beiden Laptops habe ich die gleiche Art-Net-Konfiguration, um zwischen beiden Laptops teilweise oder auch vollständig wechseln zu können.
Wenn ich die Art-Net- / DMX-Ausgabe an den drei möglichen Stellen einzeln oder auch an allen drei Stellen komplett ausschalte, wird die Art-Net-Ausgabe nict komplett abgeschaltet. Dies mündet folglich in Störungen auf dem DMX-Bus, wenn ein anderer Laptop den Port des Art-Net-Nodes “übernehmen” soll. Die Lösung war hier das Treffen der Netzwerkverbindung zu den Art-Net-Nodes.
Mit der alten Art-Net-Ausgabe (in DMXControl 3.3.1) konnte ich den Wechsel noch ohne Probleme durchführen und eben auch die Art-Net-Ausgabe vollständig abschalten.
Wenn man den PortManager bei der Port Adresse verwendet, kann man das Net und Sub-Net nicht auf 0 setzen, wie das eigentlich erlaubt ist.
DMXControl 3 besitzt im Projekt Explorer die Funktion, dass Einträge auch auf die ExecutorPage gezogen werden können. Dann werden mehrere Executoren mit den passenden Inhalten angelegt. Dies funktioniert auch, wenn der Executor beim Laden des Projekts leer war. Wenn er jedoch bereits einen Member enthalten hatte, wird der Inhalt der Buttons und des Faders nicht korrekt aktualisiert. Dann werden die Standard-Elemente des MemberWrappers eingefügt und nicht die spezifischen Elemente, die durch das Hinzufügen auf die ExecutorPage vorgegeben werden.
Wenn man in den Mastern auf dem Grand Master die Buttons “Select”, “Unselect”, “Fix” und “Unxix” betätigt fliegt eine NullPointerException.
Im Masterfenster werden die Titel / Displays nur noch in Mindestbreite angezeigt und füllen nicht mehr die Breite für einen Master aus.
I’ve noticed a cuelist behaviour that seems incorrect
I have a cuelist (we’ll call this the master cuelist), and within that cuelist, I am triggering some other cuelists (we’ll call these sub-cuelists) using the ‘Go’ and ‘Stop’ special cues.
If I use the ‘Go to’ function to jump to a later point in the master cuelist after I have triggered a ‘go’ and then a ‘stop’ on a sub-cuelist, that sub-cuelist remains playing when I believe it should be stopped.
So in the attached example screenshot, if I “Go To” cue 17, I would expect the ‘Petro Alts’ and ‘Petro Zips’ cuelists to be stopped, but instead they are running.
If I play the cuelist from the start, they behave as expected.
Siehe Titel
Verwende ich beim TCP die Executoren, dann werden alle Knopfdrücker etc. einmal ausgeführt, die vor dem Marker gesetzt sind. Das Sorgt dafür, wenn man 20x nen Trigger gesetzt hat, wird auch 20x dieser ausgelöst. Was zum einen den GUI in die Knie zwingt, als auch unschön bei der DMX Ausgabe ist
Meiner Meinung nach müsste man die Executoren nicht triggern, sondern erst ab dem Zeitpunkt wo man den TCP startet