Chosto Four stereo amplifiers configured by I2C and connected to analog outs ;
do you need to do any I2c configuration in real-time or only during setup?
Chosto For the first need, I think that OSC is suitable. However, in the linked example, polling is done in render(), which I can think cannot be done with realtime audio without glitchs (?).
That example is actually a bad example (because OSCServer
uses std::queue
, which is not thread-safe or real-time safe). I would encourage using the OSCReceiver
class instead, which is event-driven, more efficient and real-time safe. This can be found here and here, and will very soon be merged in the main Bela branch.
Chosto For the second need, successive activations could look like that. The only idea I can think of is to count time in render() thanks to sample rate / frame number but it seems a bit heavy
That is the way it's supposed to be when writing code in basic C++. PureData or supercollider could be better options if you want something more "expressive". Here is some code in C++ (untested) that should play a sound for the specified duration. This (should) works for one sound at a time, and you can extend it for your needs.
#include <Bela.h>
#include <OSCReceiver.h>
OSCReceiver oscReceiver;
int gTrigger;
void oscFunc(oscpkt::Message* msg)
{
if(message.match("/whatever")){
gTrigger = 1;
// do some more clever parsing in here)
}
}
bool setup(BelaContext*, void* userData)
{
oscReceiver.setup(7562, oscCallback);
}
int gSampleCount = 0;
int gStartSample = -1;
void render(BelaContext* context, void* userData)
{
for(unsigned int n = 0; n < context->audioFrames; ++n)
{
if(1 == gTrigger)
{
gStartSample = gSampleCount; // gStartSample keeps track of when the sound started, and is also a flag to determine whether we should be playing or not
gTrigger = 0;
}
if(0 < gStartSample) // the sound is on
{
if(gSampleCount - gStartSample > gDuration)
{
// .... do magic to play sound here ....
} else {
gStartSample = -1; // done playing, reset the flag
}
}
gSampleCount++;
}
}
Please understand that the timing accuracy of network messages cannot be guaranteed, so they may well be a few ms off (possibly more than 5ms, you'll have to test this with the CPU usage you are actually going to have).