• State Not Answered
  • Date
    jon weir
  • Date
  • Replies 2 replies
  • Subscribers 5 subscribers
  • Views 399 views
  • Users 0 members are here

Bug Report (1809) VM's priority

V2.2.2 b1809
1 - Hog III
1 - X-Wing
2 - DP 2000
2 - monitors
1 - Netgear Switch

Issue - I have a cue list that I am playing...I fire a VM (color bump chase) then play another cue from the list. This cue has color information in it and overrides the color chase. In this instance, I did not release the VM, it's playing in the background...just being overridden my the current cue. At this point, I start another cue list and release the first list. Again, the current state overrides the VM that is running in the background. I sit in this state for about 2 min. At this point, the VM takes control and starts outputting the color chase on stage. Nothing has changed with the console, it just sitting there.
I can understand if I went to a new cue list that had no information in it for those fixtures...in that instance the color chase should reassert and start outputting on stage. What is really getting me is the length of time before it starts outputting.
Parents
  • 0
    Yup, this is out there as bug #8401. I have added your comments to the bug.

    From the bug: "This is because of the distributed nature of
    playback; the desk has no knowledge of which playset(s) will end up onstage until the DPs actually calculate the onstage look and propagate it back to the desk in the form of feedback. Only when the desk has collected all the feedback from all DPs can it correctly determine which playset(s) are onstage and which are not. However, since this happens at some time after an onstage look has gone active, the DPs can have moved on and a new outcome determined by the time the desk has decided what to stomp. This time discrepancy can cause all sorts
    of incorrect stomping to occur. This behavior in which active playsets aren't stomped is preferable to having playsets stomped out from under us that shouldn't be. This bug will need to be addressed, but the architectural changes that need to happen in order to do stomping correctly are significant.
Reply
  • 0
    Yup, this is out there as bug #8401. I have added your comments to the bug.

    From the bug: "This is because of the distributed nature of
    playback; the desk has no knowledge of which playset(s) will end up onstage until the DPs actually calculate the onstage look and propagate it back to the desk in the form of feedback. Only when the desk has collected all the feedback from all DPs can it correctly determine which playset(s) are onstage and which are not. However, since this happens at some time after an onstage look has gone active, the DPs can have moved on and a new outcome determined by the time the desk has decided what to stomp. This time discrepancy can cause all sorts
    of incorrect stomping to occur. This behavior in which active playsets aren't stomped is preferable to having playsets stomped out from under us that shouldn't be. This bug will need to be addressed, but the architectural changes that need to happen in order to do stomping correctly are significant.
Children
No Data
Related

www.etcconnect.com