Pinging @mars , I think I need some feedback on the following.
Looks like currently OwlProgram is able to process only stereo patches. I’m trying to make a new multi-channel alternative to SampleBuffer class that would be able to handle:
- more than 2 channel of audio (I guess something that Noctua would also need)
- data exchange with more than 1 codecs that won’t require copying their data into a single buffer in firmware.
The latter would mean that we will skip parts of audio stream to handle double buffering correctly. I will generalize this to using up to 4 codecs, since it would only require reserving an extra bit in in audio format descriptor. Something like this would be used:
#define AUDIO_FORMAT_24B16_2X 0x10
#define AUDIO_FORMAT_24B24_2X 0x18
#define AUDIO_FORMAT_24B32 0x20
#define AUDIO_FORMAT_24B32_2X 0x22
#define AUDIO_FORMAT_24B32_4X 0x24
#define AUDIO_FORMAT_24B32_8X 0x28
#define AUDIO_CODEC_DUAL 0x40
#define AUDIO_CODEC_TRIPLE 0x80
#define AUDIO_CODEC_QUAD 0xC0
/*
* This would work correctly only with 24B32* formats!
* Others have inconsistent channels mask.
*/
#define AUDIO_CHANNELS_MASK 0x0F
#define AUDIO_CODEC_MASK 0xC0
#define AUDIO_FORMAT_MASK 0x3F
#define AUDIO_CODECS(FORMAT) ((FORMAT & AUDIO_CODEC_MASK) >> 6)
#define AUDIO_FORMAT(FORMAT) (FORMAT & AUDIO_FORMAT_MASK)
#define AUDIO_CODEC_CHANNELS(FORMAT) (FORMAT & AUDIO_CHANNELS_MASK)
#define AUDIO_TOTAL_CHANNELS(FORMAT) (AUDIO_CODEC_CHANNELS(FORMAT) * AUDIO_CODECS(FORMAT))
Then the loop in PatchProgram would have to do something like this:
for(;;){
pv->programReady();
for (int i = 0; i < AUDIO_CODECS(pv->audio_format); i++)) {
samples->setStartChannel(i * AUDIO_CODEC_CHANNELS(pv->audio_format));
samples->split32(pv->audio_input, pv->audio_blocksize);
}
processor.setParameterValues(pv->parameters);
processor.patch->processAudio(*samples);
for (int i = 0; i < AUDIO_CODECS(pv->audio_format); i++)) {
samples->setStartChannel(i * AUDIO_CODEC_CHANNELS(pv->audio_format));
samples->comb32(pv->audio_output);
}
}
This shouldn’t affect older devices - they would still be processed as stereo by old SampleBuffer class. We could theoretically also use new code for 32bit stereo processing, but I don’t think there’s any reason to do it.
