Bugtracker DMXControl 3

  • Status geschlossen
  • Prozent erledigt
    100%
  • Aufgabentyp Fehlerbericht
  • Kategorie GUI & Server
  • zuständig niemand
  • Betriebssystem All
  • Schweregrad niedrig
  • betrifft Version 3.3 Alpha x
  • fällig in Version unbestimmt
  • fällig am unbestimmt
  • Stimmen
  • versteckt
gehört zu Projekt: DMXControl 3
angelegt von LightningBrothers - 15.11.2021
zuletzt bearbeitet von Qasi - 22.01.2022

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.

geschlossen von  Qasi
22.01.2022 00:21
Grund für das Schließen:  Doppelt
Kommentar zum Schließen:  

 FS#3605 

Project Manager
Soon5 schrieb am 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 schrieb am 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 schrieb am 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 schrieb am 26.11.2021 20:15

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

Project Manager
Qasi schrieb am 01.01.2022 20:11

Warum wurde das wieder geöffnet?

Admin
JPK schrieb am 01.01.2022 21:04

Ich hatte mich verklickt und das falsche Ticket geschlossen. Das Ticket hier ist valide. Das geschlossene Ticket ist  FS#4669 

Project Manager
Qasi schrieb am 22.01.2022 00:15

häääääääää ich verstehs nicht!

Project Manager
Qasi schrieb am 22.01.2022 00:21

Bullshit, das ist  FS#3605 .
Der Progress voren wird falsch angezeigt

Beni200 schrieb am 21.01.2023 15:42

Ich habe das gerade mal geteset und genau so gemacht wie Stephan, bei mir passiert aber in der Beta 6 noch das gleiche wie bei Stephan, ist also nicht repariert, oder?

Lade...

verfügbare Tastenkürzel

Aufgabenliste

Aufgabendetails

Aufgabenbearbeitung