Hooking a callback into the "ActiveState" of an exec / sequ

BECOME PART OF THE COMMUNITY - Sign up here
  • Hello everyone,

    there is this handy-dandy HookObjectChange() function which allows us to hook into changes of an object as long as "public" attributes like name or e.g. assignments on an exec page are changing. There is also a function that lets us retrieve the "ActiveState" of a sequ called HasActivePlayback(). As it's a function and not an attribute on the sequ I can't hook into it which results in a soution which regularly calles the function to get the state. This is obviously very inefficient, slow and impractical for getting state from a larger ammount of sequences. Is there another place to hook into to get realtime updates on the sequences "ActiveState"?

    Kind regards 🙌

    lukas-runge

  • lukas-runge August 6, 2022 at 2:40 PM

    Changed the title of the thread from “Hooking a callback into the "ActiveState" of an executor” to “Hooking a callback into the "ActiveState" of an exec / sequ”.
  • Hi Lukas,

    to my knowledge:

    as you mention, HookObjectChange will trigger by changes to objects and its properties.

    Playback does not make any "change" to the object.

    Here's another approach, without using constant polling:

  • Hi Andreas,

    what a wonderful solution considering execution time overhead. Thank you Andreas! 🥳 Unfortunately, the solution prevents the user from using CueZero and OffCue commands for other purposes without further checks when adding the notify commands, which could be one way of improving upon this solution. Meanwhile I also found a solution that works without needing to modify any objects in the showfile and still works without pollig:

    Since I'm using the hook on Root().Temp.RunningSequences, this only works while the Running Sequences window is open on any of the MA3 screens, otherwise the hook won't fire on status changes. Unfortunately, there is no argument passed to the callback function to know directly what or where the change is without reiterating over all the sequences. This makes this solution more inefficient than it could be, since the execution time grows proportionally to the number of sequences. But at least the sequences are only checked if at least one state change has occurred. So at least for small showfiles you can get a latency and overhead advantage over polling. In addition, the overhead can be reduced further if one is no longer interested in the state of all sequences but only a selection. Then you can only check the relevant sequences to begin with, which extremely reduces overhead.

    Since all previous solutions that are better than polling bring restrictions for the user (using CueZero or OffCue, using windows that have to be open at all times, etc.) I sadly have to understand these solutions more as a workaround than as a serious solution that can be used sensibly.

    In hope of better solutions

    Kind regards 🙌

    lukas-runge

Participate now!

Don’t have an account yet? Register yourself now and be a part of our community!