Planung und Aufbau vom Softdesk, Input Assignment, Cues und Cuelist

Und weiter geht's.

Quote from Maxiking1994

Dieses Verhalten benötige ich genau ein Mal, wenn ich die Dimmer Cue Starte. Danach hätte ich gerne eine Fadetime.

Ganz ehrlich? Bitte nicht böse verstehen: wofür? Ich sehe da keinen Sinn drin, beim ersten Start einer Farbe hier einen Unterschied und dir damit das Leben unterschiedlich schwer zu machen. Wieso möchtest du dies beim erstmaligen und auch einzigen Start explizit anders haben? Zumal: wann genau soll alles einmal sofort ohne faden geschehen? Vielleicht magst du mir deine Idee dahinter (nochmal) erklären.

Ich kann nachvollziehen, dass du nach dem Öffnen des Projekts keine Farbe auf den Geräten haben möchtest und dies mittels einer Grund-Cuelist erschlägst. Zu diesem Zeitpunkt ist der Dimmer der Geräte noch aus, sodass du von dem Umschalten so erst einmal gar nichts mitbekommst. Darüber hinaus passiert dies ja auch noch vor dem Einlass zur Show oder vor Beginn der Aufzeichnung. Wenn es los geht, hast du entweder einer alternative Lichtstimmung vorbereitet (die dann auch zu sehen ist) oder du startest einen passenden Effekt mit dem Song - aber dies läuft doch dann bereits mit dem Fade und diese bewegen sich doch alle im Bereich von maximal 10 Sekunden, oder liege ich da falsch?

Quote from Maxiking1994

Um eine Aditive Farbmischung für RGB scheinwerfer zu erstellen, geht man am besten hin und erstellt eine Cue, die die Farben im RGB-Farbmodell ohne Fadetime auf Schwarz stellt. Diese Cuelist enthält nur diese eine Cue.

Da sind wir bei dem Punkt von eben: das kann ja (sofern es hier eine entsprechende Unterstützung gäbe) in der Grund-Cuelist gespeichert sein, welche du einmal unmittelbar nach dem Laden des Projekts startest. Da kommt es ja nicht darauf an, ob diese eingefaded wird oder nicht.

Was ich aber schon einmal einwerfen kann: auch die Fadezeiten in den Cuelists lässt sich insgesamt skalieren. Dafür ist der Fade Factor.

Quote from Maxiking1994

In der Cuelistgroup für Farben bekommt diese Cuelist dann die niedrigste Priorität, so, das alle Cues mit Farben diese Überschreiben.

Was ich auch beim Lesen deiner ersten Beiträge in diesem Thread nochmal mitbekommen habe: die Cuelist mit der höheren Priorität (zum Beispiel 23) überschreibt die mit einer zahlenmäßig niedrigeren Priorität (zum Beispiel 2).

Hallo Max!

Ich würde es mit einer Cuelist pro Gerät und einem Group Master lösen.

Lege dir für die Frontbeleuchtung eine Device Group an. Die Fader für Limiter und Master verrechnest du mit einem Math-Node und gibst den Ausgangswert an den Group Master. Für die vier "Relativfader" legst du je eine Cuelist mit einem Cue an, wo der PAR entsprechend auf 100% gesetzt ist. Ggf. sprichst du die Geräte ebenfalls über Device Groups an, solltest du mal spontan mehr als ein PAR gleichzeitig ansprechen sollen.

Die Fader für den relative Abweichung verknüpfst du mit der Intensität der jeweiligen Cuelist. Aber - und das ist nun der Trick - du übergibst nicht den Wertebereich 0 bis 1, sondern zum Beispiel 0 bis 5 (maximal 10). Auf diese Weise kannst du den PAR trotzdem "heller als 100%" machen. Bekanntermaßen verrechnet DMXControl 3 ja die Helligkeit der Cuelist mit allen Group Mastern, in denen ein Gerät enthalten ist. Wenn du also aus der Cuelist 250% Helligkeit rausgibst, kannst den zugehörigen PAR trotzdem heller machen, wenn du den Group Master heruntergezogen hast.

Ich hoffe, du kannst meinen Ausführungen folgen.

Um deine Frage zu beantworten: in der aktuellen Version kann man bei numerischen Werten, die nur positive Werte erlauben, keine negativen relativen Werte nutzen. Diesen Punkt haben wir grundsätzlich aber auf dem Schirm, dass es bestimmte Konstellationen gibt, wo so etwas erforderlich ist. Ob man deinen beschriebenen Anwendungsfall so auch dazu zählen kann, würde ich im ersten Schritt eher verneinen.

Stefan

Quote from Maxiking1994

In deiner Beschreibung, wenn ich es richtig verstehe, kann ich nicht die Helligkeit reduzieren für eine einzelne Gruppe, nur erhöhen - gegenüber dem Master.

Wenn du den Fader für die einzelne Gruppe auf 0 ziehst, dann ist der zugeordnete PAR auch aus, sofern du den ganzen Wertebereich zulässt. Du kannst der Intensität aber eben auch nur einen Wertebereich von 0,5 bis 1,5 übergeben, wodurch du die Helligkeit eben um +/-50% variieren kannst.

Quote from Maxiking1994

[...] mit negativen relativen Werten könnte ich eine Komplexes Input Assignment mir ersparen

Ich habe die Connectionsets jetzt nicht nachgebaut, aber wenn ich das im Kopf richtig überblicke, fallen diese genauso einfach aus und sind auch von der Anzahl her nicht mehr wie in deiner Lösung:

• Ein Connectionset, um den Limiter-Fader mit dem Master-Fader mittels einem Math-Node zu verrechnen und den Wert an den Groupmaster zu übergeben.
• Ein Connectionset, um die Cuelists für das Frontlicht zu starten und zu stoppen. Hier kannst du dir aber ggf. auch eine Cuelist Group erstellen und den Button mit dem Cuelist Group Node verbinden, worüber sich alle zugeordneten Cuelists gleichzeitig starten und stoppen lassen. Alternativ wählst du in den Cuelist Group Einstellungen für das Starten und Beenden die Einstellung, dass eine Cuelist alle anderen in der Gruppe startet bzw. stoppt.
• Je ein Connectionset, um den Relativfader über einen Rule of Three mit der Intensität der Cuelist zu verknüpfen.

So. Nachdem ich über deine doch komplexe Lösung ein wenig erstaunt war, wollte ich es nun nochmal wissen und habe in dem beigefügten Projekt mal genau das umgesetzt, was ich oben beschrieben habe:

• 1 Connectionset für Limiter und Master, wo die Faderwerte miteinander verrechnet und an den Groupmaster übergeben werden
• Je ein Connectionset für die Helligkeitskorrektur über die Cuelist-Intensity inklusive Button zum Zurücksetzen auf 0
• 1 Connectionset zum gemeinsamen Starten und Stoppen der Cuelists für das Frontlicht

Schaue mal rein, ob du dies so nachvollziehen kannst und insbesondere ob ich nun das so umgesetzt habe, was du erfragt hast.

Quote from Maxiking1994

Der Limiter soll den Maximal möglichen Wert begrenzen.

Okay. Da ist dann in der Tat eine etwas andere Verschaltung erforderlich, um den Wertebereich oberhalb des eingestellten Wert für den Limiter zu kappen.

Mit meinem Konzept spiegele ich die Arbeitsweise von DMXControl 3 wieder, wenn in den Geräteeinstellungen den Wert für den Limiter setzt. Hier ist es nämlich ebenfalls so, dass der Wertebereich für Intensity herunterskaliert wird und so keine toten Zeiten beim Ein- und Ausfaden gibt. Die Zeiten verteilen sich eben auf einen anderen Wertebereich.

Wichtig ist, dass du im Softdesk für den Slider den Pass-Through-Modus aktivierst. Das kannst du auch gut sehen: ist der Pass-Through-Modus deaktviert, springt der Slider nur zum Zeitpunkt des Drückens des Buttons zurück, während der Slider im anderen Fall den durch den Input Selector gesetzten Wert beibehält.

Dein beschriebenen Verhalten kann ich so mit meinem Beispielprojekt nicht nachvollziehen, da der Input Selector dem Slider explizit den Wert 0 übergibt und der Slider diesen dann auch annimmt.

Alles gut. Bei so vielen Punkten lässt sich so etwas nicht vermeiden und ich hätte ja auch explizit darauf hinweisen können, dass ich auch eine Einstellung gezielt im Softdesk gesetzt habe.

Aber schön, dass nun alles funktioniert.

Hallo Maxiking,

ich habe mich jetzt auch nochmal deinen Wünschen im Projekt angenommen. Dazu habe ich das Projekt im Anhang gebaut.

Kuck dir einfach selbst an, was ich gemacht hab, aufkommende Fragen beantworte ich gerne!

"Unscheinbar" sind folgende Veränderungen:

• Cuelist Group "Cuelist Start behaviour: Master/any starts all"

• Cuelist Group "Cuelist Stop behaviour: Master/any stops all"

-> dadurch kann ich mit einer Cuelist alle Anderen (in der Gruppe) starten/stoppen/Status

• Softdesk Relativ Slider: PassThrough "True", Min "-1", Max "1"
• Reset Buttons: Min " ", Max "0"

-> dadurch können die Slider auf 0 zurückgesetzt werden, werden aber nicht die ganze Zeit angesprochen

Viele Grüße

Johannes

Es kann sein, dass JohannesStroe in seinem Beispielprojekt nicht die Intensität der Cuelist insgesamt manipuliert, sondern direkt den Wert für den Dimmer mit Hilfe des Parametermasters. So findet die Berechnung komplett im Input Assignment statt. Von daher schaue einmal in eine der Cues. Grundsätzlich lässt sich das Konzept auch auf den Weg über die Cuelist-Intensität oder über Group Master anwenden, sogar ohne dass du Werte verändern musst.

Quote from Maxiking1994

Dieses verhalten konnte ich mit dem LTP-Node ändern. Haben die Nodes öffters Probleme mit mehreren Eingängen?

Genau aus diesem Grund kam der LTP-Node in DMXControl 3.2.2 hinzu, weil gleichzeitige Werteänderungen auf der Eingangseite eines Nodes nicht richtig verarbeitet werden können. Ein typisches Beispiel ist Änderung von Text und Farbe eines Buttons im Softdesk. Hier half in der Vergangenheit das Delay-Node weiter, mit dessen Hilfe sichergestellt wurde, dass ein zeitlicher Versatz zwischen den ankommenden Informationen liegt.

Der wesentliche Vorteil an Parametermastern ist, dass du hier auch durch die Verwendung von mehreren Parametermastern den Wert für eine Funktion fannen kannst. Das sieht dann zum Beispiel so aus: {ParameterMaster 1} <> {ParameterMaster 2}. Ein weiterer Punkt ist, dass sich Parametermaster bei zahlreichen anderen Funktionen und eben auch bei Parametern von Effekten nutzen lassen.

Somit trifft die ursprüngliche Aussage auch weiterhin zu. Die Parametermaster übergeben einen Wert, den die Cue nach dem Starten und Stoppen der zugehörigen Cuelist verarbeiten und ausgeben. Der Unterschied ist hier nur, dass du die Werte über die Parametermaster zur Laufzeit manipulieren kannst.