Max RNBO template - user created modules

[thetechnobear]

@BabylonRising666

Im looking to buy an XMX very soon and the idea of making my own modules with rnbo is amazing and I’d love to be able to share with users on here, can you DM me? I’m curious about the price of a lesson in rnbo as I’d really love to start learning how to make modules to share with everyone

we can talk about this once I release this stuff … soon

not sure about lessons, Ive done this in the past.
but, the issue is, to be effective, it requires a certain amount of prep, e.g. thinking about how to teach the subject. and, if you charge that time to one person, plus time for lesson it becomes expensive.

programming is even worst, since how quickly others can pick it up, depends on skills/aptitude/previous experience…
so the chance of charging someone a few hundred $ and not making (quick) progress is a real concern

the best way, ofc, is to prep courses, and then spread over many people, but we just dont have the number of people to make that viable.

first two modules I’d like to make is a quad EG and quad lfo since theres only 8 modules allowed in the XMX patches

yeah, very simple implement.

that said…
OMOD probably covers the quad LFO case.
a multi EG could be useful, frankly, probably an AD would suffice.
(sure ADSR is useful, but you end up with lots of parameters!?)

---

as for only 8 modules… thats not true…

Synthor (percussa software), has a limit of 64 modules (iirc), the UI is 16 pages of 8 modules. which can be interconnected however you want.
(ofc, cpu/ram constraints exist)

TRAX has 8 modules per track, but has 4 tracks.
I chose this for a few reasons.

a) to be an ‘alternative’ from synthor
synthor’s ui is a traditional virtual modular, aiming at ultimate flexibility (patch anything to anything) - but that flexibility comes at a ‘cost’ to the ux when implemented in a small UI footprint.
b) UI simplicity !
you have 8 (main) buttons, so having 8 modules - meant the UI wouldn’t require lists/scrolling around - it provides ‘direct’ access.
c) cpu/ram concerns.
its very tempting to use complex modules, so whilst I could add lots of modules slots at no cost, would you be able to use them without running out of cpu/ram?

you can see a → b, b then helps choose how to address/limit c

so trax is something different… if anyone knows the “virtual modular” I implemented on the Organelle, Orac… you can see kind of what I was thinking… its can be an multi track synth/fx with a bit of modulation, rather than a build your own synth/fx like a full virtual modular (synthor)

[thetechnobear]

a new GitHub repo has been created that supports both XMX and SSP.

GitHub - TheTechnobear/PERCUSSA.RNBO: formerly rnbo.example.ssp

this is considered in BETA at present.
this will replace rnbo.example.ssp when this release moves from beta → stable.
the above documentation will be updated accordingly at that time.

I will keep rnbo.example.ssp around, since it will still work, but will not be supported going forward.

note: percussa.rnbo may need slight alterations to your build environment. also you will need to regenerate your modules. (using create_module script)

[thetechnobear]

I’ve updated the percussa.rnbo code to include my latest framework changes/support for xmx etc.

as Ive released my plugins now, I also consider this as released.

note: the ‘legacy’ release will continue to work, as its only dependent on SSP API.
so you may want to continue using, until something you need is included in the ‘release’ version.

at present, new features for this release are, support for

• XMX plugins
• Trax/ Dual plugin (on SSP)

basically, the new template has support for a ‘mini UI’ (half screen) on xmx and ssp.
there is also now a cross compile makefile for XMX

note: you will need a toolchain suitable for the xmx, as you do for ssp. however it is not the same (different processor etc)

[thetechnobear]

today, cycling 74 have announced RNBO 1.4.0

RNBO 1.4.0 Released - RNBO Forum | Cycling '74

a key feature of this (for me) is that there is now a ‘minimal export’ option, which makes the rnbo less dependent on platform features … even ‘bare metal’.

Ive been playing with this within their closed beta, and my plan is to move to using this.

from a users perspective (either plugin or user of the template) , I doubt it’ll make a huge difference, but its a nice change anyway.

[Handsonicsuki]

I’m still learning how to make VSTs by RNBO, but the more I play around with Percussa RNBO(legacy), the more I fall in love with SSP. LoL
Thank you so much @thetechnobear for creating it!

[thetechnobear]

yeah the cool thing about using RNBO is you can target so many different environments.
be that, running in Max, or in a DAW (via VST) , or things like the SSP or Daisy etc.

not only is this useful in itself, as most of us use DAWs etc as well as (eurorack) hardware,
but provides an easy way to test things.

the other side, is because its so simple to create new modules/vsts from a ‘user perspective’, you can use it to create highly specialised/niche modules. they dont need to be re-usable, rather you can create a module which is even for just for one patch… almost it is the patch.

… at this point, Synthor is almost just a container, its role is to host a single module, and then you just connect the cv/audio io to it (via INP/OUT) job done

this is why Im pretty keen to add rnbo midi support to the template, which would mean external control (via midi) without any more configuration.
(ok, you can kind of already do this with midi learn, but it’d be nice for note support etc)

[Handsonicsuki]

Is percussa.RNBO already released version? or it’s beta?
I’m still using legacy version. However, the RNBO with old version seems unstable and it’s might better to update to RNBO v1.3.4 that you tested at percussa.RNBO.

Anyway, legacy version of your template works perfectly without any problems!
My headache is RNBO crush so many times when I patching.

[thetechnobear]

yes, percussa.rnbo is released, so you can use that.

when you say, rnbo is unstable - Im guessing you mean the max/rnbo editor side, rather than my code. as you say legacy version. rnbo.example.ssp, works ok.

if so… I think rnbo.example.ssp (aka legacy) will work with 1.3.4.
so you might want to try that first (on principle of change at little as possible),
then if you have (compilation) issues with it, try percussa.rnbo?

if you do move to percussa.rnbo, and have any issues with it create a new topic and we can look into it.

as mentioned before,
Im looking into moving to rnbo 1.4.0 which supports ‘minimal exports’,

it might be best for you to stick with ‘legacy’ for now (assuming its ok with 1.3.4) then move to percussa.rnbo once that is released.
though honestly, it doesn’t really matter

[Handsonicsuki]

Thanks.

Yes, problem is max/rnbo editor side.

I don’t remember clearly but if my memory is correct, when I update RNBO version in the past, I had some problem at rnbo.example.ssp and chaged to old RNBO version again.

I’ll try again to confirm.

Looking forward to the RNBO 1.4.0 compatible version!

[thetechnobear]

yeah, no worries either way…
just raise another topic, if you have any issues with the percussa.rnbo.

[thetechnobear]

OK… so big update for this

Ive moved to using minimal export from RNBO 1.4.2 (should work in max 8 and 9, though I used 9).
this removes a lot of dependancies, so hopefully a bit leaner.

also whilst I was doing this I worked on a version of it for VCV/Metamodule, and in doing so improved the workflow by using python.

the workflow is very similar to that used in rnbo.example.ssp, but definitely read thru docs as there are some difference. (new scripts, and the export settings are a bit different)

whilst the RNBO VCV project is quite different in details (e.g. setup environment), the YouTube video it may be interesting to watch, and you’ll see some similarities so may be useful - that said, I guess differences might make it confusing?!

---

@Handsonicsuki
ok, so what Id recommend for you, when you have time…

a) keep your (legacy) rnbo.example.ssp project as-is.
as I said before, it’ll carry on working fine.

b) create a new project for this…
you already have everything installed that you need…
so from setup.md your already on step 4 !
for Step 4, you will just need to do setup SSP_BUILDROOT
something like:

export SSP_BUILDROOT="$HOME/buildroot/ssp/arm-rockchip-linux-gnueabihf_sdk-buildroot"

or (depending where you put this folder)

export SSP_BUILDROOT="$HOME/buildroot/arm-rockchip-linux-gnueabihf_sdk-buildroot"

then you can just continue, as detailed in Step 5 onwards.
it’ll build Demo plugin which you can test works, then your good to go.

Id then try copying over your RNBO patches (not the export!), re-export as described in creating modules

this’ll be a good test to check for compatibility, should be ok

anyway, no rush, you can continue to use legacy project, so this is just when you want to give it a go.

[Handsonicsuki]

Thanks for sharing the steps!
I’ll try setting up the new environment later.

[Handsonicsuki]

I started Development Environment setup and confirmed to complete Build of VST and .so for SSP on step 6 at setup.md.
Since I got XMX also, I try to add XMX’s Buildroot.
But at Step 2, it becomes AccessDenied when click following links.

XMX : aarch64-rockchip-linux-gnu_sdk-buildroot.tar.gz

[thetechnobear]

unfortunately, I don’t think its been released.
I just did a copy of the SSP url, and replaced with what it should be called, as a kind of ‘placeholder’

[Handsonicsuki]

Thanks.
In that case, I’ll proceed with creating modules for SSP.

[Handsonicsuki]

I tried creating modules but I couldn’t make modules correctly at this moment.

I created TEST at module folder by “python3 scripts/createModule.py TEST” and Build TEST module.
(Export C++ with minimal export from RNBO, Export Name =TEST.cpp.h, Codegne class name=TESTRnbo, MAX8, RNBO 1.4.2)
Then Error massage was occurred as follows.

Next, deleted TEST module folder and created DEMO module folder and export C++ to DEMO-rnbo and build.
That’s made DEMO.so with my EREV’s RNBO code.
When I use it on SSP, it works. However go into edit menu, it become reboot.

[Error at TEST]

[Success build at DEMO]

[Reboot at created DEMO.so]

- YouTube

[thetechnobear]

great… I think actually things are basically working… just a bit of confusion.

TEST issue

I think your issue with TEST, is that when you did the rnbo export, you must have used

Codegen Class Name :DEMORnbo

rather than : (correct usage for TEST module)

Codegen Class Name : TESTRnbo

OR

perhaps you forgot to set the Output directory correctly - this is very easy to do if you have a couple of modules.

( I did check the code, I cannot see an error)

I suggest, to avoid confusion we start from the beginning again :

python3 ./scripts/test/removeAll.py 

also remove any TEST.so, DEMO.so from your SSP.

as you have successfully built a module, we don’t need to use the demo, lets just move straight to your own module.

so, start again from Step 1 creating modules

use something other than TEST or DEMO…to avoid confusion.

just in case something, goes wrong, keep track (screenshots) of exactly what you enter for export in max, and also terminal commands you enter.

honestly, I think you did the right thing, just got a bit confused between DEMO and TEST at some point.

CRASH on SSP

ok, this is identical to the the issue with Synthor we saw before when I updated the plugins (in May/June).

if you remember, I had to release an unofficial ‘Synthor’ version to fix the crash when opening the UI.

so, as per this post, you must use the synthor, I distributed with my plugins.

please let me know if this doesn’t resolve the issue…

however, I will update both the documentation on this project, and also my plugin post.
so that its clear this ‘unofficial’ synthor must be used.

side note:

if at any time, you want to update to my latest version of the templates you can use:

git pull upstream

note: this is not necessary at this time, as Ive only updated the documentation. I could find no code change necessary.

edit: updated OP regarding updating templated, and when required etc.

[Handsonicsuki]

[Edit]
@thetechnobear
Probably, I found the root cause.
For exsample, made module folder CPPC by “python3 scripts/createModule.py”.
And checking PluginProcessor.cpp at Source, there is one location where the DEMORnbo description remains unchanged.
After revising this location, the build completed without issues.

[Handsonicsuki]

CRASH on SSP was because of synthor.
DEMO.so used my EREV’s RNBO code is working with unofficial synthor.

- YouTube

[thetechnobear]

100% correct - don’t know how I missed that !!!
(id give multiple likes if I could )

ok, Ive fixed it in the template, so if you do git pull upstream you will get the revised template

note:
IF you edited the template file (I don’t think you did?!) , then print to the pull above you will need to do …

git checkout template/module/Source/PluginProcessor.cpp

because pull will complain if it thinks you and I both edited the same file

but I dont think you did, looks like you just edited the generated file, which is fine

---

great news thats its working for you, if you have any issues let me know.

also if you have an XMX,
I can give you a copy of an unofficial build root sdk for xmx to try …
just I don’t want to release it publicly, as thats Bert’s call.

but id only want to let someone try it, if they can test on an xmx,
(and preferably that already has this project working)