Local control over RNBO with internal OSC msg raspberry pi
Hi
First I explain my setup, but you can already skip to #2 below for the main issue I have
With my FCB1010 midi floor unit I output PC values to my raspberry pi in order to change presets on my external digital mixer as well as PC changes to multiple synths. On top of this I am working with different presets on my RNBO granulator patcher and with different buffers in a sampler patcher. I can control all external devices with my different PC values connected to OSC outport messages and midi channel routings to keep it clean, yet I can not seem to find a way to target a preset load in a specific patcher..
I am using a separate patcher to centralize this 'preset control' and to make presets of presets. For example button 1 is triggering midi CH16 PC x, CH1 PC y and OSC /-snapshot/load z. This works! BUT for a 'RNBO patcher preset load' I tried the following:
#1 (easiest, but a general preset load) output midi PC from my preset patcher to rnbo-control instance to load (so I can configure the presets ( eg. PC1 = preset fast, PC2 = preset slow, PC3 = preset fast) // but can not do this because I rely on a initialize graph set and rnbo-control midi connections with patchers are not saved apparently.. // also this would make an all-patcher-preset change which can be messy and not a great workflow since i would need to copy presets around (would have max 10 different incoming PC values)
#2 (specific patcher preset load) /rnbo/inst/1/presets/load as outport on my preset patcher, prior with a 'listener add msg' setting localhost to listen to port 1234, also tried with port 5678. //but this does not work, and I also have issues finding information about this topic/rnbo structure
Any ideas how to make #2 work?
So, since I made an outport tag to work (/-snap/load x) without needing to cut the '/rnbo/inst/*/messages/out prefix'. It seems like RNBO did an update, since a developer mentioned that this did not work in 2022: https://cycling74.com/forums/send-osc-messages-out-of-rnbo#reply-638fb40da998630016c4629c, but while monitoring the outcoming OSC msg from RNBO it looks like it leaves the prefix when an outport msg starts with /rnbo/.. ?
print: /rnbo/inst/8/messages/out/rnbo/inst/1/presets/load 1
I would like to still locally send OSC messages to RNBO controls without needing to write python scripts for converting every single RNBO msg. Any help or light on this subject?
Maybe this had a reason that /rnbo/.. msg did not get 'de-prefixed' in a previous update? Or I am just overseeing something small in my configuration?
Another unclarity for me on the topic of presets, I see that there are 2 'load on startup' levels:
# when Graph Set select (not selected on power up), you have Preset 'initial' that auto-loads
# when power up you have a Patcher Preset function 'load on startup'
I would like to know if when I start up the rapsberry pi, if I can overwrite the params when they are saved differently on Preset 'initial' then on Patcher Preset 'load on startup' ?
Hi Ewoud,
Currently the RNBO runner doesn't let you map OSC messages to/from inport/outport that are in the /rnbo/ namespace.. so basically, you cannot orchestrate loading presets on one instance from another except via program change messages. I'll create a ticket to look back into this as I can definitely see the value in that.
RE 'load on startup' and 'initial'. Basically, graph presets take precedence, if you have an 'initial' graph preset for a graph set then it is loaded after you load that set. The 'load on startup' patcher preset setup lets you identify a preset to be loaded when you add an instance to the graph.
The currently released runner has a bit of a weird startup behavior, it tries to load the last graph state but doesn't actually load (or at least not always) the graph by name, so it doesn't have the associated 'initial' preset. This will be resolved in an upcoming runner release, we will allow you to explicitly specify a graph set that should load when you start the runner.
Back to your preset orchestration problem. I wonder, could you use "set presets" to resolve this? You can have a single node that has parameters that orchestrate the external PC messages you need to send, each of which would be held in a parameter and so stored in presets themselves, then the rest of the state for your internal parameters could also be stored in presets.. if you have some state that doesn't need to change between preset 1 and 2, that is okay, simply make the changes to the things that need to change and save a preset.
Thank you Alex for the reply!! Thanks for the ticket creating.
The Graph Setup load works every time I trigger it through a OSC comment, but at the moment my preset load 'initialize' does not work anymore...
Looking forward for a next rnbo update then!