Touring with a super detailed, highly programmed light show is great, until you find yourself having to adapt to more limited venues than anticipated.
I found myself facing this problem earlier this year. A band I've been working with had mostly been doing big one-off festival shows, and not a huge amount per year. With those circumstances, it wasn't a big problem for me to manually go over the showfile for every show and fixing things that didn't really work with each festival rig.
Until they booked a two week club tour through Europe, and while it was a big step for the band, the variety of venues ranged from tiny 100-capacity music places to the mainstage of a festival with 40,000 sold tickets.
Spending a couple of hours per show doing previz would be possible, but I kept making more or less the same substitutions, which left me wondering if I could lighten that workload.
The easy option, and the engineering perspective
The first thought was to just build a second "minimal" showfile, for very small rigs. This would be a lot easier to scale up, but it would mean having two base files to keep up to date and program new tracks into. I absolutely hate doing repetitive work though, so keeping two separate showfiles up to date sounds like a pain.
DRY (don't repeat yourself) is one of the first things hammered into you when you're learning computer programming. If you notice you're writing the same code multiple times, it means you can probably simplify something, or extract it into a reusable bit of code, so that when you change some part of it, it updates anywhere. A great example of DRY in lighting programming would be using presets in your show, instead of hardcoding values into every cue. So I started thinking if I could come up with a more elegant solution for my situation.
The elegant solution
The entire show has been programmed using recipes, and when I was thinking this problem through, tags were recently added into the MA3 software. I noticed that a Tag field was also added to the recipe lines I started wondering if I could bulk edit recipe lines that have a tag. And as basically any question about doing things in MA using commands, the answer was "of course!"
I ended up with the following syntax:
Set Sequence 1 Thru Cue 1 Thru Part Thru.Thru Property "enabled" 0 if #[Tag 'No Sides']
This disables any recipe line in any cue in any sequence as long as it has a certain tag. change the 0 for a 1 and it enables it. So I created a few tags ("No Sides", "No Floor Spots", "No Floor Washes", and so on), then went through the show, adding additional programming for these situations. Then I just had to create a couple of simple macros to toggle the recipe lines on and off, and I was left with an on-the-fly configurable showfile to adapt to wildly differing show scenarios.
Takeaways and other uses
Being able to mix and match multiple options also lets me make sure to still maximize what I'm doing with the parts of a rig that are there. Had I chosen to go with a "minimal" showfile, using it when I don't have washes on the floor would also mean losing any cool stuff I was doing with the side lights, or having to manually program it back.
This technique has saved me several hours per gig, most of which wouldn't have been paid either.
This trick can be very useful when you're not touring too. I've also started using the If Tag technique in my busking showfile. For example for enabling/disabling certain groups in my LOS-inspired system.