This is the first in a new series of articles about our approach to plugin development, written by Baby Audio founder Caspar Bock.
I was recently writing back to a beta tester about a forthcoming plugin. He’d asked me why we chose to hide certain parameters under the hood instead of making them user-controllable – and that’s where the idea for this blog post came up.
We’re often asked about our approach to vst plugin development. We’ve also been asked why our blog is so rarely updated.
The purpose of this forthcoming series of posts is to address both issues!
OK, so back to the beta tester…
He was asking a very reasonable question: Why not give users access to certain parameters that are already in the plugin but hard-coded under the hood?
In coming up with an answer, I thought about the two classic ‘religions’ of personal computing, Mac vs PC. PCs were historically about interconnectivity, modularity and full user customization, whereas Macs had a curated and self-contained nature.
The Mac philosophy was to make systems that were close-ended and 'guardrailed', giving users a smaller space to operate within, but one that was thought-through from A-Z. You couldn't do as much on a Mac, but you also couldn't really screw things up. This suited some users as they could worry less about the tech and more about their actual work. Other users disliked the limitations and opted for the customizable nature of the PC.
Both schools have their pros and cons…
And on a personal level, I've never really been too devoted either way.
However, when it comes to making audio plugins, I've realized that we are more Mac than PC at Baby Audio. Not deliberately, but I can see it looking back (and forward) on our design decisions. We like the idea that you can abuse all the parameters in our products without seriously damaging your output. We like that our plugins offer a sonic experience that is curated and consistent regardless of what you throw at them. We think that intelligently planned guardrails can give the product experience a sense reliability and instil confidence in the user. (And who doesn’t want that from a plugin).
And that’s why we hide certain things…
Some parameters would change the sound too much. Others would clutter the interface and make the music production workflow less intuitive. We don’t want that. So we hard code these parameters under the hood, either statically or dynamically. Leaving the user with just enough flexibility to do something unique and personal but never so much that it overwhelms the creative process.
This will upset some and inspire others…
And that’s exactly how it should be!
Ultimately, the Mac vs PC rivalry benefitted both platforms. And if I look around at the audio plugin landscape, there’s plenty of options for every preference. Some rivalry between us developers is only interesting, and in fact I wonder if there could be even more of it sometimes?