ooh, thats interesting giuliomoro

yeah. Im currently using ranged values only, but I plan to support enumerated values....
the meta data is interesting, as I could use it for 'hints' to the user interface, e.g. digital values that could be used buttons.

I also need to see if I can get to the @comment meta data on the in~/out~ so I can label my cv io.

as you say, there is going to be a bit of a trade-off here, of users creating rnbo patches for 'any target' vs targeting specific that might use (optional) meta data.
in my case, Im not going too far with the UI... basically its generating a 'useful' generic UI, but you can always overload my UI, and create your own UI in C++.

theres a few other areas I need to dig into a little with RNBO... but a bit undecided on.
MIDI support.. really my focus is on CV, but I could add support for midi.
related (as cv is mono 🙂) - Im not currently implementing polyphony.. but if I add midi , could make sense to add polyphony as well.

another area is param~ which I think is sample accurate parameters... Im not quite sure where/if thats relevant for me... like you, I'm doing parameters at block level, which is the max 'norm' anyway.

    a month later

    Hi there! Quick question: will Trill sensors work with RNBO patches with this current template? I'm brand new to Bela and have yet to work with those sensors, but I know that they transmit over i2c, correct? Would they work with the analog/digital input process you're demonstrating here?

      13 days later

      a heads-up , I think rnbo 1.0.2 may have broken this...as getting compiler errors now

      Im looking into it at the moment.

      so far what Ive done is,
      replace rnbo subdirectory with new copy from 1.0.2 (patch)
      removed
      rm -rf LICENSE RNBO.cpp adapters test src/platforms/nostdlib

      ( I based this on what you were not using in your repo... though a bit surprised you didnt have RNBO.cpp in there?!)

      but bela is still not liking it ...

      In file rnbo/src/RNBO_DataRefList.cpp: unknown type name 'RNBO_PUSH_DISABLE_WARNINGS' column: 1, line: 12
In file /usr/bin/../lib/gcc/arm-linux-gnueabihf/6.3.0/../../../../include/c++/6.3.0/bits/algorithmfwd.h: expected unqualified-id column: 1, line: 42
In file rnbo/src/RNBO_DataRefList.cpp: unknown type name 'RNBO_POP_DISABLE_WARNINGS' column: 1, line: 14
In file rnbo/src/RNBO_DataRefList.cpp: expected unqualified-id column: 1, line: 16
In file rnbo/src/RNBO_DataRefList.cpp: unknown type name 'Json' column: 5, line: 22

      so digging in a bit to see whats going on.
      its a bit unclear why RNBO_PUSH_DISABLE_WARNINGS is not defined... as this is part of the stdlib refs.

      Im wondering if there is something odd going on with compiler versions...
      (Im using 3.8g on bela)

      gotta go walk dogs, but we continue digging after that

        ok, so the issue is you are compiling all the cpp files under rnbo..

        the idea generally is to actually just include RNBO.cpp into you project, and then that includes various .cpp files.

        the difference, is its implying an order than cpp files are compiled, and I guess some dependancies.
        (Ive no idea why they label them cpp, when clearly they are acting more like header files!)

        so what I did to fix was.

        move rnbo, to above the project folder.. so that its content is never compiled.

        then changed run.sh to include it from there
        e.g.
        -I\$(PROJECT_DIR)/../rnbo/common -I\$(PROJECT_DIR)/../rnbo

        (edit: odd, I dont seem to be able to include make command in code block , forum has an unknown error when posting)

        finally I copy RNBO.cpp into the project.

        so basically, we are doing as required...
        using RNBO.cpp to bring in the other cpp files, which are on the include path , thanks to run.sh

        Ive done something similar to this before with Bela...
        I dont really like having libs under ~/Bela/projects but unclear where it would be better to place.

        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?

        EDIT:
        ok, given restrictions, Ive decided what Im going to do is...

        place rnbo folder into ~/Bela/rnbo (so it'll be shared across projects)
        this means run.sh simply becomes

        CPPFLAGS="-I./rnbo/common -I./rnbo -DRNBO_USE_FLOAT32"

        then have my own rnbo.cpp, which just contains

        #include "RNBO.h"
#include "RNBO.cpp"

        this means, any time RNBO is updated, I simply copy the new generated rnbo folder to ~/Bela/rnbo, unchanged.

        so the template is basically just render.cpp + this simple rnbo.cpp

        and we just drop rnbo_source.cpp into the project.

        copying to ~/Bela/rnbo is not as nice as dropping into IDE... but feels like its going to be more future proof,
        as including RNBO.cpp is what C74 are 'expecting'

          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.

                    yeah. RNBO.cpp does take a long time to compile... but it's only done once, per project, as it doesn't change... so not too bad.

                    I did wonder about creating a bela library from the rnbo files...
                    but these appear to be build following a similar approach (no?) , where they just build every cpp file...
                    rather than allowing a custom makefile?
                    I could of course build a static library for this, but then thats something thats not just drag 'n drop for the average user... though perhaps thats not really an issues?!

                    subdirectories, yeah I was looking at the makefile, and saw the find files / heavy part...
                    I need to check to see if find could be altered to stop it search down certain paths.

                    I think ideal solution would be something like.
                    if there is a Makefile.inc file in a directory, then this is included instead of taking the CPP files.
                    (so its stops the find cpp)

                    most of the time, when I have had this in the past, and here with RNBO, what I want to do is quite simple
                    a) specify files I want to compile
                    b) add CPPFLAGS, often for defines.
                    Id say that covers 80-90%

                    I did wonder about just having it support additional makefiles/cmake ...
                    so as a separate build step...this is a bit more flexible, as you could then use it to build libraries, which then the main makefile (render) would just link.
                    but its a bit more involved, since you then don't inherit the bela 'make environment' e.g. compiler/link options.
                    ... not too problematic for experienced devs,
                    but for many the above makefile.inc solution would be easier, and probably cover most needs.

                    but yeah, I'll think about using the Bela/libraries approach, perhaps that would be neater?!

                    for now, Ive got it working with 1.02... and mainly wanted to give a heads-up, in case others tried and had issues.
                    Im currently creating a new render.cpp... one that uses the bela gui for parameters, and also one thats tailored a bit too Bela Salt specifics.

                    3 months later

                    Hello, thanks for making the RNBO repository and guide.

                    We have a chip (Sparkfun 9DoF Sensor Stick SEN-13944) that outputs i2c that we want our embedded RNBO code to read. We have our code setup to map analog inputs to our parameters as outlined here: https://learn.bela.io/using-bela/languages/rnbo/. However we want to map I2C input to our parameters, which is not covered in the Bela RNBO help website. Does anyone have a code template/know how we could set up our RNBO parameters to work with I2C inputs?

                    Thanks in advance!

                      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.

                        Hi! Thanks for the reply, I am somewhat new to this, but I think that I understand what is happening in the rnbo.example.bela/render.cpp file whenever the BELA_RNBO_USE_TRILL is defined. In the example code for my sensor, it has a read function that updates the variables gz, gx, and gy. In your rnbo.example.bela/render.cpp file you have certain variables such as trillLocation and trillSize. Forgive me if this is an uninformed question, but could I just import the code and libraries from my sensor example that fetches these variables, and then edit the render.cpp file to swap out each place these are called? Or will I have to do anything extra? (like if some of the code only works with input from trill sensors)

                          imdara Forgive me if this is an uninformed question, but could I just import the code and libraries from my sensor example that fetches these variables, and then edit the render.cpp file to swap out each place these are called? Or will I have to do anything extra? (like if some of the code only works with input from trill sensors)

                          You'll need to add your library code to the project, then initialise your global variables in setup(), do the reading of the I2C sensors in the loop() function and set the global variables from there. The global variables are then read those global variables in render() to pass them to rnbo via sendOnChange() or directly via rnbo->setParameterValueNormalized().

                            a month later

                            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;