RNBO - Cycling 74 Max -> C++

I did some work today:

https://github.com/giuliomoro/rnbo.example.bela

Here's the latest guide, working quite nicely already: https://learn.bela.io/using-bela/languages/rnbo-experimental/

If anyone is trying this out we'd love some feedback on the process and documentation. We recommend running the projects with a block size 128.

thetechnobear though a bit surprised you didnt have RNBO.cpp in there?!)

It takes forever to build on Bela, so I went for a more canonical approach: build cpp files and link the objects together.

thetechnobear the difference, is its implying an order than cpp files are compiled, and I guess some dependancies.

I put some effort into disentangling that for the original release, raised it here https://github.com/Cycling74/rnbo.example.vcvrack/issues/1 but they may have not done anything about it. I was considering storing a patch in the repo to assist with updating rnbo, but I hoped they would fix it on their side. Note also this https://github.com/Cycling74/rnbo.example.vcvrack/issues/3

thetechnobear dont really like having libs under ~/Bela/projects but unclear where it would be better to place.

Maybe just in Bela/libraries? Not sure that handles subdirectories atm.

thetechnobear what would be nicer, is if we could tell bela NOT to compile sub-directories, or let us create our own makefiles for these circumstances?

There is something like that in place for heavy/ subfolders (dedicated to any hvcc custom render): https://github.com/BelaPlatform/Bela/blob/master/Makefile#L378. Unfortunately, you cannot easily add another subfolder to ignore from the command line without first modifying that line.

I am not sure the current workflow is the best, so I am happy to hear about options that are easily reproducible for the average user. Unfortunately, using Bela/libraries, which conveniently allows to set custom CPP flags and could avoid using run.sh requires a non-trivial setup step (i.e.: putting stuff into the Bela/libraries/rnbo).

thetechnobear forum has an unknown error when posting)

The shared server we are using conveniently likes to flag up harmless stuff as dangerous with ever changing rules.

imdara Does anyone have a code template/know how we could set up our RNBO parameters to work with I2C inputs?

sure, see what is being done here when BELA_RNBO_USE_TRILL is defined. I have no idea how to communicate with your specific sensor, but I am sure you can figure it out based on its documentation and example libraries.

Hey,

I´m trying to control a RNBO patch wich some sensor data:

first situation I encountered:

gAudioFramesPerAnalogFrame = context->audioFrames / context->analogFrames;

gAudioFramesPerAnalogFrame was 2 in the sensors patch without rnbo, having Analog Sample Rate set to 22050Hz. although its still set to 22050Hz in the render.cpp with rnbo, gAudioFramesPerAnalogFrame results in 1.
why that? is the Analog Sample Rate overwritten somewhere with 44.1?

and, in the rnbo documentation(https://learn.bela.io/using-bela/languages/rnbo/) is written:

For example parametersFromAnalog = {0, 1, 2, 3, 4, 5, 6, 7}; will directly map the Bela’s 8 analog inputs to the first 8 available parameters on the list

how to do it not directly? is it ok to just call

rnbo->setParameterValueNormalized( 2, 1.0);

when doing this like:

for ( unsigned int n = 0; n< nFrames; n++)
{
	frs_2 = analogRead(context, n, 5) * 100;
}
rt_printf( "frs_2: %f\n", frs_2);

the sensors behave very differnet in comparison to the non-rnbo-version.
I press the sensor, the value increases but then decreases slowly, while keeping the pressure constant.
does anybody have an explanation for that?

currently this is the way i can trigger samples, but the sensor values are still drifting downwards. and somehow i have noise on the left audio channel permanently

        // reading sensor values
	for ( unsigned int n = 0; n < nFrames; n++ )
	{
		frs_2 = analogRead(context, n, 5) * 100;
	}
	
	// playing audio in rnbo
	if ( frs_2 > 1.0 )
	{
		rnbo->setParameterValueNormalized( 2, 1.0);
	}
	else 
	{
		rnbo->setParameterValueNormalized( 2, 0.0);
	}
	rt_printf( "frs_2: %f\n", frs_2);

D300 why that? is the Analog Sample Rate overwritten somewhere with 44.1?

	settings->uniformSampleRate = 1;

makes it so that the analog sampling rate as seen by the program is changed to match the audio sample rate. This makes processing through rnbo simpler.

D300 how to do it not directly? is it ok to just call

rnbo->setParameterValueNormalized( 2, 1.0);

What do you mean "not" directly? That call should work for setting parameter 2 to the normalised value of 1.

D300 frs_2 = analogRead(context, n, 5) * 100;

In this program you need to use analogReadNI() instead of analogRead(). This is because of

	settings->interleave = 0;