Jan M

I tried to figure out where on the Raspberry Pi are the presets stored and if/how the stored parameter values are accessible?

The preset parameter values don't seem to be readable via OSC by now, only the name and indices.

In may case it would be useful for two things:

The only way I currently found is to attach an OSC listener, load a preset and parsing all param values that are send after loading separately and create a preset JSON file.

Is there a way that is more straight forward?

synchronising the param values with external controllers when a new preset is loaded to avoid jumps and/or enable value pickup on knobs/faders

backing up presets that were created on the Raspberry Pi after exporting the RNBO patch (and possibly to implement a preset export/import  feature)

I tried to figure out where on the Raspberry Pi are the presets stored and if/how the stored parameter values are accessible?
The preset ... 

rnbo-where-are-presets-parameter-values-stored-on-raspberry-pi

The preset info is saved in: ~/Documents/rnbo/saves/last.json

You can edit that file "at your own risk" but you'll have to restart the runner to get it to reload it. You can use `sudo service rnbooscquery restart` to restart.

Do I understand correctly that you want an OSC endpoint that loads a preset by index? I'll add a feature request for that. In the mean time, MIDI program changes do that same thing but it looks like the OSC midi endpoint doesn't route through that behavior so, you'd have to create a MIDI connection between your controller software and the OSC runner.

I hadn't thought about migrating presets between patcher exports, that seems useful though a bit complicated as far as the UI goes. I'm in the middle of putting together some next steps for the oscquery runner, including managing multiple patchers by name. The idea is that you could export "My Synth" and then later export "Granulator Effect" and then later load "My Synth" without re-exporting. I wonder, in this context, maybe we could (optionally) automatically try to migrate presets if you export a new patcher named "My Synth" and there is already one on your device? Do you think you'd want to be able to access the preset data directly via OSCQuery to create your own export/import in addition to that?

Hey JAN,
The preset info is saved in: ~/Documents/rnbo/saves/last.json

You can edit that file "at your own risk" but you'll have to restart the runner to get it to reload it. You can use `sudo service rnbooscquery restart` to restart.


thank you for sharing your thoughts and your process.

I was under the impression that this was already possible. If not, yes that would be a useful feature.

Regarding the preset parameter values. I will share a bit what I am working on and why I thought it you'd be useful to be able to export/import them and/ore to access them via an OSC endpoint. Maybe a better solution will occur to us.

I am working on a synth in RNBO that is running on an Raspi. So frequently i make a build and start testing it on the real hardware. This includes playing it, stress testing and so on. It happens that while i do this I modify a preset on the Raspi or create new ones that I like.

When now I detect a flaw (maybe I realised that I'd like to change an envelope curve, or I improve some param value smoothing) and I created an updated version of the RNBO patch I lose the work that I did on the Raspi and fall back to the presets I created inside Max. Currently the only way to recreate them is to write down every single parameter value and then rebuilding presets after deploying the the updated version.

To be able to automate that process, would help a lot. It doesn't have to be a UI based solution, if they are e.g. stored in a json file that I can backup and copy back that would already help a lot.

Another scenario (in the future) are live gigs. I imagine, when the synth is done, and I worked with it for a while, there will be new presets added in rehearsals and in the process of preparing a show. Whenever possible I like to have my gear backed up. E.g. I usually travel to a gig with a second laptop, that is identical to the main one so if something goes wrong last minute I can simply switch gear and don't have to go error hunting. That does not happen happen very often, but it happens and it already saved some gigs in the past.

To the latter scenario the solution I had in mind is do and exact image copy of the Raspi SD card for the backup device. That should work though it's a bit a lot of steps for just synchronising presets between two Raspis running the same patch.

The other aspect, the one I was talking about in the first post is: Having an OSC endpoint that contains all the stored parameter values of a preset would make it easier to configure a hardware controller, and or writing a short script so that values don't jump but are picked up, when the knob of the controller is at different position than the current parameter value inside the patch.

That could be something like this for example:

"FULL_PATH": "/rnbo/inst/0/presets/entries",

"60 freq" : {"param_foo" : { "value": 123, "normalised" : 0.3}, "bar_param" : {...}},

"1200 freq" : {"param_foo" : { "value": 0, "normalised" : 0.}, "bar_param" : {...}},

"DESCRIPTION": "A list of presets that can be loaded"

thank you for sharing your thoughts and your process. 

Do I understand correctly that you want an OSC endpoint that loads a preset by index?


The other aspect, the one I was talking about in the first post is: Having an OSC endpoint that contains all the stored parameter values of a preset would make it easier to configure a hardware controller, and or writing a short script so that values don't jump but are picked up, when the knob of the controller is at different position than the current parameter value inside the patch.

That could be something like this  for example:

"presets": {
              "FULL_PATH": "/rnbo/inst/0/presets",
              "CONTENTS": {
                "entries": {
                  "FULL_PATH": "/rnbo/inst/0/presets/entries",
                  "TYPE": "sss",
                  "VALUE": [
                    { 
                       "60 freq" : {"param_foo" : { "value": 123, "normalised" : 0.3}, "bar_param"  : {...}},
                      "1200 freq" : {"param_foo" : { "value": 0, "normalised" : 0.}, "bar_param"  : {...}},
                  ],
                  "ACCESS": 1,
                  "CLIPMODE": "none",
                  "EXTENDED_TYPE": "list",
                  "DESCRIPTION": "A list of presets that can be loaded"
                },

And being able to manage multiple patchers would wonderful! +1 for this feature.

Would it be a reasonable approach to be able to give patcher on a Raspi a unique ID based probably on the [rnbo~] object in Max? Maybe the scripting name/varname of the [rnbo~] object. If the this unique ID matches an already exiting export on the Raspi there could be an option "preserve remote presets". Just thinking out loud...

right now an idea came up: 
Would it be a reasonable approach to be able to give patcher on a Raspi a unique ID based probably on the [rnbo~] object in Max? Maybe the scripting name/varname of the [rnbo~] object. If the this unique ID matches an already exiting export on the Raspi there could be an option "preserve remote presets". Just thinking out loud...

I think your idea about the unique ID works well.. in fact, I believe we already have a unique id associated with each rnbo~ object.

I'll add this "preserve remote presets" option to the feature requests.

RE Backup.. pulling out the SD card and copying it is pretty simple. You can save your self some time by getting SD cards that aren't super large, though you want to make sure it is big enough for the content that you intend to put on it.

RE the jumping after loading a preset and then moving a knob. I believe you should already have what you need via the parameter endpoints? You can query the values for your parameters and optionally not send updates until you get within some distance of the new value sent via a preset?

Jan,
I think your idea about the unique ID works well.. in fact, I believe we already have a unique id associated with each rnbo~ object.
I'll add this "preserve remote presets" option to the feature requests.

RE the jumping after loading a preset and then moving a knob. I believe you should already have what you need via the parameter endpoints? You can query the values for your parameters and optionally not send updates until you get within some distance of the new value sent via a preset?


You are right, the already exiting options for Backup and querying the current param values are already sufficient. A "preserve remote presets" indeed would be great to have eventually! Thanks for all the work Alex!

Jan, maybe a silly question : you mention creating a new preset directly on the rPi. Can you do that from inside the rnbo code? Is there an exemple somewhere in the documentation? I guess you would have to do that with Python - outside of the rnbo runner, right? (Or maybe I misunderstood and you mean presets created with your PC connected?)

currently I am using the Browser/OSC interface to create and modify presets. Later down the road I plan to create a hardware controller to directly access the parameters and save presets using the OSC endpoints on the RNBO runner so I can skip a laptop to control the patch and and use the Pi as a standalone (screen-free) device.

Hi Jean-Francois,
currently I am using the Browser/OSC interface to create and modify presets. Later down the road I plan to create a hardware controller to directly access the parameters and save presets using the OSC endpoints on the RNBO runner so I can skip a laptop to control the patch and and use the Pi as a standalone (screen-free) device.
 

For sure, we would like to be able to send an OSC command to add a preset on a standalone Pi, or as a first step to overwrite a currently existing preset.

Another limitation is that - as far as I understand at this point - we need the preset name to recall a preset through OSC.

Among the commands that seem useful to add to the runner for screen-free applications:

- update/overwrite current preset (impossible right now without giving the preset name as argument, right? /rnbo/inst/0/presets/save needs a preset name, right?)(well, we can make a Python script that saves using the name of the most recently recalled preset)

- save as new preset (either insert or add as last preset)

Browser, I see.
For sure, we would like to be able to send an OSC command to add a preset on a standalone Pi, or as a first step to overwrite a currently existing preset.
Another limitation is that - as far as I understand at this point - we need the preset name to recall a preset through OSC.
Among the commands that seem useful to add to the runner for screen-free applications:
- update/overwrite current preset (impossible right now without giving the preset name as argument, right? /rnbo/inst/0/presets/save needs a preset name, right?)(well, we can make a Python script that saves using the name of the most recently recalled preset)
- load previous preset
- load next preset
- save as new preset (either insert or add as last preset)

The browser actually works just as a fronted for the OSC endpoints. behind the scenes it’s just sending OSC messages to the RNBO runner.

if preset loading by index via OSC is currently not possible, a workaround could be connecting via MIDI (could be within a python script as well) and translate your own OSC message into a MIDI program change message. This way you can load presets by index.

for saving you could try using the program (change) number as name for example.

The browser actually works just as a  fronted for the OSC endpoints. behind the scenes it’s just sending OSC messages to the RNBO runner.
if preset loading by index via OSC  is currently not possible, a workaround could be connecting  via MIDI (could be within a python script as well) and translate your own OSC message into a MIDI program change message. This way you can load presets by index.
for saving you could try using the program (change) number as name for example. 

Yes, that's clear. Thanks for the workaround idea to send MIDI via Python.

RNBO - where are presets (parameter values) stored on Raspberry Pi?