Pattrstorage & dynamic bpatcher loading.
Following on from the thread about dynamically loading bpatchers using scripting...
I'd be interested to know how anyone who does this in their patches handles presets. I've found that switching bpatchers in and out of a patch recalls their individual stored preset slots in pattrstorage only while the main patch is loaded. Saving the pattrstorage .json only preserves the preset slots for the currently loaded bpatcher, and once you restart the main patch, or reload the .json file, the other settings are lost.
The only solutions I can think of off the top of my head are
either to remove the pattr/autopattr objects from one of the bpatchers (the one that's easiest to set up quickly or that doesn't need to have its UI settings stored) or
have a duplicate set of UI objects for each bpatcher (four times two in my case) offscreen, and use the "load bpatcher" command to load the current settings from the offscreen UI to the internal bpatcher UI.(And remove the pattr/autopattr objects from both bpatchers).
Anyone thought of anything neater?
I make a "pattr bank" for this type of thing.
In my main patch I create a subpatcher and put a [pattrmarker pattrBank]; this contains many instances of the patchers that I want to store in my pattr system - ALL there is in here are parameter objects linked with pattrs. All these patchers are given a unique script name so my bpatchers can directly reference the patchers and objects in it.
--- This "pattr bank" houses all of the values I want to store with pattrstorage.
Then I have my UI bpatchers. When I click on a button to replace a bpatcher, it stores the patch name I want to recall in a [v]. The newly loaded bpatcher loadbangs this [v], sending the script name of the patcher I want to recall into a "bindto ::pattrBank::" message ( where v is the specific patch instance I want to recall ), which is then sent to each pattr.
So basically my bpatchers don't store any data, they just "bindto" the visible parameters in my "pattr bank"
I've made you a little demo:
Very nice. I've only ever made significant use of pattrmarker once before, so I tend to forget about it. And actually, as I'm tending to create offscreen duplicates of module UIs to use with Mira, it actually makes more sense generally to use this method to store settings.
I'm going to look at implementing that tomorrow (working on something else right now).
Thanks!
Great! I'm happy you found it useful.
I have a similar process when I want to have all the modules running constantly in the background, but wish to have only the selected module "displayed". With this method, I have a bpatcher as a completely "dumb" UI that simply hosts the parameter UI objects. All of the processing of the data is done behind the scenes in my "pattr bank"; the bpatcher is then only used to allow me to edit the parameters.