Non-Sequential playback?

I'm running a show in a few weeks on an ion (v 2.9) where every once and a while a poll is opened and the audience votes on what the characters should do next, kind of like a choose your own adventure book. Of course, that means that we can't just record a cue list and press go. Has anyone had to run something like this before?

Over the past week I have been prototyping a control system which uses macros to enable and disable subs bound to macros that fire go to cue commands, but macros don't appear to be super reliable (or maybe I'm just using them wrong). Surely there is a better way to do what I want to do?

Any advice appreciated!

Cheers!

Ben

Parents
  • This is a fun exercise!

    There probably isn't a "best" way to do this, and the choice I would make heavily depends on the details of how you or your operator will be interacting in show conditions.

    Assuming the following:

        - All choices and sub-choices are scripted (truly in the "choose your adventure" storybook style

        - The operator will manually interact with the console to input the audience choice

    I would look at doing the navigation portion in snapshots with Custom Direct Selects.

    Each "poll the audience" cue could execute a snapshot to pull up the appropriate Custom DS Layout, and each possible choice would either execute another Snapshot to reveal the next level of choices or execute a macro to execute your desired Sub or Cue.  If you get creative with things you can set up a complete UI mapping system this way.

    This gives you a good way to filter information a have a consistent means of executing the transitions every time.

    Depending on your needs either Cue Lists or Subs work for the content, depending on whether you need branching trees or accents/effects for any given interaction.  Both is always an option!

  • I really like this. Probably because it's quite similar to my prototype.

    Instead of having direct selects, I'm abusing the fact that on the ion faders can have either a green or red light (additive or inhibitive). By default I have ten subs (ten choices) all in inhibitive mode and their buttons unbound

    When a choice cue is loaded, it executes one of 10 macros that will activate that many subs, put them into additive mode and bind their buttons to another macro that will make the jump to whatever choice the audience makes.

    Ill probably change this to just a plane copy so that it's easier to program as this show will be run in a different venue on a different board (still an ion luckily).

    For the actual 'jumping', the macros are goto cue commands, the first choice is one cue ahead (one press of [Next], 2 is +2cues ([Next] [Next]), etc.

    The goto's load what I'm calling 'response' cues. Each one has a link to a separate cue list, or a different segment in the same list. they have a follow time as 0 and have the same look as the choice cue. I can get away with this because somewhere on the forums the other day I saw if you append [Time] to a goto command it uses the time of cue its jumping to, and triggers follows.

    Once a choice button is pressed, the subs are disabled again.

    The benefit to this is, because the macros are just pressing [Next] a variable amount of times, it is applicable to all my choices, so long as the choices are all programmed the same.

    Is it over-engineered? absolutely. Is it abusing colourful lights on the ion? Yep. Is it obvious to the op how many choices there are and when the buttons can be pressed? I think so.

    I feel like your idea would be practical so long as each choice didn't need their separate UI (and separate macros). There are about 40 choices in the show, if each one needed a separate macro, then that would take a lot of programming time. Other than that, I think I just applied a UI to a physical hardware component.

    I am new to this though, if my prototype is a big nono then please tell me.

    Cheers!

Reply
  • I really like this. Probably because it's quite similar to my prototype.

    Instead of having direct selects, I'm abusing the fact that on the ion faders can have either a green or red light (additive or inhibitive). By default I have ten subs (ten choices) all in inhibitive mode and their buttons unbound

    When a choice cue is loaded, it executes one of 10 macros that will activate that many subs, put them into additive mode and bind their buttons to another macro that will make the jump to whatever choice the audience makes.

    Ill probably change this to just a plane copy so that it's easier to program as this show will be run in a different venue on a different board (still an ion luckily).

    For the actual 'jumping', the macros are goto cue commands, the first choice is one cue ahead (one press of [Next], 2 is +2cues ([Next] [Next]), etc.

    The goto's load what I'm calling 'response' cues. Each one has a link to a separate cue list, or a different segment in the same list. they have a follow time as 0 and have the same look as the choice cue. I can get away with this because somewhere on the forums the other day I saw if you append [Time] to a goto command it uses the time of cue its jumping to, and triggers follows.

    Once a choice button is pressed, the subs are disabled again.

    The benefit to this is, because the macros are just pressing [Next] a variable amount of times, it is applicable to all my choices, so long as the choices are all programmed the same.

    Is it over-engineered? absolutely. Is it abusing colourful lights on the ion? Yep. Is it obvious to the op how many choices there are and when the buttons can be pressed? I think so.

    I feel like your idea would be practical so long as each choice didn't need their separate UI (and separate macros). There are about 40 choices in the show, if each one needed a separate macro, then that would take a lot of programming time. Other than that, I think I just applied a UI to a physical hardware component.

    I am new to this though, if my prototype is a big nono then please tell me.

    Cheers!

Children
  • That's a great use of the hardware, and there's certainly nothing functionally wrong with the approach you're taking here.  If you want a physical button to press rather than a soft-button like a direct select you may as well use the fader buttons on the desk.  Assuming you don't need the faders for anything else of course

    I personally favor the soft-button approach because it allows for more information to be presented to the user by means of larger possible label fields and macro color flags.  It's also rather less programming time to set up and has fewer potential points of failure.  Whether or not these factors are important strongly depends on your situation, of course.

    If your macros are modular, you can re-use them the same way in custom Direct Selects by mapping one macro to multiple Custom DS slots, just the same as mapping to Fader buttons.

    You mentioned macros being unreliable but haven't said what specifically is unreliable about them.  Are you seeing unintended behavior or encountering errors?  One risk of using modular macros is that you need to be 100% certain the desk is in the correct state before you execute them. Sometimes it's possible to enforce that within the macro, other times it may not be.

  • I like what your saying with the macros and direct selects. But unfortunately my macros are having unintended behaviour. Such as:

    The macro will only execute the first three commands, regardless of the commands it's executing
    Loops fail
    Labelling a cue will work only sometimes, other times crashing the macro
    The macro behaves differently depending on if it is run on ion or nomad

    I found that I can temporarily fix this issues if I create a new macro which is a perfect replica of the old one, but eventually, this fix stops working.

    I am enforcing the state of the board with the macro, so the start state shouldn't be the issue.

  • Could you give us details of the macros,  as some of us them heavily and we've not had the kind of issues you are describing other than label generally does go wrong (I may get some push back on that from people that have made it work ok, but unless its the last thing in a macro it seems to not know reliably when to finish the label and when to continue the macro).

    The most common reason for macros seeming to give up is just a missing enter to the confirm prompt that might appear if you are copying over something. you need to include the extra enter in the macro. Your 3 command only issue sounds like that situation.

    Unless your running different versions of the software nomads and the ion will be the same,  back at 2.5 2.6 there were some changes and I did get caught out on that when not upgrading the ion to the version I had on nomads.

  • +1 to what Mike A said.  I just slapped together a quick prototype that provides all the features you describe with no errors.

    You will probably need to put the macros executed from the cue stack into Foreground mode to get all the labels and copies to work.

  • I'll describe to the best of my memory, keep in mind though that if I'm not confident in a fact I'm going to jump over it.

    An earlier prototype of my Macros involved using a Macro Loop, however, after further development, I started to encounter problems with the loop, in the form of silent crashes, or the 3 command only thing, conveniently, the third command in a previous version was the macro end loop command, but I'm not sure if that is related or not. Even after removing all loops, the macro always ended at that same point.

    Rebuilding the macro fixed that problem but more started to pop up. My solution was just to simplify the macro, meaning more upfront programming but it does appear to be more stable. Currently, my macros look like this:

    Macro for activating the subs, and binding their buttons to other macros
    There are ten macros, the first activates one sub (yes redundant, i know), the next activates 2 subs, then 3, 4, etc, all the way to 10. It is run in background mode.

    This is macro 523 (as referenced above):

    The only thing that changes between 521 and 523 is the amount of [Next].
    I'm also unsure why an extra termination is needed after the macro is trigger, can someone explain that to me?

    This one is run in foreground mode.

    Macro 523 was the macro with different behavior on the ion as opposed to nomad. On my ion I could run this macro in background mode no problem. On nomad (which is on the same version as the ion), it doesn't appear to like that, but runs fine in foreground mode. Thanks the help fixing that!

    (Macro 501 just unbinds all the buttons and sets the subs to inhibitive mode, it has never failed)

    These macros work fine, most of my pain has come from the macros I built for programming:

    This macro creates a cue that the subs jump to when selected, 60% of the time it crashes at the label. (Like Mike said). It is being run in foreground mode, and I have no clue why it fails that sometimes (unless when typing in a link it tries to relabel the link cue?)

    Hope that helps describe my problems! Cheers!

Related