Partitioned control with client/RVI

I have a show coming in that wants to use two programmers, one for conventionals and one for moving lights.  I know that this can be done with partitioned control on the EOS, but I need to make sure that a client or RVI can be used for the second programmer.   I would try this out but I can't reconfigure the system with a show sitting in the hall and by the time this show is gone I will have to have a solution in place.

I am planning on buying an X-keys for the client or RVI and using that to program the conventionals while the moving light programming is done on the console.

Has anyone done this this way?  Any tips on making the process run smoothly?  (I am going to suggest recording the ML cues and conventional cues into separate cue lists and then linking them on playback)

 

Thanks,

Todd

 

Parents
  • Short answer - Yes you can!

    Just make sure the Client/RVI is a different User to the Primary so you don't end up sharing the command line.

    The only gotcha is to remember that the Master is actually doing the real work, so the showfile should be saved and loaded there.

  • Richard-

    Thanks for the info- the different programmers will be set up as different users.  I'm not sure what you mean about saving and loading from the Master- our console is actually the backup (with a RPU as master) and we save and load shows on it all the time with no problems.  Is there something with partitioned control that changes how saving works?

    -Todd

     

  • If the RPU is the master and that is where you save to, then That should be fine.  I don't think it was mentioned that you had an RPU in your system in this post.

    The point Richard was trying to make (and correct me if I'm wrong) is the master console, whether it be a console, RPU, etc... is the console that does all the number-crunching and thinking.  Therefore, if you had a console and a client, you need to make sure that you save to your master as that is where all the action is taking place, so to speak.  In your case, you have an RPU as master, so then the EOS console, and other clients are essentially facepanels, or interfaces and don't do all the hard work.

    Hope that makes sense

    Cheers - BFJ

  • Brent-

    What I have seen with my system (1 console as Backup, 1 RPU as Master, 1 RVI always connected, and 1 laptop sometimes connected as Client) is that every device that is connected saves a local copy of the show when any device executes a "save show" command.  Since the Master is always on, it always saves a copy.

    I guess my point is that the Master will always have a copy (the master copy, if you will) of the show and it doesn't matter what device you are using when you perform the save command.

    I don't know if this is affected by using partitioned control- is it?  If one user saves the show while the other user is actively updating levels/cues, what happens? 

    Thanks - Todd

     

  • Partitioned control doesn't affect how the show is saved/loaded.

    The Master console is the one that's actually in control, and thus is the one that holds the 'definitive' copy of the show - the other consoles/clients all take their copy from the Master (you'll see this go through during load)

    When one user saves or loads the show, it tells the Master to do so and then re-distribute the show - so everyone will have to pause work during the save/load procedure.

    The key thing is that it's the Master that's really 'in charge' and doing the work - so don't turn it off while the other programmer(s) are still working!

  • In an effort to add a bit of clarity here - leaving partitioned control off the table - as it has nothing to do with how files are saved....

    When a save or save as is initiated from ANY processor on the network, ALL processors save that show file to their local hard drive.   The current designation of "Master" is (as has been pointed out) the processor that is currently servicing the lighting rig - and, in case of any kind of data hickup - determines what the content of the current show should be.    The UI at a device is serviced by the the local copy of the show file.   

    When devices come on the network, the master will always shoot across what it determines as the "current" show - current output, active cues, data content, etc.  That data is then resident on the local processor.  

    There is a difference between local and global commands.  A local command is "1 at".  That instruction has not been finished, so only the processors assigned to the associated "user" see the command.  As soon as you say "full enter" - that is now a global command and all processors are aware of it.

    Does this help at all?  :-)

    a



    [edited by: Anne Valentino at 10:13 AM (GMT -6) on Wed, Dec 17 2008]
  • Anne and Richard-

    It's all clear - that's exactly what I am used to.  Since I never turn off the Master processor, the show is always safe (and saved) there.  I could see where things could get ugly if you have two programmers, one on a Master and the other on a Client, and the Master was shut down accidentally when the Client programmer was still working.

    -Todd

Reply
  • Anne and Richard-

    It's all clear - that's exactly what I am used to.  Since I never turn off the Master processor, the show is always safe (and saved) there.  I could see where things could get ugly if you have two programmers, one on a Master and the other on a Client, and the Master was shut down accidentally when the Client programmer was still working.

    -Todd

Children
No Data
Related