Updating parameter values when using OSC

JoelBird

I'm trying to get an OLED display to update what it's showing based on the value of a potentiometer (in this case, showing the location of panned audio). I'm struggling to figure out how to send the pot value to the display function in O2O-main. Below is the main project:

#include <Bela.h>
#include <libraries/Scope/Scope.h>
#include "u8g2/U8g2LinuxI2C.h"
#include <libraries/OscSender/OscSender.h>

// Analog inputs
float gPot1;

// Bela oscilloscope
Scope gScope;

int gAudioFramesPerAnalogFrame = 0;

float amplitudeLeft;
float amplitudeRight;
float value = 0;

void sendToDisplayBackground(void *);

OscSender gOscSender;
size_t gRefreshSamples;
constexpr size_t kColumns = 128; // number of columns on your display
float gDisplayData[kColumns];
size_t gDisplayPtr = 0;
AuxiliaryTask gSendToDisplayTask;

//void sendToDisplay(void*) {
    //gOscSender.newMessage("/parameters");
    //for(size_t n = 0; n < kColumns; ++n) {
        // the value in the buffer was between -1 and 1. Here we make it between 0 and 1
        //float value = gDisplayData[n];
        //gOscSender.add(value);
    //}
    //gOscSender.send();
//}

void sendToDisplay(float value) {
    gOscSender.newMessage("/panner");
    gOscSender.add(value);
    gOscSender.send();
}

bool setup(BelaContext *context, void *userData)
{
	// calculate no. audio frames per analog frame
	if(context->analogFrames)
		gAudioFramesPerAnalogFrame = context->audioFrames / context->analogFrames;
		
	// Initialise the oscilloscope
	gScope.setup(4, context->audioSampleRate);
	
	gRefreshSamples = context->audioSampleRate  * 0.05; // 50ms refresh rate
    gOscSender.setup(7562);
    gSendToDisplayTask = Bela_createAuxiliaryTask(sendToDisplayBackground, 1, "sendToDisplay");
    
	return true;
}

void sendToDisplayBackground(void *){
	sendToDisplay(value);
}

void render(BelaContext *context, void *userData)
{
    for(unsigned int n = 0; n < context->audioFrames; n++) {
    	
		// read analog inputs and update amplitudes
		gPot1 = analogRead(context, n/gAudioFramesPerAnalogFrame, 0);
		amplitudeLeft = map(gPot1, 0, 0.824, 1, 0);
		amplitudeRight = map(gPot1, 0, 0.824, 0, 1);
		
		// read input
        float in = 0.5*audioRead(context, n, 0) + 0.5*audioRead(context, n, 1);
        
        // pan audio
        float outLeft = amplitudeLeft*in;
        float outRight = amplitudeRight*in;
    	audioWrite(context, n, 0, outLeft);
    	audioWrite(context, n, 1, outRight);
    	
    	gScope.log(amplitudeLeft, amplitudeRight, outLeft, outRight);
    	
    	value = amplitudeLeft;
		Bela_scheduleAuxiliaryTask(gSendToDisplayTask);
	}
}

void cleanup(BelaContext *context, void *userData)
{

}

And here is the "panner" function within parseMessage in O2O:

else if (msg.match("/panner")){
		if(!args.popFloat(param1Value).isOkNoMoreArgs())
			error = kWrongArguments;
		else {
			printf("received /panner\n");
			u8g2.drawCircle(displayWidth*param1Value, displayHeight*0.5, 10, U8G2_DRAW_ALL);
		}
	}

In this current form, the audio panning works as expected, but the circle on the display seems to have a mind of its own, mostly staying to one side of the screen and sometimes moving to the other and jittering about. It's also worth noting that running the panner project uses a surprisingly high amount of the Bela's CPU (~50%, whereas before I tried to include the display stuff it was more like 15-20%), and Error while sending to pipe from OscSndrTsk_127.0.0.17562: (12) Cannot allocate memory (size: 16) appears repeatedly in the IDE's console.
Any help that anyone can offer would be greatly appreciated.

giuliomoro

Your sending thread is running too often, in fact it's running probably 44100/16, i.e.: 2756 times per second. This has a few side effects:

CPU usage of the Bela process skyrockets
the pipe used to pass data from gOscSender.send() to yet another thread gets flooded with messages faster than these can be sent out to the socket, which causes the " Cannot allocate memory" error you see. This also causes some messages getting dropped.
on the receiving end (O2O), you'll be receiving a lot of messages per second. A bit less than 2756 because some get lost in the Pipe (see previous point), but still many more than you can actually send to the display. I think a reasonable refresh rate is under 20 fps. This causes a new pileup and potentially lost messages in the O2O process.

All in all, you have a big pileup of messages and lost messages, which is what's causing increased CPU time on both ends and glitchy display.

Solutions:

check out the only-latest branch of O2O , reapply your changes for handling /panner, rebuild the program, that makes sure no pileup happens on the O2O side as all older messages are discarded when a new one arrives.
the above by itself won't solve any of the issues (CPU and full pipe) you are seeing on the sending program. There, you should simply send data more often. There is no point in sending more data than the frame rate and even more sending 100x the frame rate as you are doing now. You should call Bela_scheduleAuxiliaryTask much more sparingly, let's say 30 times per second. This way, you'll be sending at most 30 messages per second. These may be a few more than the display can handle, but the O2O branch mentioned above will avoid a pileup so you'll have "max" frame rate, no delay, no loss of relevant messages and only moderate CPU overhead.

To send more sparingly, try something like this in your loop:

    static size_t count = 0;
    count++;
    if(count >= 1500) { // 1500 samples at 44100Hz is 29.4 fps
        count = 0;
        Bela_scheduleAuxiliaryTask(gSendToDisplayTask);
    }

Btw, you don't need to #include "u8g2/U8g2LinuxI2C.h" in this program.

giuliomoro

@JoelBird I just updated the OscSender library. If you get the latest dev branch for the Bela (see instructions here), then use gOscSender.sendNonRt() instead of gOscSender.send() and save even more CPU time.

JoelBird

Just tried your suggested fix with only sending at the same rate as the screen's refresh, and that works much better, so thank you very much. The only problem now is that the animation on the display lags behind the actual input by a second or so. I'm not sure if this could be fixed by your other suggestions or by improving my own code, but I'll try doing both and will report back here if I figure it out.

JoelBird

JoelBird Okay never mind, turns out simply targeting a lower frame rate was the fix lol.

giuliomoro

JoelBird f this could be fixed by your other suggestions or by improving my own code,

So the deal is: with the main branch of O2O, you will get a pileup of incoming messages and consequent delay if you are sending them at a higher rate than the refresh rate, so you have to send messages slower than the frame rate. This means you may not reach the maximum frame rate because you have to conservatively aim below it/

With the only-latest branch, you will avoid the pileup and consequent delay, so you can send slightly higher than the frame rate and not have any delays and achieve the maximum frame rate.

I should mention that another good thing to do would be to avoid sending messages if the value hasn't changed as this would avoid repeatedly sending identical data to the display and in turn save further CPU.

JoelBird

Slightly unrelated to the display, I've been getting these errors when running the panner:

Warning: -A/--adc-level is deprecated and IGNORED. Use --audio-input-gain instead
Warning: --pga-gain-left is deprecated. Use --audio-input-gain instead
Warning: --pga-gain-right is deprecated. Use --audio-input-gain instead

They don't seem to be causing any issues regarding the actual effect, but I'd still prefer if they weren't present.

giuliomoro

JoelBird Slightly unrelated to the display, I've been getting these errors when running the panner:

you can do rm projects/PROJECTNAME/settings.json in the console at the bottom of the IDE (after replacing PROJECTNAME with the name of the project) and then refresh the IDE page and they should go away. This will also forget any custom settings you may have in your project, so if that's undesirable there is a less destructive way that I can tell explain in detail if needed.

JoelBird

giuliomoro I see, I'll give that a go tomorrow. If it doesn't pan out (ba-dum tss) I've got it working well enough at 15-20 fps.

JoelBird

giuliomoro The only custom settings should be the analog inputs being sampled at 44.1 kHz, which I can live without. Thanks for all your help!