What Do You Actually Test Before a Gallery Goes Live?

Almost every first conversation about a new or upgraded gallery reaches the same question: how will we know it works before the first broadcast? It is a fair thing to ask, because a gallery is not one product. It is a vision mixer, a router, monitoring, intercom, tally, timing and a great many cables, all of which have to agree with each other under pressure.

Our answer is that nothing is assumed to work until it has been seen working, in the way the crew will actually use it. A device that passes its own self-test tells us very little. A signal that leaves a camera, crosses the router, appears on the right monitor wall and reaches the programme output with the right tally tells us a great deal.

This note sets out how that testing goes, in the order we do it, so that a producer or engineering lead can judge whether a proposed integration plan is thorough enough.

Testing begins before any equipment is unboxed. We write down every source, destination and path the gallery needs: cameras, playout, graphics, remote guests, studio displays, recorders and the feeds that leave the building. From this we draw a signal flow and agree it with the client.

The flow settles questions that are cheap to answer on paper and expensive on site. How many mixer inputs are truly needed? Which monitors must show programme and which preview? Where does intercom split between the gallery, the floor and the presenters? Who needs talkback to whom?

We also record the formats in use, such as resolution and frame rate, because a mismatch there causes problems that look like faults but are really design gaps. The agreed document becomes the checklist we test against, line by line.

• Every source and destination listed and named
• Formats and frame rates agreed up front
• Intercom groups and talkback paths drawn out

Wiring is where reliability is quietly won or lost. We run and dress cable to the plan, label both ends of every run, and keep patching logical so that a stranger could trace a signal at three in the morning. Neat work is not vanity; it shortens every later fault to minutes.

Before connecting anything live, we check continuity and look for obvious errors such as swapped pairs or poor terminations. Then equipment goes on in stages rather than all at once, so that a problem can be tied to the last thing added.

Only once the base layer is stable do we bring up the vision mixer and router and name every input and output as the crew will know them. A label on a button that matches the label on the monitor prevents more on-air mistakes than any manual.

This is the stage that answers the question. We pass test signals through the full chain and then real sources, confirming that each camera reaches its mixer input, each monitor shows what its label claims, and tally lights follow the programme bus correctly. We check audio travels with the picture and stays in step with it.

Intercom is tested from every position, including the awkward cases: a producer cutting across a director, a floor manager heard in the gallery while the studio is quiet, and a talkback to a presenter's earpiece. Each should behave as the plan says.

We then try to break things deliberately. We pull a source, change a route mid-programme and trigger the fallback paths we have designed. A gallery that recovers calmly from a planned fault is far more trustworthy than one that has simply never been challenged.

• Every camera traced to input, monitor and tally
• Intercom checked from each position
• Fallback paths triggered on purpose

Equipment passing its checks is not the same as a crew being comfortable with it. We schedule a rehearsal with the real team, running a short mock programme with the sources, graphics and cues they will use. This often exposes small things no test sheet would: a monitor placed just outside someone's eyeline, or a button layout that invites a slip.

We adjust on the spot where we can, and note anything larger for a follow-up visit. The aim is not a flawless demonstration but a crew who know where everything is and what to do when something misbehaves.

Where in-house operators are newer to the equipment, we pair this with practical guidance at the desk, so that confidence is built on the real system rather than on slides.

A good integration ends with documentation you can use. We hand over the final signal flow, the labelling scheme, the intercom groups and a short record of what was tested and how it behaved. If a fault appears months later, your own engineer should be able to start from facts rather than guesswork.

We also leave a plain list of the fallback procedures that were tested, written for the people on shift rather than for specialists. Short, clear and kept near the desk, it is the page most likely to be read when it matters.

If a supplier cannot show you this kind of record, ask why. It is the simplest measure of how seriously the testing was taken.

• Final signal flow and labelling scheme
• Record of tests carried out and results
• Fallback procedures written for the shift crew