Multiple instruments on Raspberry Pi?
Hi . .
I am just diving into RNBO and the connection to Raspberry Pi has been really intuitive to work with so far. I'm really excited about the prospect of not having to do everything in Pd for the Pi.
This might be obvious, but can you export multiple RNBO patches to a Raspberry Pi or does exporting only support on patch at a time? I currently have a Pi Synth with an LCD and options to select and load different Pd patches. It uses a Python script to handle the buttons and knobs on the Pi via OSC. That is working well with a loaded RNBO patch on the Pi.
Is there a way via Python and ultimately OSC to target different RNBO patches on the Pi? Use a button and the LCD to select different patches via Python-OSC messages. The OSC framework seems to suggest this with the /rnbo/inst/0/. Maybe /rnbo/inst/0 would be one patch and rnbo/inst/1 would be another? Or would I need to create one large patch with multiple instruments which is how the Pd patches work at the moment.
Regardless of my musings, what would be the most efficient way to do such a thing and is it possible? Thanks!
@Clay - Glad to hear you are digging in!
We don't currently have an interface for managing exports / multiple patches on the Pi, though it is something we would like to support at some point.
In the meantime, if you do need dynamic switching, I'd recommend just building all of your functionality into one rnbo~ patch, and using OSC to selectively enable/disable elements/routing/processing/etc.
OK. Thanks for the information. Good to know.
@BEN BRACKEN Is there a way to disabling audio processing for parts of an RNBO patch or a subpatcher? Something like the good old mute~ in Max?
I am curious about the mute~ or other ways to do this as well. Thanks!
It seems when the Pi is booted it automatically enables the last transferred patch which is good. I think it is reading the .cpp file in the /documents/rnbo/cache/src/ folder. Would it be possible via crontab and a startup script to tell the pi to choose a different .cpp file at start? (assuming that is what is happening - i don't know) I guess I'm curious about how the Pi interacts under the hood once a rnbo patch is transferred. And maybe what happens on boot. I think C74 is concerned with keeping the OSC connectivity, etc going with max on the originating computer and is keeping interaction on the Pi very simple which makes sense. I'm curious once patches are transferred over to the Pi and ready to go would it be possible to do something in regards to what is loaded on startup?
anyway, sorry to nitpick! this is all working well so far and has been pretty easy to figure out which says a lot about the work that went in to rnbo.
I had a quick look at this....
its not using the source code (I dont believe) , rather than source is compiled into a shared library.
which is then loaded by the "PI runner", which is what gets started by systemd at startup
we see 3 processes started, im not sure which loads the shared librar
python3 /usr/bin/rnbo-runner-panel --directory /usr/share/rnbo-runner-panel/www/
/usr/bin/rnbooscquery
/usr/bin/rnbo-update-servicethe python task, seems to just be the web front end
not sure what rnbo-update-service does (perhaps just update template from internet?)
however, only rnbooscquery is running as pi.. so the 'user', so I suspect this is the one that is the 'runner' and load the shared library.
(I could go check C74 source code, but this feels right)
as for what the runner, runs...
pi@c74rpi:~ $ ls -lR Documents/rnbo/
Documents/rnbo/:
total 12
drwxr-xr-x 4 pi audio 4096 Oct 31 21:47 cache
drwxr-xr-x 2 pi audio 4096 Oct 31 21:47 datafiles
drwxr-xr-x 2 pi audio 4096 Nov 6 13:16 saves
Documents/rnbo/cache:
total 8
drwxr-xr-x 2 pi audio 4096 Nov 6 13:44 so
drwxr-xr-x 2 pi audio 4096 Nov 12 14:46 src
Documents/rnbo/cache/so:
total 392
-rwxr-xr-x 1 pi audio 199212 Nov 6 13:15 libRNBORunnerSO1667736933.1.0.0.so
-rwxr-xr-x 1 pi audio 199212 Nov 6 13:44 libRNBORunnerSO1667738641.1.0.0.so
Documents/rnbo/cache/src:
total 512
-rw-r--r-- 1 pi audio 259878 Nov 6 13:15 rnbogen.1667736933.1.0.0.cpp
-rw-r--r-- 1 pi audio 259878 Nov 6 13:44 rnbogen.1667738641.1.0.0.cpp
Documents/rnbo/datafiles:
total 0
Documents/rnbo/saves:
total 52
-rw-r--r-- 1 pi audio 50768 Nov 6 13:44 last.jsonsee how the so name follows the cpp name...
the saves/last.json , contains the name of the last so thats been loaded, so thats how it knows on reboot what to load.
I guess theoretically, you could keep various versions of last.json , pointing to different patches.
copy these to last.json, then restart the rnbo services
rnbo-runner-panel.service
rnbo-update-service.service
rnbooscquery.servicethats all a bit of a hack in my mind though...
if I wanted to do this now (until C74 address this), what Id consider is...
a) writing your own runner in C++... this could load the same so thats been generated.
b) look to see if you can adapt the C74 runners to add the ability to switch.
I guess these two options are quite similar, just do you want to start with the existing c74 code or not.
Thanks @thetechnobear! Useful information. I might poke around with adapting the runners and see if something might be possible.