Plans to support RNBO

[TheTenOfSwords]

Any plans to support RNBO on the Daisy? Seems like a match made in heaven. Yeah, ~gen is great but RNBO bring a whole new level of awesome.

[tunagenes]

I think the question to Cycling74 is whether they plan to support Daisy on RNBO.

[Wizard]

Sounds like those of us who are interested need to start requesting this feature from Cycling74. I’ve been on the fence about moving to Daisy for Eurorack, but if RBNO happened it would become a no brainer.

[shylayers]

I agree that this would be a game changer. I asked about this on IG, they said “we’ll be looking into it for future updates”. ¯|(ツ)/¯

[shensley]

Hiya! Just wanted to chime in with our thoughts here at Electrosmith

RNBO is super exciting, and seems like it may have a very promising future with hardware platforms like Daisy.

The compiled export currently supports a limited number of pre-built targets (plugin formats, and Raspberry Pi).
However, the C++ code export could potentially already be used within a Daisy project.
We haven’t looked into what kind of integration this would take, but we don’t have any immediate plans to develop anything specific at this time.

Based on the latest from Cycling74’s support page, there is a bit about bare-metal support (without access to the c++ standard library):

It may be possible to run without the C++ standard library support for more restricted “bare metal” hardware platforms, but currently it will require manual tweaking of the exported code, and is not an officially supported feature. We hope to improve RNBO C++ code export support for “bare metal” platforms over time.

If it’s something you’re interested in seeing supported, definitely continue to make that clear to Cycling74, and we’ll keep our eyes and ears out as RNBO matures.

[antisvin]

Somehow it doesn’t say anywhere that it’s written to run in a multi-threaded environment. Their Engine class has mutexes and concurrent queues and whatnot, making it impossible to run it as is on embedded environment. That class also includes what looks like a reference counting garbage collector for patch data. There is a base class (EngineCore) that doesn’t have those restriction, but it only provides part of functionality.

So yes, we’ll have to wait for some sort of official baremetal support. It’s a commercial product, they show some interest in expanding the supported platforms list and I don’t think anyone else would be writing a new RNBO engine implementation for fun.

[Garret_Pablo]

Any news concerning a possible integration with the RNBO Plattform?

[tunagenes]

I haven’t heard anything from Cycling74, and they would have to add the support.

Plugdata fills the same role, with some limitations:

Plugdata - new PD environment that can flash straight to Daisy

Yesterday we released plugdata v0.6.3 which has integration with heavy/hvcc → Release v0.6.3 · plugdata-team/plugdata · GitHub Plugdata is a new interface and user experience for pure data, that can also run as a plugin. It includes a Compiled mode that will warn you when you use incompatible objects. After which you can retrieve the compiler toolchain for your platform (about 1.5GB) and then either export just C++ code, flash a Daisy device or output plugins created with DPF. We have includ…

[asavartsov]

Just got my Daisy seed and played with it for one evening. RNBO thing doesn’t look that bad. Looks like it works just fine in single-threaded context if you add shims for stuff that target compiler is missing. They even have an RNBO_SIMPLEENGINE flag to choose thread unsafe engine. No need to touch generated code (I wish they updated their third party libs to versions that don’t use exceptions though, -fexceptions adds around 20kB to binary).

Compiled code doesn’t fit into FLASH, but should be fine for SRAM (~130kB for simple stuff with the seed board). Audio IO working just fine (just need to switch to float buffer instead of default double, tried it with vibrato example from “RNBO Pedal Collection”). MIDI a little bit tricky because you need to keep buffers from overflow, but should be doable either with buffers or using event handlers. But I just touched it, never had experience either with Daisy or RNBO.

Here is an example project for seed with simple oscillator in gen~ inside RNBO patch. I am pretty sure something like this can be turned into library and even have support for switching between patchers like oopsy: if you define RNBO_NO_PATCHERFACTORY you will have access to individual patch factories.

As it targets SRAM, need to do make program-boot first and then make program-dfu while seed’s led is “breathing”. It will output sweeping frequency from 50Hz to 1kHz (frequency set via RNBO param) and led will blink indicating that some MIDI messages are coming from RNBO midiout.

All magic happens in Makefile (-D flags), compat dir and main.cpp. All other stuff autogenerated, libDaisy is expected in parent directory. Very dumb and rudimentary example just to prove that this thing can work without Linux or RTOS.

https://github.com/asavartsov/daisy-rnbo-poc

[tele_player]

Welcome to Daisy Forum!!
That is very impressive for one evening! Many would still be struggling with getting the tools installed!

[tunagenes]

Hey! I resemble that remark!

[Takumi_Ogata]

Welcome!
And thank you for exploring this possibility and sharing your findings so far! This is super exciting!!
I have been meaning to try out RNBO for a while now.

[asavartsov]

Thanks all! And after digging a little deep into it it turned out that you don’t need those shims at all

With -DRNBO_SIMPLEENGINE flag you don’t need to compile RNBO_Engine.cpp and RNBO_ParameterInterfaceAsync.cpp. It will use so-called core engine and sync event processing that don’t use threads or mutexes at all. I don’t see any significant features it lacks from regular one. Only external data buffers will need to be set to patcher directly instead of using core object. I updated example project on GitHub, also added some rudimentary memory management to allocate buffers in SDRAM (RNBO depends heavily on dynamic allocation, also buffers can be resized etc. so I think ideally you would like to have couple memory pools to choose from based on allocation size or if it is external file ref you can have a convention that if dataref name ends with “fast” than the main thread will try to allocate in fast memory pool first or something like that).

[tunagenes]

Here is an interesting development on the RNBO front:

RNBO Export support for the Eventide H9000

Eventide H9000 adds Cycling ’74 RNBO patch import, a door opener for new...

[dreamer]

Cycling74 has now created their own proof-of-concept integration of RNBO with Daisy: GitHub - Cycling74/rnbo.example.daisy: Example of how to use RNBO code on the Daisy Audio Platform

It requires access to a beta version of RNBO (nothing about requiring a license though, so you may need to be a paying customer to use this).

And while this integration code is MIT licensed, the generated output by RNBO is definitely not: https://support.cycling74.com/hc/en-us/articles/10730031661587-Cycling-74-License-for-Max-Generated-Code-for-Export

[Manysounds]

Ok this is amazing but what I don’t understand is how naming conventions are resolved through RNBO. How are the names used to port to the hardware implemented in the RNBO object’s I/O? Using Oopsy~ as a reference.
Typing bad, I hope you understand.