Bugtracker DMXControl 3

  • Status Unbestätigt
  • Percent Complete
    0%
  • Task Type Fehlerbericht
  • Category GUI & Server
  • Assigned To No-one
  • Operating System All
  • Severity Low
  • Priority Very Low
  • Reported Version 3.3 Alpha x
  • Due in Version Undecided
  • Due Date Undecided
  • Votes
  • Private
Attached to Project: DMXControl 3
Opened by LightningBrothers - 15.11.2021
Last edited by LightningBrothers - 26.11.2021

FS#4657 - Tracking ignoriert "Back"-Button vom Executor

Ich habe mir eine Cuelist mit fünf Cues gebaut, wobei das Tracking standardmäßig aktiv ist:

  1. Cue 1 - blue > red
  2. Cue 2 - static white
  3. Cue 3 - green > blue
  4. Cue 4 - static red
  5. Cue 5 - static violett

Mit dieser Cuelist führe ich folgende Schritte aus:

  • Ich lasse die manuell via Go getriggert per Executor bis zur 5. Cue durchlaufen.
  • Ich drücke mehrfach den Pause- / Back-Button. Die Anzeige unter “Current cue” springt ab dem zweiten Klick mit jedem weiteren Klick Cue für Cue zurück - und zwar in der Reihenfolge, wie die Cues in der zugeordneten Cuelist angeordnet sind. Den Button drücke ich so lange, bis unter “Current cue” die “Cue 2” aufgeführt wird. Die Zeile ist grau hinterlegt.
  • Ich klicken auf Go. Der blaue Balken beginnt, sich von links aus aufzubauen. Das gleiche Verhalten zeigt die Cuelist selbst auch.

Mit dem Klick auf Go führt die Cuelist aber nicht wie vom Executor suggeriert die “Cue 2” aus, sondern die der “Cue 5” vorhergehende “Cue 4”. Erst wenn ich das Tracking deaktiviere wird auch die “Cue 2” tatsächlich ausgegeben.

An dieser Stelle sollte ich aus meiner Sicht die Cuelist nicht anders verhalten, als wenn ich die “Cue 2” in der Cuelist selbst manuell per “Load” vorauswähle und dann mit dem Klick auf Go (egal ob Cuelist oder per Executor) aufrufe. Sprich: in beiden Fällen (egal ob Tracking aktiv oder nicht) sollte die “Cue 2” ausgeführt werden, so wie es mir auch in der Anzeige im Executor oder in den Progress-Balken der Cuelist suggeriert wird.

Um das unterschiedliche Verhalten darzustellen, enthält das beigefügte Projekt die Cuelist zwei Mal - einmal mit aktiven und einmal mit deaktiviertem Tracking. Beide Cuuelists sind direkt per Executor aufrufbar, wenn das letzte Fensterlayout geladen wird.

Project Manager
Soon5 commented on 24.11.2021 22:52

Also wenn ich das richtig lese, ist das Verhalten der Cueliste erstmal i.O, nur die visuelle Darstellung im Executor stimmt nicht. Korrekt?

LightningBrothers commented on 25.11.2021 17:55

Wenn ich "Go back" direkt über die Cuelist ausführe, arbeitet alles wie erwartet. Die Cues werden von unten nach oben ausgegeben.

Es ist ein Kommunikationsproblem zwischen Executor und Cuelist in Verbindung mit dem Tracking. Führe ich die oben beschriebenen Schritte in der Cuelist "Tracking on" aus, gehe aber per "Pause / Back" nicht bis zur Cue 2 sondern bis zur Cue 1 zurück, sehe ich

  • beim ersten Klick auf Go die Cue 4 (hier sollte eben eigentlich die Cue 1 wiedergegeben werden)
  • beim zweiten Klick auf Go die Cue 2

Bei der Cuelist "Tracking off" wird

  • direkt beim ersten Klick auf Go die Cue 1 wie erwartet ausgegeben

Ich denke, das Phänomen ist wie gesagt am besten mit dem Beispielprojekt nachzuvollziehen. Ich hatte jetzt keine Lust (mehr) ein Video zu drehen - was mir vielleicht rückblickend doch einiges an Text gespart hätte. :-D Aber ich kann ja meine Meinung noch ändern. ;-)

Project Manager
Qasi commented on 25.11.2021 23:54

Ich weis immernoch nicht was nicht geht.
Im Kernel ist absolut kein unterschied, von wo das GoBack getriggert wird, den es ist immer ein und die selbe methode

LightningBrothers commented on 26.11.2021 20:15

So… Ich habe mal mit dem bereits oben beigefügten Beispielprojekt nun doch noch ein Video gedreht.

Loading...

Available keyboard shortcuts

Tasklist

Task Details

Task Editing