Woe recorded two songs a few weeks ago. They’re planned for release later this year, medium TBD. Like the last album but unlike the two before that, it was not recorded and will be mixed elsewhere, which makes its chances of sounding good significantly higher than if I had been completely in charge and the likelihood of emerging with some sanity greater still. It’s cool.

Something that’s not cool is how primitive aspects of the modern digital recording process still feel. It’s not like I had any illusions about this – I still read about things and record my own demos, so I haven’t completely given up – but I became hyperaware of it as we started this mix process and talked about ways to collaborate on some additional tracks and work. It got me thinking about how so many collaboration and communication problems could be solved by tools and processes that are popular in the software development world. Here are a few.

PROBLEM: Version control of mixes

In my current workflow, I include the current date in a project’s filename and I never clean files unassociated with a project until I’m completely done editing. It’s a bit of a drag, since those filenames don’t include details about what changed or why, they’re just dates, which are sort of useful, but not really. It’s even worse when I’m writing over the course of days or weeks or even months, since I’ll invariably clean my project’s unassociated files, breaking old versions in the process. It’d be so great if I could keep track of a project and its audio dependencies as well as log distinct changes.

SOLUTION: Git LFS?

Git Large File Storage, or Git LFS, might do the trick. It’s like git, only for large files. Go figure. I have no idea how well it works, nor do I have an answer for how the audio world should handle things like merging branches, but for basic versioning, hanging onto audio dependencies, as well as having a places for notes about changes, this could be cool.

PROBLEM: Plugin Dependency Management

I’ve switched computers a few times over the years and I don’t always reinstall all the same software. This is especially true for my plugins, which I had a habit of buying greedily and forgetting after a mix or two. It’s rare that I need to open an old project, but without fail, if a few years have passed, I’ll get an error about missing plugins. It would be amazing if there was a single file that contained a list of all the plugins used in a project, the vendors who created them, and the last versions encountered at the time that the file was saved.

SOLUTION: Bundler/NPM/Cargo/etc for Recording?

This is something that so many languages have solved. Ruby has Bundler, JavaScript has npm, Rust has Cargo. (Incidentally, Cargo was built with involvement Yehuda Katz, who also worked on Bundler. Yarn, an alternative to npm that I really like, is another project that benefits from his involvement.) In each case, there’s an aspect that might be somewhat difficult for the recording world, a central repository of open-source libraries from which the depedency manager can draw, but I’d settle for just a list of what I need, how much of it is missing, and where I can get it. Baby steps.

PROBLEM: Shared Projects, Unshared Plugins

This one kills me. I’m working on a project and I want to send it to my friend to help with the mix or contribute some extra tracks, but I can’t because I’m using a bunch of plugins they don’t have. Even if we have the same DAW (let’s not even get into the fact that there isn’t a universal project format…), it’s going to be hard to share without coordinating very carefully. I know this is one of the reasons that UAD and Waves plugins are popular, but for the rest of us, it sucks.

SOLUTION: https://en.wikipedia.org/wiki/Adapter_pattern

The Adapter Pattern is a coding practice in which we create a trustworthy interface for something foreign and unreliable. It would work like this:

I open my DAW and I insert a generic reverb wrapper plugin. The reverb wrapper asks me to choose my reverb, so I choose some Nebula nonsense. I tell the wrapper, “this nebula variable is input, this one is output, this is wet level, this is dry level, this is delay time,” etc,… After that, I control my plugin entirely through the wrapper, not through Nebula. As I work, the wrapper keeps a record of the average output level, which will be important later. The next week, I send my project to my friend. She doesn’t have Nebula, but that’s ok because the wrapper will say, “Feed me a reverb. It must have a distinct input, output, wet, dry, and delay time.” She chooses some other plugin that satisfies those requirements. Because the project has been keeping track of the average output level, it does its best to tune her plugin’s settings to match mine. We’re obviously going to have different results, but it should at least get us started and allow us to communicate, which is better than where we are now.

There are a lot of problems with this. There are so few plugins whose settings would sync up nicely, I could see it being really frustrating. But maybe not. Or maybe some basic qualities would map over, maybe you’d have the shared settings and dial the rest to taste. Maybe something something machine learning could help find the settings in plugin B that are sonically closest to those of plugin A. I dunno, I’m just a guy who complains about technology.

I doubt that any of these will ever be explored, other than me maybe starting to use Git LFS to track versions of songs. They’re still fun to think about. As technology advances and we find better ways of sharing information, I’m confident that we’ll solve all of these problems in ways that are far more appropriate for the audio engineering world. Until then, it’s fun to daydream.