Support for Cycling74 RNBO

Hello Rebeltech Team,

are there any plans to support the recently released RNBO code generator on the OWL platform?
To be able to create a patch, compile it and and pushing it to the device with only a few clicks would be a huge workflow improvement.

I bought a witch about a year ago, As much h as I like the concept of that device, it actually didn’t make it into my workflow a permanent setup, mainly because the whole process of creating a patch in gen, exporting the code, uploading it to my account, compiling it pushing it to the device is just a time killer.

mor often then not I discover that some aspects of the patch do not behave or sound identical to the gen~ patch, I just haven’t thought about some aspects, made a mistake or I hit some performance bottlenecks and so the whole long chains has to be executed again.

If this this process could be streamlined I happily would give it another try to incorporate it into my daily workflow. It seems like Bela Board and and Electro-Smith daisy platforms are already working on that…

Cheers,

Jan

1 Like

I am also interested in this topic.

Personally, i can see how it can be painful and knowing that the boss @mars is very busy now, i don’t want this to sound in any way offensive.

The fact is that Rebel Owl stuff is way more opensource than anything cycling '74 does. I think martin’s goal was always to get the community more involved in understanding how to flex the framework to our own unique needs. We don’t need special licenses or software, we just use what we can and in the end learn C++ that can benefit our careers without introducing the complexities of navigating licenses.

Cycling has a TINY userbase that even knows what gen~ is. In the grand scheme of this universe of sound engineers, the maxmsp userbase is quite small. So imo it doesn’t make sense to spend tons of time to rewrite gen~ support or add RNBO support if @Befaco won’t put some resources behind it and that there is a sure increasing in the OWL/LICH etc community growing significantly.

I feel the ethos of befaco and owl, is way more aligned with actual C++ programming or at least PD - since those things are free and depend on user skill and time to accomplish pretty much the same stuff gen users can after paying for a license, reading docs, taking a class, and pushing a few buttons to compile. No offense. Also knowing Befaco and Owl are programmers and electronics experts, they aren’t tied to specific hardware - while stuff like electrosmith daisy and RNBO is.

My hope is of course its JUST a 2 line magic sleepy keystroke from Martin or master @antisvin but it is probably beyond that. I know that a very big man in the Cycling community, Graham Wakefield is working with Electrosmith to further their creative platform but I have a feeling that it has slowed down in terms of evolution. Perhaps suffering from the same issues as Rebel Owl. It seems its 1-3 people maximum that are programming everything with very little return.

My main problem is why are they not getting more attention from media or the PD and Gen~ communities in the first place. Is it too difficult? Is the quality control too loose and there are tons of pitfalls? I guess i would attest to that since I am a power user and find a bunch of stuff annoying but I am too uneducated to do everything myself, so i need the tools and tool path to be almost perfect. So yeah I am gravitating to easy solutions like using Gen~ on Lich or now RNBO.

Another gripe I have with all this stuff is that in the end, everyone is using up their precious health and time to do this stuff and they want to be compensated. Piss easy maxmsp and gen~ things are being sold for 5-14 bucks. I’ve no idea about C and PD but maybe its the same. Just because this person paid 400 bucks for a license and spend 1 month reading documentation and finding examples to copy paste and improve on - they will put up a paywall. So the MaxMsp community is super weird and closed in some ways, but there are very bright, usually aligned with Cycling '74 individuals that push the whole concept along.

RNBO seems like a really strong statement from Cycling to all the makers and all the newcomers so I really do hope that @mars and @antisvin and @Befaco find interest in it. I’ll do what I can with connections but it also sometimes doesn’t work out - since Cycling 74 doesn’t really have infinite resources either and they just launched something that runs on the most accessible platforms.
Ironically…raspberry pis are unobtanium now.

Maybe it is the time to QUICKLY brainstorm for owl and befaco and to seriously consider maybe this the correct wave to jump on and surf into a more fun future for all.

It’s as easy or slightly easier to support that compared to gen~, so if you have a lot of interest you can try making a test patch and we can experiment with converting it to an OWL patch manually. I’m not too excited myself due to its proprietary nature (can’t even run it on Linux), but don’t mind helping. Their C++ example looks similar to gen~. It’s hard to say if it would end up usable right now or will require some changes in RNBO because they haven’t supported any embedded targets yet.

I’m sure that Martin will get this to work eventually and I think he was aware that this would be available way before the news became public as he’s got some contacts with one of Cycling’74 devs.

1 Like

Thank you for sharing all your thoughts @undefined.
I share a lot of your points of view. In my main profession I am an artists and musician and teacher and also a part-time developer (not really in C/C++ though - very basic knowledge there). So I do find myself in a spot, of endorsing the open source Idea and contributing wherever I can on the one side. On the other side after: a day of coding and coming to the studio working on an installation or some movie sound tracks I find myself often already exhausted of coding and the state of mind that it puts me in. So having tools like max/gen/RNBO that give me the possibility and flexibility to apply my tech-part to the creations and also having a tech support that I can contact, when running into problems, instead of digging into code again is the place where I ended up.
certainly not free of contradictions, I am aware about that. But is life ever free of those?

@antisvin This is a very generous offer! I am saving up for a license and as soon as I have one I can provide test exports. Ideally (in my dreams) it would be something that runs similar like the RaspberryPi integration that Cycling is already supporting: that the OWL devices show up directly as an export target in Max (similar like a connected Pi or a VST export).

Don’t they offer a monthly subscription option for $10 or something like that? Probably worth paying for a month or two before splashing out on full license.

Currently there is no subscription option. The demo mode though is unlimited in functionality but saving is disabled. My current testing/exploring I do this way. Compiling to Max-Objects and VTS3 works really well. What I have seen so far points very much for me into the direction of buying the full license though. My next tests will be building for the RasPi.

They would gladly take your subscription money here: RNBO | Shop | Cycling '74

But if C++ export works for demo mode, this would be good enough for trying to get it running with OWL.

what king of example would you need to start with?

I will gladly send it to them as soon as I have it :slight_smile:

and I also would gladly pay rebeltech and befaco for a good integration. I do value the work that goes into those projects a lot!

I’d say C++ export for a simple oscillator with tuning controlled by a parameter should be good enough as a starting point.

I will prepare something tonight or latest tomorrow. What would be the best way to send it to you?

Uploading a ZIP archive to this topic would be fine

nice @antisvin . Hopefully this is interesting.
It is a simple RNBO saw oscillator with a param assigned. Threw in the maxmsp patch too.
Super simple.

saw_osc_rnbo.zip (402.4 KB)

Some words from cycling on RNBO and more platforms (2 separate links to different responses)

Ok, I’ve taken a closer look and it’s obvious that it won’t work on baremetal. Not really surprising as they’ve mentioned that this would be the case in the forum thread linked in previous message. The problem is that they have a multi-threaded DSP engine that can only work on desktop OS. I think that for now we’ll have to wait for an RNBO update that would make it usable on OWL, Daisy, Teensy, etc.

Deleting anything related to threading in their code may be one possible way to get it working, not sure if that would be sufficient or there could be more issues.

I’ll wait for what @mars has to say about this for now. If necessary, here’s a branch where I’ve tried building it as a static library

nice to know. I saw BELA peeps have a beta but I’ve no idea what bela is and if its some sort of rpi thing.
RNBO - Cycling 74 Max → C++ - Bela

(read some stuff) - so Bela is a hat for Beagle Bone which runs linux.
ontop of that Martin already made a eurorack synth with them it seems. So guess hes been there done that.

Yes, Bela runs Linux (with realtime hypervisor for ultra low latency, unlike RPi), that’s why it’s possible.

I am definitely no expert in this. Though to me it sounds like due to the platform requirements being so different, it’s probably not worth all the effort in relation to possible gains. My imagination was to probably be able to export an effect or instrument as a vst for example for studio productions and also pushing the algorithm with little changes to the witch for life performances. By being so different in requirements it probably wouldn’t be such a difference to continue developing the core functionality in gen~ and then creating the vst from this using RNBO.
How do you all see it?

Well you could still do it, just the core part would need to be in gen~ and then for vsts, web, Rpi, etc you would just build an RNBO patch with that gen~ patch at the core.

yes that what I was thinking as well - but then probably the differences in results due to single-thread vs multi-thread might be something to always keep in mind probably. I do not depend on the CV in and outputs. It’s great to have them, but for me not a must. Next step I will run some tests using the Raspi directly as the sound processor. (buts that’s off topic :wink: )