Follow trigger

hi patme,

versuch mal sowas ...
Die Start Cueliste definiert die Grundeinstellung (sofort)
Dann startest du die zweite liste ...die läuft im Loop , die erste wird beendet

@hothand:
warum wait in der 2ten cuelist und nicht manual? wie wirkt sich der unterschied aus diesem fall?

wobei sich mir auch die frage stellt, was der unterschied ist zwischen start und go, wenn man eine cueliste einfügt?
...ich habe bisher nur start benutzt...

Hallo,
hier mal die Erklärung für wait, follow und manual:

• manual: Hier wird solange gewartet, bis man von Hand auf GO klickt bzw. eine andere Cue-List auf Go "klickt" und so den Cue startet
• wait: Wait und follow sind eng miteinander verwand. Bei beiden Einstellungen wird automatisch der nächste Cue ausgeführt. Der Unterschied besteht in dem Referenzzeitpunkt, ab dem die zu wartende Zeit gezählt wird. Bei "wait" ist dieser Referenzpunkt der Start des vorherigen Cues. Sobald dieser also gestartet wird, läuft ein Timer und startet den aktuellen Cue, sobald der Timer abgelaufen ist.
• follow: Follow ist wie gesagt ähnlich zu wait. Allerdings begint hier der Timer erst, wenn der vorherige Cue vollständig eingeblendet ist. So hat man also mit wait und follow die Wahl, denn je nach Anwendungsfall ist eine der beiden Möglichkeiten logischer.

Zu dem Start und Go: Da bin ich mir nicht hundertprozentig sicher, aber so viel ich weiß startest du mit "Start" eine Cuelist immer vom Anfang, auch wenn sie irgendwo in der Mitte gerade läuft. Mit Go startest du eine Cuelist nur dann, wenn sie noch nicht läuft. Ist sie schon aktiv, so ist das einfach, wie wenn du den Go-Button klicken würdest.
Viele Grüße
JP

danke
super erklärung, nun kenn ich den unterschied!

by the way: als, nicht wie

Danke @JPK
wieder etwas dazu gelernt.

@Lichtfuzzi,
Die zweite cueliste läuft im loop immer über das WAIT, was ja eigentlich nichts mehr machen soll.
Und das sollte so schnell wie möglich passieren.

Würde die erste liste gem. ihrer einstellung "end on last cue" sich selber beenden könnte man das stoppen der ersten liste,
in der zweiten weg lassen ......leider funktionierte das bei mir nicht ( 3.0.1)

Auf jeden fall bekommt man aber so genau die Variante von PATME gebaut.
Starten und dann schritte im 20s Takt.

Gruß Uwe

Hi!

Quote from patme

Nun zur Frage :
Wenn ich cue starte, läuft erstmal die Wartezeit der 1.cue ab, bevor irgendwas ausgegeben wird. Das will ich aber nicht. Ich möchte das die Wartezeit am Anfang übersprungen wird.
Wenn ich halt nochmal auf go klicke, geht es mit der nächsten cue los. Das möchte ich aber nicht.

Nochmal zum Grundverständnis: Eigentlich sollte ein doppelter Klick auf "Go" dafür sorgen, dass die "follow"-Zeit abgebrochen wird und sofort die "Fade"-Zeit gestartet wird.
Wenn also die Einstellungen so sind wie im Screenshot hier, dann sollte ein Doppelklick auf "Go" die erste Cue einblenden und nicht die Zweite:

Ansonsten muss da noch ein Bug drinstecken. Bei mir gehts. Denn genau dieser Anwendungsfall "Bitte sofort starten und nicht erst warten" in einer Loop war schonmal auch die Diskussion im Team. Ich kann damit nämlich auch nix anfangen. Wenn ich auf den Knopf drücke will ich, dass die Aktion beginnt und nicht erst warten.

Hoc

Hallo zusammen!

Ich habe mir das mal angeschaut und schließe mich der Meinung an: wenn ich eine Cuelist starte, soll sofort etwas passieren und nicht erst der Time für die Triggerung ablaufen.

Mich würde jetzt an der Stelle interessieren: ist das so gewollt? Wenn hierzu ein Anwendungsfall existiert, dann würde ich dann eine Einstellmöglichkeit vorsehen: "Ignore trigger value at cuelist start" .

Viele Grüße, Stefan von den LightningBrothers.

im theater wäre das sehr wahrscheinlich und inormationstechnisch passiert ja was. es wird gewartet
aber dein vorschlag mit dem ignorieren ist vollkommen i.o. und durchaus sinnvoll und brauchbar!

Hallo!

Ich schreibe hierzu mal einen Eintrag im Bugtracker.

Viele Grüße, Stefan von den LightningBrothers.

Edit: Der Punkt ist als Wunsch / Idee unter der Nummer FS#2478 : Cuelist startet bei Triggerung via follow / wait mit Wartezeit nicht sofort zu finden.

Hallo Leut's
ich denke das Probl. tritt erst auf wenn die Liste im Loop laufen soll.

Im Normalfall starte ich die Listen mit manual als ersten Eintrag, der natürlich mit GO bzw Start / Stop abgearbeitet wird.
Aber vereinfachen würde es schon einges.

Schick wäre auch eine Funktion die einen Wert zwischen 0-255 in eine 1/0 umwandelt, bzw einen Event auslöst , unter Angabe des Schellenwertes.
Dafür hätte ich massig Anwendungen.
Aber vieleicht bin ich auch zu SPS vorbelastet, wo man mit Funktionsketten arbeiten kann.
Oder meine SONY Sound und Video DSP's Progs... die arbeiten auch so.... alles das selbe.

Gruß Uwe

also ich stell mir das etwas "stottern" vor, vorallem mit musik...es würde den eindruck machend, als ob der letzte schritt hängen bleibt...

Hy,

Besser ist es als Workaround für eine "Loop" Cue am Ende eine leere Cue mit 20 Sekunden anzuhängen.

Diese Leere cue ist quasi die Wartezeit für die 1. Cue.

Was mich noch interessieren würde ist, dass anscheinen das "end on last cue" nicht funktioniert (hat zumindest hothand oben geschrieben). Kann das jemand reproduzieren? Bei mir geht es und daher wollte ich mal fragen wo das Problem ist.

Die Einstellung "Release at end mode" muss auf "when last cue ends" sein. Dann kann man mit "Release time" die Zeit einstellen die die cue released wird.

Sollte es wirklich nicht gehen, bitte einen Bugtracker Eintrag aufmachen.

Gruß

Arne

hi @Soon5,
alles fein hatte selbst einen Fehler gemacht.

Übrigens ... mit dem leeren Cue anhängen hinten ist garnicht schlecht, jedoch würde es die Ausgangsfrage mit "sofortigem" start und abarbeiten des 1. Cue's nicht lösen. Ich werde das noch mal umbauen, einfach interessenhalber.
Wobei ich fast alle Cuelisten mit Buttons, oder aus anderen Listen starte.

Achso... und übrigens @JPK es gibt den Befehl "Start" nicht .... ich denke das ist ein sprachliches Problem
...........

OK geht ..... 1. startet sofort und 5. setzt nur die Pause vor die 1.

@patme ... Zu: starten eines / mehrere Cuelisten aus einer anderen.....
kann ich nur sagen: überhaupt kein Problem .
Da ich diverse Cluelisten "übereinander" lege gab es nur beim stoppen einge (handling) Probleme.
Hier hat ein Button "Stoppe alle Effekte" , der mit einem klick den Stop-Event an etliche Cluelisten schickt seinen Dienst aufgenommen.
Ob diese nun wirklich laufen oder nicht ist egal.

Wenn eine Liste eine Andere startet und die nächst wieder irgendwas anhält gibt es irgendwan keinen klaren Zustand ( nicht zu erkennen !! welche CueListe Aktiv ist) Hierzu gibt es schon einen "Feature Wunsch" den "aktiven Zustand einer CueListe in einer Übersicht erkennen zu können.

Verzögerungen in den Abläufen durch dieses "gewollte" Durcheinander konnte ich nicht feststellen,
und ich habe sehr viele zeitkrittische Aktionen am Start.

Gruß Uwe

wieso das Anhängen eines leeren Cues am Ende und dafür die erste Zeit weglassen dann sollte der erste Cue sofort ausgeführt werden, und danach halt mit delay.
Gruß
Scyte

Genauso haben ich es ja gemeint.

Wie gesagt, ich habe den Request verstanden und es ist als "Feature" ja schon im Bugtracker. Aktuell kann man sich aber mit diesem Workaround behelfen.

Gruß Arne

Hallo,
wäre es da nicht evtl. geschickter, noch einen neuen Trigger vorzusehen, durch den die Art und Weise aus der 2er Serie angewendet wird. Damit gäbe es dann keine Verzögerung, bis der Trigger auslöst und der Cue wird direkt eingeblendet. Stattdessen kann man bei diesem Trigger die Verzögerung anpassen, nachdem der Cue eingefadet wurde. Dann müsste man nicht mit so einer vorgeschlagenen Hilfe arbeiten, die sich in mehreren Durchläufen inkonsistent verhält. Außerdem gibt es bestimmt weitere Szenarien, bei dem eine Haltezeit sinnvoller ist als ein Startverzögerungstrigger.
Viele Grüße
JP

Hallo Zusammen,

Haltezeiten wird es nicht geben, weil bei "Tracking" Programmierung gibt es keine Haltezeiten, weil eine Cue so lange "aktiv" ist, bis alle Kanäle überschrieben sind. Zudem sorgen Haltezeiten in Gemischten Trigger Szenarien für Verwirrung. Wir haben uns vor einiger Zeit explizit gegen Haltezeiten entschieden.

Quote from JPK

Stattdessen kann man bei diesem Trigger die Verzögerung anpassen, nachdem der Cue eingefadet wurde.

Das ist doch genau das was "follow" macht. Es definiert die Verzögerung nachdem der vorhergehende Cue eingefadet wurde.

Theoretisch lässt sich das Problem mit der "Dummy Cue" auch dadurch lösen, dass man beim Start der Cueliste 2x auf "Go" Klickt. Durch den 2. click wird der Trigger abgebrochen und der Fadein startet.

Von daher es gibt aktuell mehr als genug Lösungen und es wird immer Szenarien geben, die mit Standardmitteln nicht abgedeckt werden können. Wenn wir für jeden dieser Usecases eine Einstellung / Sonderlocke vorsehen, darf ich mir hinterher wieder Anhören wie kompliziert die Software ist, und dass keiner mehr Versteht wie die funktioniert (wie bereits geschehen).

Deshalb ist es bei neuen Funktionen wichtig zu überlegen, ist das eher ein "80% der User Problem" oder ein "0,1% der User Problem". Für letzteres wird es nie eine Implementierung geben, weil dadurch erhöhen wir unnötig die Komplexität der Software, was dann für 100% der User ein Problem ist

Wichtig ist, dass es für alle Probleme eine Lösung gibt, wenn auch manchmal mit akzeptablen Umwegen.

Gruß

Arne