Stereo/multichannel oscillator

[olofson]

trafficstars

Once we have rendered a multichannel set of waves (see #8 and #95), it would be nice to be able to play them in some sensible way.

We can always use one wtosc for each channel, and be done with it - and that, of course, gives us a lot of control, including stereo flanger effects and the like.

However, most of the time, we just want to play them back as rendered. It would also be nice to have some standard way of selecting a bundle of waves as one object, if we implement that. (See #95.) And of course, there are cycles to be saved here, as we can share some logic, interpolation calculations etc across channels.

[olofson]

Been thinking about whether or not there is a case for making stereo a "core" feature, or just an abstraction on one or more levels.

• We can probably assume that two channel stereo is such a commonly used format that it should be handled in a transparent and smooth manner, if not even being the default format, so it definitely needs explicit support.

• Maybe eventually this will extend to multichannel surround formats as well, but I don't think we're there yet, even when dealing with game audio meant to support surround output.

• An actual interleaved stereo audio format is pretty much only a performance hack, and comes at the cost of essentially doubling the size and/or complexity of any code that needs to touch it. With inlines and macro magic, that doesn't necessarily have much impact on the source code, but it may harm performance in cases where both mono and stereo paths are used concurrently.

• For both waveforms and buffers, interleaved stereo provides an advantage in cache coherency. This is probably more important for large waveforms that are essentially always streamed from cold RAM, but in "consumer" scenarios (>10 ms latency), it's quite likely that every audio callback starts with an entirely cold engine, in which case it might be an advantage if also internal buffers are interleaved stereo.