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!
2 Likes
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)
2 Likes
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.
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
1 Like
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!
2 Likes
yeah, no worries either way…
just raise another topic, if you have any issues with the percussa.rnbo.
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.
1 Like
Thanks for sharing the steps!
I’ll try setting up the new environment later.
1 Like
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.
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’
1 Like
Thanks.
In that case, I’ll proceed with creating modules for SSP.
1 Like
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]
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.
1 Like
[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.
2 Likes
CRASH on SSP was because of synthor.
DEMO.so used my EREV’s RNBO code is working with unofficial synthor.
2 Likes
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)
2 Likes
Yes, I want to try whether I can build module for XMX.
Please DM me if you can share unofficial build root sdk for XMX.
About new Environment for SSP, not issue but I have several questions.
1. Rename input / outputs
It seems like the method is different from the previous one.
I would be happy if you could add new RNBO tips n tricks for this later.
2.How to modify “@ thetechnobear” in module?
Every my build modules become your module!! 
I thought I can change it if I wrote something in author.
But after made module using "python3 scripts/createModule.py VERB --name “My Reverb” --description “Lush reverb effect” --author “Your Name”
“@ thetechnobear” is still exsting.
How can I modify it?
3. About Configure environment variables at setup.md
The following steps are in Setup.md.
#Add these to your shell config file (.zshrc, .bashrc, etc.)
export SSP_BUILDROOT="$HOME/buildroot/ssp/arm-rockchip-linux-gnueabihf_sdk-buildroot"
After build my module, close terminal and run terminal again, and process “python3 scripts/check.py”, I find following warning and cannot build the module.
So, I do export command every time before build.
Do I have to do the export command every time? Or is it just not being saved it to the config file because I’m doing something wrong in my procedure?
I don’t really understand what this “export” is doing.
1 Like
ok, Ive updated …
a) use BRAND for title ( manufacturer name)
b) improved the template code so its easier see how to add custom IO names
c) create module documentation explains how to add custom IO names
d) addDemo and createModule next steps show one line build command in line with documentation.
you have to do this every time
OR… you can add this to your .zshrc file, so its remembered
mine looks like this
export SSP_BUILDROOT=~/xc/ssp/arm-rockchip-linux-gnueabihf_sdk-buildroot
export XMX_BUILDROOT=~/xc/xmx/aarch64-rockchip-linux-gnu_sdk-buildroot
you can see what its using during build…
kodiak@ardilla Percussa.Rnbo % cmake --fresh -B build,ssp -DCMAKE_BUILD_TYPE=Release -DCMAKE_TOOLCHAIN_FILE=./xcSSP.cmake && cmake --build build.ssp
using TOOLSROOT : /opt/homebrew/opt/llvm/bin
using BUILDROOT : /Users/kodiak/xc/ssp/arm-rockchip-linux-gnueabihf_sdk-buildroot
BUILDROOT is the important line, it be useful to see what you have …
so SSP_BUILDROOT and XMX_BUILDROOT are (highly) recommended approach.
however, Ive just added some more logic be a bit more forgiving.
if the above are missing it will also look for
# SSP
~/buildroot/arm-rockchip-linux-gnueabihf_sdk-buildroot
# XMX
~/buildroot/aarch64-rockchip-linux-gnu_sdk-buildroot
also (unsupported ) , you can use an variable for BUILDROOT.
# SSP
${BUILDROOT)/arm-rockchip-linux-gnueabihf_sdk-buildroot
# XMX
${BUILDROOT)/aarch64-rockchip-linux-gnu_sdk-buildroot
I’d not advise these, because as you can see, its easy to get mixed up with which is ssp (arm32), and xmx(arm64)…
Im not quite sure what you has setup previously…
but if you didn’t have BUILDROOT setup previously, then looking at your screenshot, you’ll probably just be able to throw the xmx sdk into ~/buildroot, and it’ll work.
XMX Buildroot , Ive uploaded to my dropbox, you can get here …
this is an unofficial ‘release’, provided as-is.
It should be ok, as Ive used it to build my plugins, which others are using
IF it doesn’t work, then I don’t really have a solution - Id have to remove it.
then you’d have to wait for Bert to do an official release based off his xmx build.
let me know how you get on, I tested the XMX (obviously), but its been a while… not sure if I changed anything since.
I could build XMX’s plugin using unofficial XMX Buildroot!!
And I could change In/Out name.
Thank you for putting the procedure of rename IN/Out.
About the title for plugin, I may have made a mistake somewhere in the procedure, but at XMX plugin, I couldn’t change title.
I made module folder using “python3 scripts/createModule.py” and added Handsonicsuki at Brand and Author as follows.
And create VST3, SSP plugin, and XMX plugin.
XMX plugin’s title is still @ thetechnobear though SSP plugin and VST3 are correct title.
I’m not quite sure about the export part of your answer since I don’t know much about zsh, so I’ll look into it a bit more.
wow cool… its rare to see an xmx in action - and seeing it with custom modules 
… didn’t know anyone else, had both xmx and ssp - awesome.
brand - sorry, fixed that… forgot, Id give the xmx has a different base class.
compile again, and you should be fine
exports, don’t worry, if its works for you as is.
1 Like