FOH Console Tech Rider: Inputs, Show Files, and Handoffs

TL;DR — An FOH console tech rider should define the required input and output capacity, stage I/O, console workflow, control position, networking or recording handoffs, guest-engineer access, show-file compatibility, and fallback plan. Specify operational needs before preferred brands. Send the current input list with any show file, identify its exact console software version, and never assume a file will load unchanged on another system. Confirm the final package during the production advance.

Table of contents

1. Define the FOH job
2. Turn the input list into capacity
3. Specify the console without over-specifying
4. Plan show-file exchange
5. Document the FOH position and handoffs
6. Advance the guest-engineer workflow
7. FAQ

Define the FOH job

Start by describing what the engineer must operate, not which logo must be on the desk. The console section should connect the stage inputs to the audience mix and every production output that FOH owns.

Record:

• total physical inputs from stage and local FOH sources;
• required mono and stereo input processing paths;
• audience-system outputs and matrix feeds;
• communication, talkback, playback, ambience, recording, broadcast, or press feeds;
• who mixes FOH and who mixes monitors;
• whether the artist carries a console, stage rack, control package, or only a show file;
• whether the venue console is shared with support acts;
• changeover, line-check, and soundcheck constraints;
• an acceptable fallback if the preferred system is unavailable.

Keep the scope explicit. A touring FOH engineer may mix only the main audience system, while the venue engineer owns delays, fills, lobby feeds, or system processing. Write that boundary down.

Turn the input list into capacity

The current input list is the source for console input capacity. Count physical stage inputs, then identify additional paths that consume resources but may not appear as stagebox sockets.

Example capacity summary

This is a documentation pattern, not a universal console specification. Replace the numbers and functions with the actual show.

Do not assume that a console advertised with a large channel count has the required physical sockets, stage I/O, output connectors, processing paths, expansion cards, or software configuration. Confirm the complete system.

Link every input to a stable source name. Stereo sources should occupy paired rows, and monitor-only channels such as click or cues must still be visible if they pass through the FOH console.

Specify the console without over-specifying

Lead with operational requirements

A useful console requirement might state:

Digital console with at least 24 confirmed stage inputs, the outputs and buses listed below, recallable scenes, per-input processing suitable for the show, talkback, and compatible stage I/O. Artist FOH engineer must receive full mixing access. Final model and configuration require advance approval.

Then add preferred models only when they reflect real operator familiarity, carried files, plugins, I/O, or workflow. Separate:

• required — the show cannot be delivered safely or correctly without it;
• preferred — the touring team works faster on it;
• acceptable alternative — confirmed models or capabilities that can perform the job;
• not acceptable without approval — a meaningful limitation, explained plainly.

Avoid long brand wish lists that hide the real requirement. “Professional digital console” is too vague; one exact model with no functional reason is often too rigid.

Confirm the whole console system

For the agreed desk, verify:

• surface and engine model;
• console software or firmware version;
• stage rack and I/O model;
• installed input and output cards;
• digital transport between stage and FOH;
• sample-rate or clocking requirements when external digital equipment is involved;
• local I/O at FOH;
• network access needed for artist-carried control devices;
• supported recording or virtual-soundcheck connections, if required;
• user permissions and guest-engineer access.

Do not assume venue networks are available for artist devices. If remote control is required, state what the artist carries and have the venue approve the connection plan.

Plan show-file exchange

A show file can reduce setup time, but it is not a substitute for the input list, system confirmation, or soundcheck.

Before sending a file

Record:

• console family and exact model;
• software or firmware version used to create the file;
• file creation or revision date;
• input-list revision that the file matches;
• stage-rack and card assumptions;
• scope of stored data, such as channels, buses, scenes, routing, or user keys;
• whether external plugins, servers, licenses, or hardware inserts are required;
• who is allowed to load, convert, or modify the file;
• a non-file fallback.

Console file formats and stored features vary by manufacturer, model, and software version. Confirm compatibility using the manufacturer's documentation or support process for the exact systems involved. Back up the venue's current state before any approved load, and let the responsible venue technician control the operation.

After loading

Verify rather than assume:

1. channel names and patch;
2. stage-rack and local input assignments;
3. output and matrix routing;
4. mute groups, DCAs, scenes, and recall scope;
5. talkback and communication paths;
6. monitor sends when FOH owns them;
7. external processing and digital connections;
8. user access and control devices;
9. safe output state before audio passes.

Keep a readable input list and patch plan available if the file cannot be used. The production should still be able to build a basic mix from the written documents.

Document the FOH position and handoffs

FOH position

The mix position should allow the engineer to hear the audience system and see the stage. Confirm:

• location relative to the audience and PA coverage;
• usable footprint for the console, computers, racks, and operator;
• whether the position is covered outdoors;
• safe access and cable paths;
• power and lighting;
• communication with stage and monitors;
• any seating, barricade, security, or public-access constraints.

Do not accept an obstructed or acoustically isolated position by default when the engineer is expected to judge the audience mix. If the venue has a fixed location, review its limitations during the advance and agree on the workable plan.

Audio and data handoffs

List every boundary between artist and venue systems:

Replace generic handoffs with the actual connector, format, sample rate when relevant, provider, and responsibility. Do not add broadcast, recording, or press feeds unless the production actually needs and authorizes them.

Advance the guest-engineer workflow

When an artist travels with an FOH engineer but uses the venue console, the advance should establish authority and support:

1. venue production and systems contacts;
2. final console, engine, stage-rack, card, and software versions;
3. current input list and output responsibilities;
4. show-file delivery deadline and loading process;
5. patching responsibility;
6. guest access level and venue supervision;
7. system processing boundary;
8. support-act sharing and scene-management rules;
9. recording, network, plugin, or external hardware needs;
10. soundcheck, line-check, and doors deadlines;
11. restore or handback procedure after the set;
12. fallback if the preferred console or file is unavailable.

Turn every exception into a named action with an owner and deadline. The process in How to Advance a Show helps keep those decisions visible.

After the advance, update the same Rider rather than leaving the agreement in a separate email chain. Invite the FOH engineer or tour manager to edit and save the Rider and inspect history. Share a view-only link with the venue, and export a dated PDF for offline use.

Common FOH-rider mistakes

Naming a console without stating capacity or workflow. Explain the inputs, outputs, I/O, access, and operational reason.

Counting input channels but not physical sockets. Confirm the stage rack, local I/O, cards, and transport.

Sending a show file with no version information. State the exact model, software version, revision date, and matching input list.

Assuming a loaded file is correct. Verify patch, routing, scenes, outputs, and external dependencies before passing audio.

Leaving system-processing ownership unclear. Define who controls the console mix and who controls PA processing, delays, and fills.

Requesting recording or network access casually. Document purpose, format, permission, hardware, and ownership.

Pre-send checklist

• Input capacity matches the current numbered input list.
• Physical stage and local I/O are confirmed.
• Every required output, bus, matrix, and utility path is stated.
• Required, preferred, and acceptable console options are separated.
• Console, engine, stage rack, cards, and software versions are recorded.
• Show-file revision and matching input-list revision are clear.
• External plugins, hardware, networks, and licenses are assigned.
• FOH position, footprint, power, access, and communication are agreed.
• Guest-engineer access and system-processing boundaries are explicit.
• A readable no-file fallback exists.

FAQ

What should an FOH tech rider include?

Include input and output capacity, physical stage I/O, console requirements, stage-to-FOH transport, control position, communication, system-processing boundaries, guest-engineer access, show-file details, external hardware or network needs, schedule, and fallback plans.

How do you specify a mixing console in a tech rider?

State the operational requirements first: input and output capacity, physical I/O, buses, processing, recall, access, and handoffs. Then list a preferred model and acceptable alternatives when familiarity or file compatibility matters. Confirm the entire configured system, not only the console surface.

Should you send a console show file before a show?

Yes, when the venue has confirmed the exact compatible system and loading process. Send the file with its console model, software version, revision date, matching input list, dependencies, and scope. Keep a written patch and a no-file fallback.

What is a guest engineer tech rider?

It is the production section that explains what a touring engineer needs from the venue to operate the show. It covers the console system, access, patch, files, FOH position, system handoff, schedule, support from venue staff, and responsibility boundaries.

Where should the FOH console be located?

Place it where the engineer can hear representative audience-system coverage and see the stage, with adequate footprint, safe access, power, communication, and weather protection when outdoors. Review any fixed or obstructed position during the advance.

Make the console plan part of the Rider

Build the FOH input list and stage handoff in Techrider.live, invite the engineer to edit the same Rider, and share the current link with the venue before sending a console file.

---

Last updated: 2026-07-27 · Reviewed for FOH console capacity, show-file exchange, guest-engineer access, and production handoffs.