Wtf is an API, anyway? – adamtcroft.com

Dear sound designers,

I know that not all of you are coders/programmers – so I want to do a good service to that segment of you today. After you read this post, you should be extremely excited and also way more willing to run up to your resident programmer (or myself) and not be afraid to ask for tools and help.

So today I’m going to explain this:

What the f*#! is an API, anyway, and why should I care?

(FYI, see this post and this post)

Why should you care about an API?

Let me answer this with a question – do you struggle with your sound design tools at all? Do you ever lament “if this only did X! I wouldn’t have to do this stupid workaround!” Do you ever wish you had an extension of your current tool that’s almost good enough, but not quite perfect?

Then you already care about APIs.

Ok, then WTF is an API anyway?

Imagine you built a sound library for use by everyone. Anyone can use your sounds at any time – everyone loves it and they’re all high-quality source and everything is great.

Then a few of your users ask for new sounds that could really help them out on their projects. But say you’re too busy recording and filing metadata for the current sounds in your library. Perhaps the sounds your users are asking for are difficult or expensive to get. Maybe they’re great ideas you’d love to grab, but logistically it just doesn’t make sense for you.

So you make a fateful decision one day to open up access to your sound library and allow others to contribute their own sounds. But, not wanting things to get out of hand, you set up some pretty specific rules. You only allow sounds of a certain quality, file type, size, channel count, loudness, etc.

That access, my friends, is analogous to an API.

Let’s get granular

I use the above example to compare sound design to software development.

If you re-read the example, put yourself in the title of “software developer” rather than “sound designer”. You create a tool, everyone can use it (or, you know, whoever buys it). But your users are asking for features and you logistically cannot provide them.

This is where an API comes in handy.

In this case, a software developer has an option to write an Application Program Interface which is essentially a set of rules and tools that other people can use to build on top of their existing tool.

In the example, it’s other sound designers being allowed to contribute sounds. You get access to new locations and other people’s time/microphones, and in turn, your users get the new sounds they want.

Why this matters in real life

I’m going to point you again at the upcoming Wwise Authoring API.

Using the above examples, the “existing tool” is Audiokinetic’s Wwise. The user is you, the sound designer. You now have the ability to clamor for a new Wwise feature, let’s say…

Direct control of Wwise mixing parameters in Unity or Unreal engines
Control of sound importing/event creation/file management directly from your DAW
Control of Wwise RTPCs from an external control surface like a Kaos Pad or an MPC

Normally Audiokinetic (or any other software developer) would look at these things and go “That sounds awesome! But… I don’t have and can’t commit the resources to that. Sorry :(”

But with the public availability of an API – you can go to your resident studio programmer, or freelance developers (like me – hi!) – and ask for features custom built for you.

You’re also going to see said custom features shared or sold online.

Crazy, right?

I hope that helps to explain why you should be flipping your lid in excitement. Now you can also ask developers of your other favorite software to create public APIs for their work too. You don’t even need to know how they work to get the tools you need, built!

If you find yourself getting ideas already or have questions, you know where to find me – @adamtcroft or me [at] adamtcroft.com