A template is a promise you make to yourself. I had thirty-two tracks of one, built up over a year of small decisions, and a routine plugin update broke it on a Tuesday.
Not a crash. Worse in a way. The project opened, the vocal comped and sat exactly where I left it, and then I noticed the bus compressor on the drum group was bypassed with a little yellow notice I hadn’t seen before. The vocal reverb was loading a preset I never chose. Nobody warned me. The whole thing sounded a half-decibel flatter and I spent forty minutes chasing a problem that turned out to be a factory preset overwriting my saved state.
That’s the kind of morning that makes you suspicious of every update prompt. So this is what I actually do before I click install now, and what I check afterward when something has moved.
The update itself is rarely the enemy; the state file is
Plugin developers test that the new build runs. They can’t test your specific template, your specific automation, your specific clip of a half-good vocal you’ve been nursing for two days. The failures I’ve seen almost all live in the saved state: the preset you had loaded, the automation lane you drew, the sidechain routing you set up.
So the first thing I do before updating anything that’s in a project I care about is freeze the audio. Bounce the bus, not because I don’t trust the plugin, but because I want a reference sitting in a muted track. If the update changes the sound even slightly, I want to A/B it against a render, not against my memory of how it sounded at 2 in the morning last week.
That reference bounce is cheap. Ten minutes of export time. It has saved me twice now from a reverb tail that got a little longer and a compressor that got a little faster, both changes that would have slipped past me otherwise.
What to check before you hit install
I run through this list when a plugin sits in a live template. It’s short, and it’s mostly about making the rollback painless.
- Note the version number. Not the product name, the version. I keep a text file per machine with what’s installed. Without it I can’t tell you what I had before, which means I can’t reinstall it.
- Check the changelog for state and preset changes. Any line mentioning preset format, parameter mapping, or migration is a flag. New features are fine. Changes to how saved settings are read are what bites.
- Save a copy of the project with the old build. I keep a “before update” version of anything in progress. If the new build misreads the state, I still have the working file.
- Know where the previous installer lives. Most developers keep a couple of older builds on their site, some don’t. Find out before you commit, not after.
- Freeze the plugin host’s routing. Sidechain sends and grouping are the most fragile thing in a template. If the update resets an input assignment, that’s the kind of break that takes a while to spot.
The sidechain one matters most to me. I run a lot of buses with keyed compression, and a reset input is silent until you notice the kick isn’t ducking anything. By then you’ve mixed into it for twenty minutes.
After the update: the reference test
Open a copy of the project, not the original. Let the plugin reload. Then A/B against the bounce you made. I solo the reference and the live version in the same spot, match the loudness by ear, and listen for three things: the vocal sits the same, the low end holds its shape, and nothing has gained or lost a tail.
If any of that has moved, I don’t immediately blame the update. I check the saved preset first. More than half the time, the plugin loaded a default state because the preset name changed or the library path moved. That’s a five-minute fix, not a catastrophe.
If the preset is fine and the sound still moved, then the update changed something under the hood. That’s when the rollback list earns its keep. Reinstall the old build, reopen the project, confirm it sounds like the reference again, and then decide whether you actually need the new version. Sometimes you don’t.
When the update is worth keeping anyway
There’s a real question buried here, which is whether to update at all. My rule is simple: I update plugins that are stable in the template only when I have a reason. A bug fix for something I’ve hit, a feature I’ll use on the current project, or a security fix. Not because the number in the corner went up.
The counter-argument is that a stale plugin can become a liability. If a developer moves to a new framework or a new copy-protection scheme, the old build eventually stops activating, or the installer disappears from the developer’s own download page. That’s the same mechanical pressure that led Elektron to clamp down on community firmware mods on its forums; the company drew a line around distributing modified builds, calling out insufficiently tested firmware that can brick hardware and void warranty coverage. That’s a hardware example, but the instinct applies to software. Unsupported builds stop being safe eventually, and at some point the least risky option is the official current one.
So I don’t run old versions forever. I run them until I’ve tested the new one against a reference, and then I commit.
The template is not the only thing at risk
A plugin update can also move the session if it changes how the host reports latency. If the reported latency shifts, your timing shifts, and everything you tracked live against that plugin can feel slightly off. That’s rare, but when it happens it’s the most confusing kind of break because nothing sounds obviously wrong. The groove is just a little loose, and you blame yourself.
I check the reported latency of any plugin sitting on a monitored input after an update. It’s a boring thing to do. It takes thirty seconds. It has caught a problem once in about three years, which is enough to keep doing it.
The real lesson
The update didn’t break my template. My template was fragile, and the update exposed it. I’d built the thing on a stack of plugin defaults I never saved as my own presets, and a routing scheme I hadn’t documented, and a single project file I’d been treating as the master copy. All of that was a bet that nothing would ever change underneath me.
Since then I save my own preset for every plugin on a bus, name it with the project, and keep the reference bounce in the project itself. It’s slower to set up. But when the next update lands, and it will, I’ll know within two minutes whether it moved anything, and I’ll have a way back if it did.
Worth keeping in mind the next time your DAW pings you about an update while you’re mid-mix. The install is the easy part. The state file is what you’re really betting on.