Feature request = Assignment of backup instances

[wvanmaris]

Describe the feature The possibility to assign a backup instance to a main instance in instance settings. E.g. you have a QLAB main system and want to control a QLAB backup system. All buttons can be made with just a command for the QLAB main system, but because the backup system is assigned as backup instance for the main, all commands are sent to both. This can be passed by, by just adding cues for both instances on each button, but by having a general "follow" / "clone" / "backup" option, it will save a lot of work. Perhaps the feature can be further enhanced by being able to send a delay option for the backup command.

Is this platform dependent (windows, mac, ..)? no

If documentation is required to implement, do you know where to find it? If applicable, add screenshots, protocol description PDFs, etc to help the developers along

Usecases Useful for any system that often is backed by a secondary backup system (mediaservers / lighting consoles / seamless switchers, or even (if multiple backup instances could be applied) projectors and such (for global shutter commands).

[skermanator]

Would love this feature

[sphlabs]

Just bumping this to see if there are any active plans/ideas on implementing this feature?

For more complex setups, this would be an immense time/error saver, vs. manually duplicating all actions on all buttons.

The main complication I can see is in handling feedback and variables (although feedback might not be so bad in a lot of cases) but at least having this for actions would be a big win.

[Julusian]

I see a couple of challenges which need good solutions for this:

Different connections from the same module can have different actions/feedbacks exposed
Different connections from the same module can have different options for an action/feedback (while the name of something might be the same, it could have a different id internally.
This means that a companion-level primary/backup setup wont work with some modules. I dont see a good way around that.

Building on that, what if the systems are setup slightly differently, and need slightly different parameters? perhaps inputs to the mixer are patched slightly differently for reasons out of your control

Do we need a way to add actions that address the 'pool' as well as an option to address an individual connection in that pool?

Which do we use for feedback?
I am thinking that there should be a panel to select which is the primary, and it is the primary that we use for feedback and variables. To begin with we could keep the primary to be manually selected, that could be expanded to auto select one later on

I dont really have any experience in this area of using backups for this kind of equipment, so I am not entirely sure if these concerns are valid, or how best to solve them. As such, I will find it hard to motivate spending my time on this instead of other features. It may happen, but it definitely needs more of a plan on how it should work before I will consider it

[Sullyy]

"Useful for any system that often is backed by a secondary backup system (media servers / lighting consoles / seamless switchers, or even (if multiple backup instances could be applied) projectors and such (for global shutter commands)." At least 3 from this examples media server, seamless switchers - projectors, if not all4 need to be idemntical and with identical connection, setup, programing, to function as backup anyway, so the feedback would be the only issue here i think. I would mainly use this feature for media server, resolume, millumin... witch i backup when i can, and use identical machines. for this feature I would easy give up feedback, or use an internal feedback - button pressed or something just to show me where i am, i would take a-lot of time off preparing a show

[Sullyy]

or is this "the possibility copy the commands sent to an instance to another similar instance. ex: 2 resolume, 1 is backup- i need to copy all the commands from the main to the backup resolume." from my thread witch you closed earlier as it was a duplicate, an easier solution?

[sphlabs]

I would echo that sentiment. The idea would be to send identical commands to the backup device; the idea being that they are identically configured and should be running in lock-step with the primary. For setups where the backup system is doing something different, then that would have to be programmed manually as a second device.

But there are many, many production that have identical systems running in tandem for which this would be applicable.

In terms of feedback/variables: If instances are flagged as primary/backup (or primary/secondary/tertiary/etc) then feedback could come from the primary system. To be fancy/stretch goal--if the primary loses connection then feedback comes from secondary, etc. This could include cases where the primary is manually disabled via a button for cases where it's not working properly but still connected.

Octopus does this, or something very similar; although it's a while since I've used it so can't remember all the specifics. But it does have a primary/backup concept, and can support multiple backups. They all get the exact same commands as the primary.

[Julusian]

Yeah the initial implementation could definitely make the assumption that everything is identical. But I worry that 'they are identically configured' can be misleading. I know that the vmix api uses guids for a bunch of things, as global consistent identifiers for things. So while you will probably start off by building a project file and copying it to the backup machine, when you get to adding an extra thing last minute, you would probably rather follow the same steps on each machine to add the missing thing, resulting in them having different ids. Again, this doesnt have to be a solved for the first iteration, but I do expect some frustration from users over this limitation if its not communicated well

[rywolf]

Yes this please!!!!! Backup instances that do what the primary does.

[kman1898]

Any updates on this?

[sphlabs]

To come back to @Julusian ’s concerns from his last post:

I think assuming things are identical is the end assumption, not just the initial one, if things aren’t identical then the programmer doesn’t have a primary/backup setup and it isn’t Companion’s place to make decisions in that circumstance.

I’m the example of vMix, I wonder how many people use guids rather than the input name or index? I suppose with appropriate hooks, a module could be aware of backups, and a primary using guids could somehow communicate alternate means of reference…? But that’s really getting into the weeds and over complicating things for the majority of cases.

In the spirit of “don’t let perfection be the enemy of good enough”, I do think an initial implementation with some “here be dragons” warning would make a lot of people very happy!

Oh, and I do like the idea I read in a duplicate thread of specifying an instance-level delay time for each backup instance.

[wvanmaris]

Regarding Stephen Harrison: I see you point, but that was not the thought behind it. We’re talking a true backup where it NEEDS to be the same. Like a HOT backup ppt machine or QLAB instance. In real life you would edit on one machine, sync all content to the second and just need a way of controlling them both without having to enter two command on a single companion button. I think you’re overthinking the request. And yes, having a possibility to delay the command to the backup instance it valid. 

[sphlabs]

On the contrary, I agree with you completely, that the backup systems do need to be identically configured, and that that is the user's responsibility, not Companion's.

[kman1898]

Couldn’t agree more with y’all. Identical is the way to go. We can’t go over complicating things. If your use case is different then can go an alternate route.

[Julusian]

ok, it sounds like there is a plan formed here now then.

one question I had hasnt been answered

Do we need a way to add actions that address the 'pool' as well as an option to address an individual connection in that pool?

I'm thinking this as a case of you might intentionally want to unsync them at some point, so you can check your routing or something. for example, set the primary to red and backup to blue.
this could be handled by adding each device twice, once as part of the primary/backup system, and once as individual connections. so maybe this can be ignored?

It sounds like what this needs now is someone with time to figure out a how to implement it and then do it

[wvanmaris]

The way I envisioned it, was two separate instances, and having the option at any of them to assign the other as backup. With the condition it needs to be the same type of instance. In this backup instance setting it would be great to have a general delay setting or the likes. And having feedback from both would be awesome (as in a orange square if one of the instances is not available and red if both are. 

[kman1898]

Any new progress in this realm?