Max RNBO - create modules for SSP?

[thetechnobear]

I thought I’d start a topic on this, as Im sure someone here will spot/raise it soon enough

RNBO Revealed

What is Max RNBO?

Max is a visual patching program that can be used by non-programmers for audio visual applications.
It’s a commercial application by Cycling 74, though students (iirc) can get it for free. It’s similar to pure data (though PD is free), but it’s a lot more polished, it’s actually pretty nice… very mature and highly respected.

RNBO (pronounced Rainbow) allows these max patches to be converted to VSTs / AU and other target platforms.

so the hope/dream is therefore non-programmers can create there own (e.g. VST) modules, or even run these patches on hardware like a raspberry PI.

cool - no?

How does this relate to the SSP?

well, the idea is pretty simple… how about using this to create modules for the SSP ?
Yup… this is an idea that Im actively investigating at the moment, and it does look interesting !

ok, its early stages, as rnbo has only just been released… and whilst theres alot of info/docs, its going to take a while to go thru and experiment with.

BUT, I do want to limit expectations a bit… before we get too excited

What’s my hope/plan?

What Id like to do is create a kind of ‘template’ that we will be able to plug a RNBO patch into, and then we can just compile and throw onto the SSP , and it’ll appear as a new module.
this is pretty much the ‘ideal’ scenario, and goal… and I want to get as close to this as possible.

Limitations / Expectations

(these may change as I discover more… both positive and negative !)

• No UI
  Im pretty sure, it’s not possible to generate any UI for the plugin.
  this is not really an issue… my current idea is to try to create some kind of standardised UI.
  whilst, also trying to allow custom UI to also be used… but you’ll need to know C++ to do this.

• VST source code is NOT exported
  this actually surprised me, but when you export rnbo patch to a vst3, it does not give you the code… it compiles the ‘vst’ on the cloud, so you only get a binary.
  this means it cannot be used with the SSP, since the linux target is not correct, and also cannot be modified. I suspect the rPI target is very similar.
  so we can only use the Source Code target (not a bit deal , but means more work!)

• Max is not free/commercial
  anyone that wants to do build their own modules will need a max license. its not ideal, but also not something that’ll stop me.
  (of course anyone can USE a module thats been built this way, see below)

also building on a 3rd party commercial product is not ideal either. so basically this’ll have to be ‘really good’ to be viable for me.

• Licensing
  I’ve had a quick look at generated code, the license for this code appears to be non-commercial only. i.e. you’d not be able to sell a module generated this way. however its usage is completely un-licensed.
  (ok, not strictly true, you’d have to apply for a license (fee?) from cycling 74)

• No custom targets (currently?)
  RNBO supports different targets (e.g. VST Mac, rPI, Source Code), whats cool is its integrated into Max… so a quick build/compile/test cycle - however, it does not appear to have any customisation in this area, so some of the process for the SSP will have to be ‘manual’. though I hope to try to minimise this.

Next Steps / Expectations

Im starting already to play with RNBO to see what’s possible, and figure out how Id integrate it with the SSP SDK and my ‘UI Framework’.

This is going to take some time, it’s far from trivial … and there are a lot of open questions.

also, upfront I should say, even if it works, I will be able to give limited support to those wanting to create modules… as development support is extremely time consuming.

BUT it is an exciting development…
as I said , Max is a great patching environment… so this could open up many possibilities

[thetechnobear]

ooh, quick update…

looks like Cycling74 have also released a template VST project , which I assume is what they use for the ‘cloud builds’.

put simply, however I approach this … the ideas is to create an ‘SSP template’ project, which you drop RNBO export coded into… then compile.

this vst project, whilst unlikely to be directly usable, may have some bits which are common to what I need to do… so might be a possible starting point.
that said, it may be overly complex to use anything from, but may still be able to answer some questions.

[thetechnobear]

an important question … How many are interested in this ?

if you are - what is your primary interest?

a) “I want to develop modules for the SSP”
if so , how likely are you to actually do this? (need a realistic answer here… if not a commitment )
remember: whilst the technical barrier will be lower (lets assume no C++ skills for now, just Max) , it will require you to invest a reasonable amount of time, to learn to patch, learn dip, create environment etc.

b) “It’ll make it easier for others to develop modules for the SSP”
this one is a bit double edged… unless we get many saying (a)… and following thru, otherwise ‘others’ = me- and if thats the case, then as I have the skills needed to create modules without this method, it becomes more a personal question of , do I want it or not.

as always, Im not committing to ‘future developments’, but it can be useful for me to understand what the communities feels…

[Handsonicsuki]

It’s awesome!
I’ll try to create a looper module with it. I tried to learn c++ to learn making vst at SSP, but c++ was a nightmare for me and gave up.
I have Max though I don’t use for several years and have a friend who have nice skill of it.
It’s really interesting for me.

[martinlanglie]

hi:)
to be able to port max-patches over to the ssp would be the ideal dream-solution for me!!
I`m currently trying to up my max-game and simultaneously learning the ssp and the thought of being able to port my patches over to the ssp is a huge motivator!!!
I dont know how the UI part would work, or any of the porting/shoehorning that i guess would be involved, but shit Id be interested to learn it!

[thetechnobear]

Ouch… just hit a roadblock…

I already own a full permanent Max 8 License, Id assumed RNBO was included (as the gen~ export was). However, it appears RNBO is being sold as an extra add-on…

and, since my Max license is permanent (not yearly/monthly) , I’d have to buy the RNBO perpetual license which is $299 + VAT (another 21% in Spain) … so thats 380 euros !

honestly, thats too rich for me, for something I don’t know how much Im really going to use once Ive got it up n’ running

the only way around, is for me to buy a (another) monthly license for MAX, so that I can add RNBO on a monthly sub too… that’d cost about 25 euros/month.
But Im not too keen on this, I cannot support something without owning it, so thats not really going to work.

Im going to try to approach Cycling 74 and see if they can offer license for open source projects (like mine for the SSP)… as in some ways its in their interests for me to support RNBO in my projects.
… but seems unlikely, but might offer a discount perhaps?!

[Handsonicsuki]

You can find something on ko-fi.
Of course, you don’t need to promiss the development.

[thetechnobear]

wow, are you sure? that’s really generous of you!

[Handsonicsuki]

Sure!
What you brought to the forum is already worth you receive it.

[jcn24]

100% absolutely interested in this. This would be a huge factor for me to play into really using the SSP more. I would soo love RNBO being used on the SSP!

[thetechnobear]

k, some solid good news…

I have the first RNBO module running on the SSP!!!

(k, obviously this is step 1… well step 3, but its not ‘finished’)

we have to thank @Handsonicsuki for their generosity for this.
as Ive mentioned before, often we just need a bit of motivation that anyone ‘cares’ to kick start things
so I spent much of yesterday, and a bit of time this morning on this… thanks to @Handsonicsuki.

anyway… so what exactly do we have here?

this is the rnbo demo patch provided by cycling 74… largely unchanged (see below)
I actually have 2 instances running on the SSP, to check for conflicts (none found), and performance seems to be ok.
the code is completely ‘generic’ i.e. no adaptations for this particular rnbo patch.
it’s being driven by cv/gate from cart, and as you can see we have a number of parameters.

this proves quite a few things

• cv and audio in/out between SSP modules
• usage of (basic) rnbo parameters, with names/ranges etc.
• it compiles/deploy successfully on ssp (and my Mac )
• uses same build environment as all my other ssp modules.
• so far seems stables, and performance looks fine.

its also the first step in understanding what rnbo will be like for development…

I said the patch was largely unchanged… in fact there were only 2 changes (all related)

• no midi → use cv
  the (main) demo patch uses midi to drive the synth… this is not useful for the SSP.
  so I changed this to use CV. this in turn meant changing the rnbo patch to accommodate.
  basically scale cv to the -5v / +5v used for v/oct.
• remove polyphony
  with one cv/gate in, we cannot have polyphony (unlike midi), so I removed

at first Ive no plans for adding midi or polyphony support.

also it appears currently rnbo does not support named input/outputs (only parameters)
this is a pain for the SSP , as these are are cv in/out … currently we just end up with in0-N , out 0-N
max does support naming in a comment, so perhaps this can change?

there are also a couple of bugs in rnbo… though in fairness this is version 1.0.1… so im sure they will fix, once we give feedback

where next?

exploratory tests like these are obviously great news…
but there is a lot of difference between these, and something I can release - a lot of edge cases, a lot of things I need to check.
also, as its a ‘developer release’, theres a lot of work to do on packaging so that others can use.

so lots more dev work for me to still do , but its a good start

[marcusfischer]

amazing! i’m definitely excited by this… especially just you using rnbo. I’m sure you’ll find uses for it even beyond the SSP

[Sonakinesis]

Yes, I too am interested in RNBO / Max and the possibility of developing more modules for the SSP. I do have Max7, which I assume I will have to upgrade to Max8 first. I’ll keep RNBO in mind, but I watch here to see how this turns out.
Thanks, Marc

[thetechnobear]

yeah, to build new modules with RNBO, you will need a Max 8 license and a RNBO license.
(its pretty expensive, though there are monthly subscriptions for those wanting to dip in n’ out)

however, if someone else creates a module (like me) using RNBO, then you dont need anything, it’ll be just like any other SSP module.

[BENDY]

this is amazing… potentially.
&e

Ps, look at all that dust! Glad your were able to haul your SSP out of storage…

[thetechnobear]

lol…
nah, I live in Southern Spain, which is very dry, very low humidity, so we have dust everywhere within minutes of dusting, and as Im doing dev, SSP is sitting on my office desk.

quite enjoying RNBO… the template seems to be basically done, just been doing some tweaks here n’ there. also got docs in place etc
but whilst, it’d be usable for users that can setup dev environments… but Im trying to think of an easier solution.

---

one idea is to compile on SSP - as we all have one
but the minimum image (built on buildroot) we have on the SSP makes that a bit tricky.
Id have to build not only all the build tools, but also a package manager…
also Im not sure of the practicality of this without users adding a network adapter (wifi/ethernet)
… though that addition,

other options are:

• VM
  but I really don’t want to start distributing large images… and is anyway problematic these days with different architectures in play. (32/64 bit , arm/intel)
• Raspberry PI.
  I keep coming back to this…these very cheap, and we could assume a particular distro to give a common platform to build on. and there is a lot of ‘support material’ out their for rPIs
  sure this has extra cost, its minimal compare to the Max/RNBO license required

But not sure yet… as all these routes, would take significant time for me to setup, and as I said from the beginning, Im pretty concerned about the ongoing support effort on this.
then the next issue is… 90% of the effort, even with a simple setupm will be getting the dev environment working, and then understanding the basics… i.e. to the point they compile and install the first ‘demo module’… unfortunately, me experience shows, the vast majority will never do much past that stage.

so my working assumption is … find a way that minimises the upfront cost, that is possible IF the user is willing to invest the time and effort themselves to work it out.
(you could argue, what I already have done will allow for this)
but, unfortunately, this likely wont work for the casual ‘lets give it a go’ user… however, in fairness, I suspect that users wouldn’t invest in both max/rnbo anyway…

however as I said… I really dont know… it’s still a bit up in the air.

in the meantime, I want to add a more positive benefit for RNBO… to make use of the (non unsubstantial) effort Ive already spent on RNBO.
so, Im going create a module (or two) that use RNBO… these can serve as real world examples, and test out the template, as well as being generally useful - and I can see, if RNBO has a place in my dev cycle.
so thats probably next…

[thetechnobear]

quick update… this is all proceeding nicely

as @Handsonicsuki provided me with the RNBO license, I gave them a preview of the the ‘template’.
they were able to get their own module up n’ running on the SSP…
so, that’s the first custom SSP module by a non-developer… quite an exciting development!

whilst doing this with @Handsonicsuki , we found a few ‘issues’ with my docs, related to running on an Intel Mac, and got those sorted… so thats really helped the testing process a lot !
thanks to @Handsonicsuki for being a guinea pig!

so thats nearly ready to go.

note: only supported on macOS and Linux…
(windows users will need to use a Linux VM)

---

Im also now building a more ‘significant’ new module based on this work, with a customised UI… and also some more complex sides of RNBO - not only exploring RNBO, but also how it might be used as a development workflow, for both prototyping, and potentially some released modules.
( the value of RNBO here, will depend on how fast testing the DSP is in RNBO, compared to be writing directly in C++… sometimes, it’ll be just as fast for me to go straight to C++)

I hope to have 2 examples to ‘release’
a) straight RNBO + Template module
the idea is something that shows what a non-developer can achieve, with just some basic RNBO skills - this will be the included example in template.
(so won’t be a release binary module… though I might later do a ‘customised’ version, if community is interested)

b) custom RNBO module
this will just use RNBO/Template to create the initial DSP, but will be fully customised, so its own UI and also additional dsp handling/processing.
the idea here is to demonstrate, you can write modules that you couldn’t tell initially started from RNBO.
(this will be in my main SSP project repo, so released as binary)

(a) I’ve not started on, but by definition, once Ive decided on what it’ll be, its very quick to put together.

(b) is in progress, a large part of its done (including UI), but Im still playing with some ‘features’ of RNBO to see if I can get the patch more to my liking.

the template (and possibly example (a)), I plan to put out (probably) next week…
it’ll be public, but I will initially give priority support to ko-fi supporters.

the more complex example… aka a new SSP module, probably will be around the same time.
that will be released as an EAP to ko-fi supporters.

[Handsonicsuki]

So far, I’ve only converted a few simple MAX-RNBO patches to SSP plug-ins, but those all worked in SSP without any problems.
This is a dream update for a non-programmer like me!
Once I have the development environment set up, I can then concentrate on using MAX-RNBO to create the processing I want to use in SSP.

Anyway, all I can say is wow! This is awesome!!!

[Handsonicsuki]

I converted Max’s example code of Jon Dattoro’s reverb with some patch modification to SSP’s plugin and it works fine.

I’m really looking forward to finishing my own plugin and getting it running on SSP!
And I’m interested to see what kind of plugins everyone will make in the future.

MAX RNBO - SSP

[thetechnobear]

cool… really, its good to see others being able to build things.

FX are a natural place to start, as they are nicely self contained, and often only need a few well chosen parameters… and of course, theres so much diversity in this area.

I’ll throw out a couple of ideas that I found inspirational when I first started…

delay (lines) are the heart of many fx (delay~)

you might be surprised about how many fx’s are basically delay lines… just a tiny bit of research on chorus/phasers etc will show you, how delays are much more than an echo and reverbs
the trick is… differing delays line times (try very short) , with feedback, filtering and modulation.
they are a natural place for ‘beginners’ to start

even I could spend months, just playing delay’s and create fx’s

which leads me, nicely, to a more generic idea…

get experimental

I think this is where RNBO excels… I learnt this best from the Critter & Guitari Organelle (and its community).
there’s (kind of) two ways to look at software…generic use-case, and specialise use-case.
generic - something everyone needs and loves.
specialist - something only a few (perhaps only you!) will need/love.
of course, we all need base tools, and it makes sense for developers to target the majority.

but covering the majority of use-cases, leaves a huge area untouched, as the ‘generic’ cannot the specialist use-cases into their model.

and this is where the Organelle community shined…
its quality is not always the best, but it has some the weirdest more interesting fx and synths out there.
so whilst you might not reach for it to get the best reverb, if you want something different/interesting its a hell of an instrument.
and this is possible because Pure Data that it uses is very accessible, so user build things for themselves , some thing specialised, so perhaps only a handful might ever use.

… and this is where I think RBNO on the SSP can shine with the community just ‘having a go’, just trying out ideas e.g. an FX that might only be useful for one type of patch, in one genre.

if we look at the hardware , I think we can see that hologram electronics have kind of been going this way. things like microcosm are a group of quite ‘specialised’ algorithms, and they only work for some use-cases… compared to a generic reverb pedal (e.g. big sky) - and microcosm was successful, because musicians like ‘different’.

of course, experimental doesn’t mean ‘easy’, you will have to kiss a lot of frogs to get your prince.
but many happy accidents can be had, and

anyway, just a few ideas (*) , that inspired me…

tl;dr; just experiment, its amazing what you can achieve just by throwing a few things into the mix…
experimentation lowers expectations, as you are not trying to reproduce something, be the best.
so its a lot of fun… and the more you do, the better you will become, the more ‘guided’ your experimentation will be.
… and this is where I think RNBO could excel for non-developers !

---

( * ) final tip… bare in mind the SSP processing power.
don’t go totally overboard, when testing on your PC, as it may be too hungry to run on the SSP.
however, also push it… sometimes its absolutely fine to have just ONE module running on the SSP.
it might be great to have a module where it leaves no cpu for other modules… wouldn’t make a great ‘generic’ module, but as specialist/experimental … thats fine! (*)
(in some ways you can view whilst its only a single module on the SSP, thats because the ‘multi module’ is within RNBO)
its balance, and once you have done a few patches you’ll get a feel for it.

(**) actually its a bit more complex here…we have 4 cores on the SSP, one core is reserved for UI /IO.
your module can only run on ONE core, so thats your ‘limit’ (as there is no multi core support in RNBO)
on the (positive) flip-side, this means two cores remain for modules.
(this is a bit simplified, so not quite true… but gives a general feel for whats going on)