Since a couple of you asked, here is the honest version of the two-cursor half of our setup. Two operators, one Windows machine: one switching, one on replay. Separate mouse and keyboard each, independent cursors, same vMix instance, replay window on the second operator's own monitor.
It works, but not for the reason I assumed, and most of what we got wrong was not about cursors at all.
1. Separate cursors does not give you separate keyboard focus
This is the big one and I had it wrong at the start. Multiple pointers on one Windows desktop do not mean two focused windows. Keyboard input still goes to whichever window has focus, so:
- Anything driven by keyboard shortcuts or text entry belongs to one operator at a time.
- If the replay operator clicks into the replay window, that becomes the focused window, and the director's next keyboard entry may land there instead of where they expect.
- This is, I think, why controller-based replay workflows are so dominant here. A StreamDeck, a jog/shuttle, a MIDI surface - those send their commands without needing window focus at all. They sidestep the problem instead of managing it.
Our mitigation was to stop pretending the keyboard was shareable: the mouse-driven operator gets pointer tasks, anything shortcut-driven goes on a controller, and we are explicit about who owns the keyboard at any moment.
2. Fullscreen and exclusive-capture surfaces behave differently
Some apps will not render a second cursor, and some hide the cursor entirely in fullscreen or exclusive mode. Test the actual application in the actual mode you will use it, not a windowed approximation. Same applies if there is a remote or virtual session anywhere in the chain.
3. Two pointers can conflict in the same window
Hovering and selecting independently works fine. Two operators doing sustained drag operations in the same application at the same time still does not. Our rule became: one operator, one window. It has never come up in a real show since we adopted it.
4. Windows have opinions about which monitor they belong on
Dialogs and child windows tend to open on the primary display or relative to their parent, which in a two-operator rig means they appear on the other person's screen. We assign what we can by script or shortcut, and design around the rest rather than fighting it.
5. Two keyboards means two chances to trigger a global hotkey
Any application with global hotkeys - recording, push-to-talk, mute - needs an audit. We found at least one conflict that would have been ugly live.
6. Our worst live failure had nothing to do with any of this
It was a setting left over from a rehearsal. An audio device default that the next show did not want. Not a dead machine, not a cursor problem.
That one changed how we think about the whole thing. The risk of a rig like this is not more boxes or more cursors, it is more state that nobody put back. Which is a solvable problem, and not really a hardware problem.
What we would do differently
1. Automate startup and teardown. Startup sets the environment for the show type; teardown puts it back explicitly, including saved defaults, especially the default audio device. If a script can own it, do not leave it to memory or to a checklist.
2. Close things in the right order, with the right signal. Some apps need to quit gracefully to save state. Hard-killing leaves things half-written and you find out next week.
3. Rehearse teardown too. We rehearsed the show and not the end of it. That is where our failure came from.
4. Keep the human checklist for what genuinely cannot be automated - camera framing, program audio, stream key. Short list, actually checked.
Honest boundary
A single box with two cursors is not equivalent to two machines. Two boxes buy you per-task optimisation and fault isolation, and this does not. What it buys is everything that goes with one show on one machine: one set of sources, no NDI round trip, one thing to prepare and one thing to tear down. For the smaller rigs, where a second box is a real cost and the show often stays a one-person job, that trade has been worth it for us.
If anyone wants the specifics of how the two-cursor part is configured, happy to go into it. The parts above are what actually cost us time.
