Arbitrary sized mixers

[Teik]

If like me and you're dealing with lots of simultaneous voices (eg synth project) you're probably a bit frustrated with AudioMixer4 having only 4 inputs. Then you'll have the large cascade of patchcords to stitch together to join everything up. Super messy code and inflexible. Well, I've templatized AudioMixer4 to create AudioMixerN (attached).

Just include that at the top of your sketch.

So, if I want a mixer for 64 sources then declare as follows for 64 voices:

AudioMixerN<64> mixerN;

you'll have to patch its output as usual to whatever. Then let's say I've got a bunch of wavetable generators:

AudioSynthWavetable wavetable[64];

and their patchcords (which will be dynamically allocated - you don't have to but you can):

AudioConnection *patchCords[NUM_VOICES];

Then initialisation in your setup() is simply:

for (int i = 0; i < 64; i++)
{
patchCords = new AudioConnection(wavetable, 0, mixerN, i);
mixerN.gain(i, 0.75);
}


enjoy! Happy for PJRC to add it to their libraries if this proves useful. I did bugger all work just munging the AudioMixer4 and templating it.

Teik

 

[MarkT]

I think once you go to wide mixing bus it would be great to have an output gain control too, and use 32 bit
internally. A clipping indicator would be great too.

 

[Teik]

It's basically what would happen if you concatenate a bunch of AudioMixer4 things albeit marginally faster as you don't have all the summing of mixers upon mixers. For "__ARM_ARCH_7EM__" which I think is Teensy 3.2 and above (I'm using a 4.0 so don't really think about this) the summations are done using floats. But the code is so trivial anybody should be able to add extra behaviours...

 

[PaulStoffregen]

and use 32 bit internally.

This is on my bucket list for the audio library (a very long list). If 3+ inputs are active, it's entirely possible 2 positive samples which might 16 bit clip when added together could have another negative sample added which fits the final result into 16 bits without clipping.

I've also been considering a non-linear "soft" clipping option.

A clipping indicator would be great too.

Thought about this too, but for the whole library using the ARM's DSP extension saturation flag.

So many ideas... never enough hours in every day....

 

[MarkT]

I've also been considering a non-linear "soft" clipping option.

It would be nice if that was a separate object for flexibility, but it would have to be used by the mixer where the
32 bit intermediate result is, so perhaps a plug-in to the mixer, perhaps just a function parameter, though it
would be nice for more advanced behaviour like clip detection or AGC.