openframeworks/openFrameworks — pull request #2592 by admsyn (2013-09-29 16:16:02+00:00)
Title: New sound functionality (from YCAM)

This PR contains initial implementations of a few of the sound-related things in the openFrameworks 1.0 roadmap. Specifically, there's implementations for ofSoundBuffer, ofSoundFile, ofSoundObject and ofSoundMixer.

### ofSoundBuffer ###
Effectively a `vector`, with a bunch of helper functions that you might want to do on a `vector` of audio data. It's intended to be the standard way of passing audio around in openFrameworks, so ofSoundFile will give you ofSoundBuffers by decoding files, and ofSoundStream will request ofSoundBuffers instead of the more cumbersome `float *` and length which are passed around now. Basically, this is the ofPixels of sound, thereby closing #856 .

Implementation mostly by @damiannz, including extensive Doxygen documentation as well.

[ofSoundBuffer header is here](https://github.com/admsyn/openFrameworks/blob/feature-sound-ycam/libs/openFrameworks/sound/ofSoundBuffer.h)

### ofSoundFile ###
Point it at a file, it gives you a decoded ofSoundBuffer back. Wraps [libaudiodecoder](https://github.com/asantoni/libaudiodecoder) on OSX and Windows, and [libsndfile](http://www.mega-nerd.com/libsndfile/) on linux. Libaudiodecoder is basically a common interface to the codec support built in to OSX / Windows, so we get MP3 support + more ([see here](https://github.com/asantoni/libaudiodecoder#compatibility)).

Since file writing is a little hairy in terms of codec support and licensing, ofSoundFile currently just supports writing 16-bit WAV files, since it's pretty easy to just bang out the file format correctly. This is more-or-less a stopgap measure to give some file writing capability, but I'm definitely open to any suggestions on how to handle this better. This closes #2511.

[ofSoundFile header is here](https://github.com/admsyn/openFrameworks/blob/feature-sound-ycam/libs/openFrameworks/sound/ofSoundFile.h)

### ofSoundObject ###
A common interface a class can implement in order to pass sound around. There's 2 specific uses this is targeting:

1 - An easy object to inherit from in order to start playing with DSP
2 - A simple interface for addon writers to implement, which allows consistent interoperability between multiple sound addons in the same app

For example, a user could drop in a synthesizer addon, make their own quick subclass of ofSoundObject to add an effect, and then plug the output of that into the global sound stream. So you could things like:
```
addon -> my cool sound effect -> output
```
or
```
addon -> addon -> addon -> output
```
or
```
ofSoundPlayer -> my cool sound effect -> output
addon -> output
```
etc.

There's also a new example of this (soundObjectExample), courtesy @mazbox.

My game plan for this is to see if there's any feedback regarding crucial missing features, then to start bootstrapping the system by PR-ing ofSoundObject functionality into some of the sound addons that are already out there.

[ofSoundObject header is here](https://github.com/admsyn/openFrameworks/blob/feature-sound-ycam/libs/openFrameworks/sound/ofSoundObject.h)

### Other Stuff ###
- ofxSynth has been removed, since it's outdated and somewhat conflicts with the ofSoundObject API. This closes #861 as well. We should probably be steering people towards ofxMaxim if they're still using ofxSynth.
- `bool getLooping()` has been added to ofSoundPlayer, closing #1235
- all of the new stuff contains doxygen inline documentation as well

The work for this happened in two parts: part of it ~a year ago between arturo and damian, and the rest at the YCAM dev con between myself, @roymacdonald and @mazbox (and arturo).

Ping @arturoc @oftheo @ofzach @kylemcdonald

PS. I still have to add the changelog commit in here, but I'm assuming this won't be taken as-is, so I'll hold off until we've figured out what it is that's actually changing :)