Audio Programming

I work in the game industry, and you will almost never see an audio programmer writing DSP. Typically an audio programmer is a gameplay programmer that provides tools and game system hooks for the audio team - knowledge beyond basic audio terminology(dB, reverb, etc.) isn't necessary.

Check out fmod:

http://www.fmod.org/

It's a good example of how games typically interface with audio. A lot of places have in-house tools, but for the most part, they all work similarly to fmod in that you are triggering off abstract events from gameplay code("collision" with material parameter "metal", "high" velocity, etc.) that fmod(or whatever) maps onto some logic the audio folks have set up to pick a sound/pitch.

Console developers are looking for engineers with extensive C++ experience. It is a long road to go down.

You may want to consider looking at web/mobile, but the audio engineering work there is going to be substantially less interesting.

You may consider becoming a technical designer with a focus on audio - technical designers use scripting language and in-house tools to implement gameplay features. Learning UDK(UnrealScript/UDK/etc.) or Unity would be a great place to start.

  On 1/17/2013 at 6:01 PM, Face Culler said:

You may consider becoming a technical designer with a focus on audio - technical designers use scripting language and in-house tools to implement gameplay features. Learning UDK(UnrealScript/UDK/etc.) or Unity would be a great place to start.

So what is a scripting language, and how does that differ from other programming languages?

A friend of mine is using Corona to code a game right now, which I'm doing the art/audio for, which is great for 2D, but I was thinking of using Unity when we want to make the jump to 3D.

The distinction is a bit vague because there are languages you could call a programming or scripting language like Python. But a scripting language generally has a large built in library and a loose syntax, often with dynamic typing, and is mostly interpreted so no explicit compilation is needed. You don't have to deal directly with memory and low level operations so it's much faster to create and maintain software. Your code will look much nicer because modern scripting languages have evolved their syntax and paradigms and most of the low level work has been abstracted away for you.

This obviously comes with a cost. Everything happens on the heap and there's overhead to everything you do so your software will take a lot more memory and CPU cycles. If you assign a string in Python 3 you'll create an object you can do a lot of operations on. You'll be able to search and replace, it supports multibyte characters, you can dynamically change the length and other stuff you'll quickly take for granted. If you create a character array in C you'll just get a memory pointer that points directly to a block of bytes ending by a \0 character. While extremely limited and prone to bugs because it's easy to mess something up, it's also extremely fast. For something like audio processing where you are working with raw audio streams and have to do a lot of time sensitive operations per second C(++) is certainly a good choice.

The need for that speed is why C++ is still the standard in the game industry for engine code. The high level stuff like the game logic is often done using a high level "scripting" language like Lua, C#, Python or even Javascript because that makes the high level stuff easier to build and maintain. You don't need to be close to the machine code for that.

unless you have a background in computer science youre probably beter off just sending tracks and hoping they get in a game.

  On 1/17/2013 at 10:26 PM, CharlesWatkins said:

unless you have a background in computer science youre probably beter off just sending tracks and hoping they get in a game.

Read the rules.

You don't need a background in CS to be a technical designer. Try making a really small game in Unity or UDK and see how you like it, and what parts interest you. Don't get discouraged by trying to jump in the deep end.

I decided I'm going to try to make a synthesizer or at least some oscillators using Python. I know it's not exactly an orthodox way of doing it, but there are a few things out there on it, so I figured I would give it a shot. Also, XCode will let you use Python, so I figured it was one way to get into the app making side of things.

A tutorial on generating audio with Python: http://bluehat.me/blog/2011/09/05/generate-audio-with-python/

Anyone have any similar experience?

Reviving this thread because lately I've been doing audio programming in Python to create sound editing tools. NumPy and SciPy offer pretty good signal processing functionalities that can be used relatively easily for audio programming also and I got pretty familiar with them in my previous job. Anyone else gone down this road? It's a bit hardcore and mathematical way to do audio stuff but you can create some interesting things.

  On 11/17/2021 at 9:49 PM, zkom said:

Reviving this thread because lately I've been doing audio programming in Python to create sound editing tools. NumPy and SciPy offer pretty good signal processing functionalities that can be used relatively easily for audio programming also and I got pretty familiar with them in my previous job. Anyone else gone down this road? It's a bit hardcore and mathematical way to do audio stuff but you can create some interesting things.

I have dabbled in this. Processing audio in Python seems interesting indeed and has endless possibilities but I haven't had enough free time to build anything substantial

  On 11/18/2021 at 6:27 PM, ghsotword said:

I have dabbled in this. Processing audio in Python seems interesting indeed and has endless possibilities but I haven't had enough free time to build anything substantial

NumPy and SciPy are really good for signal processing and they are quite fast, but I think there would be some problems if I tried to do anything in real-time. I think the main problem wouldn't be speed but the latency that comes from context switching between the optimized libraries and interpreted Python code. Anyway, for non-real time audio editing they seem perfect but maybe a bit overly technical as I mentioned.

I'm currently trying different ways of editing the audio spectrum. So far I've created a program that can turn melodic tracks into microtonal strangeness.. Here's an example

Interestingly Youtube's copyright algorithm can still recognize this. Wonder how much you need to scramble the spectrum to make it unrecognizable..

  On 11/17/2021 at 9:49 PM, zkom said:

Reviving this thread because lately I've been doing audio programming in Python to create sound editing tools. NumPy and SciPy offer pretty good signal processing functionalities that can be used relatively easily for audio programming also and I got pretty familiar with them in my previous job. Anyone else gone down this road? It's a bit hardcore and mathematical way to do audio stuff but you can create some interesting things.

nice. I used python a lot last year for uni

I imagine you've got librosa installed as well, yeah? https://librosa.org/

  On 11/18/2021 at 9:06 PM, IOS said:

nice. I used python a lot last year for uni

I imagine you've got librosa installed as well, yeah? https://librosa.org/

 

Actually no, because I haven't really taken too deep a dive into the python audio libraries I used to do RF-signal processing with SciPy so just went straight with that and then used pydub to load mp3s and turned them into NumPy arrays. But librosa looks very interesting now that I'm checking the white paper. Need to take a closer look. Thanks

YouTube's copyright algorithm didn't recognize this anymore..