I mentioned in the Quadstock post that the program day is “pretty much just building an ArrayCalc file and exporting to R1”. A few people asked what that actually looks like, so here's the whole workflow, start to finish, the way I do it for a d&b rig. It's not the only way. It's the one that means I'm calm on show day.
Before you open ArrayCalc
Get real numbers. A venue drawing if there is one, and if there isn't, a laser measure and ten minutes on site or a very honest conversation with the venue tech. What I need:
- Distance from the array position to the furthest seat, and to the front row.
- Trim height, or at least the ceiling and any rigging limits.
- Where the audience actually is — standing floor, raked seating, a mezzanine, a mosh pit that turns into a car park after 10pm.
- What boxes I've actually got. Not what I'd like. What's on the truck.
Guessing any of these is how you end up re-hanging an array at 4pm.
Modelling the room
In ArrayCalc I draw the audience areas first, before I touch a speaker. Floor, raked seating, balcony as separate planes. This is the part that makes the prediction mean something — the software's only ever telling you how the boxes cover the surfaces you drew.
Then the arrays. For a typical mid-size show that's mains left and right, subs across the front, and front fills if the stage is high. I'm looking for even level across the audience planes and, just as importantly, keeping energy off the walls and the stage. A slightly quieter but even rig beats a loud one with a hot spot every time.
Subs
I'll almost always set up the sub array as cardioid if I've got the boxes for it. Less low end on stage means the vocal mics stay cleaner and the band can hear themselves. ArrayCalc will show you the rear rejection; trust it, then confirm it with your ears on the day.
On the Quadstock rig it was two Q-subs and two SL-subs a side with some Q1s in the middle for fill, and it sounded really, really good. That's not luck — that's the model saying it would and then the measurement agreeing.
Export to R1
Once I'm happy, I export the project to R1. This is where the naming discipline pays off. I name every source, every group and every zone in ArrayCalc before exporting, because those names come through and become what you see at FOH. “Mains L”, “Mains R”, “Subs”, “Front Fill”, “Delays” — not “Array 1”.
In R1 I let it build the standard group tree, patch the amps, and check every channel is where the model thinks it is. Then I make the remote views I want on the show.
Remote views: the thing I actually look at
This is my strong opinion. The default R1 views are built for a system tech at the amp rack, not for someone mixing a band. What I want at front of house is one screen that shows me level, mute and a couple of EQ handles per zone — nothing else. Big, readable, glanceable.
I got sick enough of building these by hand that I wrote a little tool to do it. It reads the group structure R1 already made and generates the operator views automatically, and it never touches your original file. It's up on the projects page if you want to try it — it's the exact thing I use on my own gigs.
Show day: verify, don't assume
The model is a prediction. On the day I walk the room with a measurement mic and confirm that the coverage is what ArrayCalc said it'd be, then time-align subs to mains and fills to mains. If the room's fuller or emptier than planned, the top end will have moved and I'll adjust. The point of doing the prep isn't to skip tuning; it's so that tuning is small moves.
The panic I'm avoiding
Every bit of this is about not having to make a big decision under pressure. When the band's on stage and the promoter's asking why the back row's quiet, I want to already know the answer from the drawing, not be working it out with 800 people watching. Do the boring work on program day. Show day gets to be the fun bit.