• State Not Answered
  • Date
    travisres
  • Date
  • Replies 4 replies
  • Subscribers 184 subscribers
  • Views 7177 views
  • Users 0 members are here

Stop/Back Function in a Linked Multi Playlist environment

The setup.

RPU - Primary Master

EOS - Backup Tracking - Running Cue List 2 - partitioned to Moving light channels

ION - Client - Running Cue List 1 with an External Link to List 2 - partitioned to conventional channels.

The link is working great for running the show. Every Go on List 1 triggers list 2 if the appropriate cue exists.

Where we are running into troubles is when going back a cue. The default back time on both consoles is set to 1 second. When the Ion presses back, it takes List 1 back a Cue in 1 second. It also tells List 2 to go back, but List 2 goes back in Cue time. I am assuming that when you link a list, it is just sending a GO TO CUE command to the linked list, so this may be a lost cause as GO TO CUE has to be in cue time for the functionality to work correctly, but... is there a way to go back on a linked list in a default time rather than cue time? I know one answer is to have the EOS press its own back button before the Ion presses back, but we then will just end up reloading the cue which isn't really wanted either.

Thoughts?

Thanks

 

 



[edited by: travisres at 3:15 PM (GMT -6) on Thu, Mar 19 2009] Fixed spelling of subject
Parents
  • 0


    Ah, interesting.  The back command is triggering the execute for the second list in its actual cue time, not the Go to Cue time.  What's needed here is a bit of code that forces different timing if the cue in the execute list is triggered by a back action, rather than a go action.  No immediate workaround for this other than what you've suggested, but will put on the list (with a priority).  We are in final testing for 1.5, so this won't make it into our upcoming release.  But look for it shortly.

    Thanks!

    a

Reply
  • 0


    Ah, interesting.  The back command is triggering the execute for the second list in its actual cue time, not the Go to Cue time.  What's needed here is a bit of code that forces different timing if the cue in the execute list is triggered by a back action, rather than a go action.  No immediate workaround for this other than what you've suggested, but will put on the list (with a priority).  We are in final testing for 1.5, so this won't make it into our upcoming release.  But look for it shortly.

    Thanks!

    a

Children
  • 0 in reply to Anne Valentino

    After playing with it for a couple days I realized that my Go To Cue assumption was completely backwards as this console does not have a setting to set the default Go To Cue time to Cue time. I was stuck in Grand MA land. Silly me.

    Thanks for taking a look at it. We've gotten sneaky with some macro's for the time being.

    But, while you're looking at it and maybe making changes... would it be possible to make it not only send the Back execute command in default time, but also have similar functionality when a Go To Cue command is used on a linked list? So a Go To Cue Time 5 sent to list one, would pass that temporary time onto list 2 as well?

    In the tech process, just as often as we are pressing back, we are also using Go To during note sessions as we jump around the show making changes. Or,.... is there a way to run in a cue once it has been started?

    Thanks much!

     

    -Ben

  • 0 in reply to travisres
    Make a macro that says 
    GoToCue Time 1 Enter
    travisres said:
    is there a way to run in a cue once it has been started?
  • 0 in reply to jabadger

    You can press manual override/load.  That grabs manual control of the entire cue.  Dropping the fader grabs manual control of just the intensity.

    We will also change it so that if you do a go to cue x, and cue x is executing another cue, both cues will go in the go to cue time.  

    hope that helps.

    a

     

Related

www.etcconnect.com