Mark

i have a main patcher with a preset/pattrstorage system that is working fine.

now i have built an embedded Bpatcher which i want to have it's own preset object, but i want it to be "slave" to the preset system of the main patch.

eg, if i am on preset 5 on the MAIN-Patch, save slot 2 on the B-Patch preset, then switch to to preset 7 on the MAIN-Patch, and save slot 2 again on the B-Patcher with some different values, then slot 2 of B-Patcher preset should contain different values when i switch between slots 5 and 7 on the MAIN-Patch Preset.

https://cycling74.com/forums/some-basics-on-pattrstorage

but the solution provided has a broken link, and the one posted later didn't seem to work as intended.

i have a main patcher with a preset/pattrstorage system that is working fine.
now i have built an embedded Bpatcher which i want to have it's own preset object, but i want it to be "slave" to the preset system of the main patch.
eg, if i am on preset 5 on the MAIN-Patch, save slot 2 on the B-Patch preset, then switch to to preset 7 on the MAIN-Patch, and save slot 2 again on the B-Patcher with some different values, then slot 2 of B-Patcher preset should contain different values when i switch between slots 5 and 7 on the MAIN-Patch Preset.

probably this is relevant: https://cycling74.com/forums/some-basics-on-pattrstorage
but the solution provided has a broken link, and the one posted later didn't seem to work as intended.

i have a main patcher with a preset/pattrstorage system that is working fine.
now i have built an embedded Bpatcher which i want to have it'

master-slave-preset-bank-help

One [preset] binded to one [pattrstorage @greedy0] 

One [preset] binded dynamically to one of a number of [pattrstorage]'s each of which corresponds to a preset slot of the Main-Patch.

You need to have multiple [pattrstorage] objects in the B-Patcher. As many as the number of Preset Slots available in the Main-Patch Preset. But all of them are controlled by the same, dynamically routed [preset] object, so not much of a hustle unless it eats extra cpu?

the B-Patcher presets data isn't actually saved INSIDE of the Main-Patcher preset slots, so if you save a MAIN-Patcher preset slot somewhere else eg, in a different slot number, then the corresponding B-Patcher preset data will not be copied as well.

I think i can come up with a solution to the second issue. unless someone has a better implementation in mind?

this is the best i came up with so far:
On Main-Patch:
One [preset] binded to one [pattrstorage @greedy0] 
On B-Patch:
One [preset] binded dynamically to one of a number of [pattrstorage]'s each of which corresponds to a preset slot of the Main-Patch.
it works but it has 2 downsides:
1.
You need to have multiple [pattrstorage] objects in the B-Patcher. As many as the number of Preset Slots available in the Main-Patch Preset. But all of them are controlled by the same, dynamically routed [preset] object, so not much of a hustle unless it eats extra cpu?

2. 
the B-Patcher presets data isn't actually saved INSIDE of the Main-Patcher preset slots, so if you save a MAIN-Patcher preset slot somewhere else eg, in a different slot number, then the corresponding B-Patcher preset data will not be copied as well. 

 I think i can come up  with a solution to the second issue. unless someone has a better implementation in mind?



it seems i rushed to celebrate and neglected to test my solution properly.

it seems that the presence of more than one [pattrstorage] in the same patcher (B-patcher in this case) causes problems. probably because only the 1st [pattrstorage] object sees all the parameters while the rest remain blind. 

i will see if it is possible to fix this somehow, or else i will have to seek for a solution without same-level pattrstorage's. 

it seems i rushed to celebrate and neglected to test my solution properly.
it seems that the presence of more than one [pattrstorage] in the same patcher (B-patcher in this case) causes problems. probably because only the 1st [pattrstorage] object sees all the parameters while the rest remain blind. 
i will see if it is possible to fix this somehow, or else i will have to seek for a solution without same-level pattrstorage's. 


perhaps subscribemode can be used in a way that will allow multiple b-patchers in the same patch?

in the meantime i will first try to think of a solution without use of multiple same-level [pattrst..]

perhaps subscribemode can be used in a way that will allow multiple b-patchers in the same patch?
anyone ever tried that?
in the meantime i will first try to think of a solution without use of multiple same-level [pattrst..]


It doesn't need to work that way. What you can do is 

* Create one pattrstorage at the top level

* Select the bpatchers and in the inspector, give them each a unique scripting name.

https://www.yofiel.com/downloads/audio-apps/remixquad-pro-audio-3d

 go to section on presets. You will see the storage window. Each of those nested hierarchies are bpatchers, with the scripting names showing up as names of the parent bpatcher instance.

If you set pattrstorage "outputmode 1", you will see on the output from it, the nested instances when you change their values, with double colons between the bpatcher name instances and the objects in the bpatcher.

It doesn't need to work that way. What you can do is 
* Create one pattrstorage at the top level
* Put autopattr object in the bpatchers
* Select the bpatchers and in the inspector, give them each a unique scripting name. 

If you look at RemixQuad3d,  https://www.yofiel.com/downloads/audio-apps/remixquad-pro-audio-3d  go to section on presets. You will see the storage window. Each of those nested hierarchies are bpatchers, with the scripting names showing up as names of the parent bpatcher instance.  

If you set pattrstorage "outputmode 1", you will see on the output from it, the nested instances when you change their values, with double colons between the bpatcher name instances and the objects in the bpatcher. 

i'm not sure i understand how to use your solution exactly.

may this be because i have not explained myself well?

taking a look at the storage-window picture in your link, i get the impression that you have a set of identical sub-patchers, each one corresponding to a different channel FXsend. all of which may be active simultaneously, meaning that they all exist in the patch simultaneously?

in my case, i want just one b-patcher, just with an independent preset bank for each of the top-patcher preset slots.

i assume i could still use your solution to implement what i want, but then i would have 8 simultaneous versions of the same b-patcher running? (while i actually only need 1)

please correct me if i have misundertood your solution, i will try to have another look at it in the meantime.

to help myself become more clear: this is what i had come up with before, but it only works when the 1st preset slot of the Main patcher works :

each top-level preset slot corresponds to a different instrument.

and each b-patcher preset slot corresponds to a different chord.

i want each instrument to have it's own chord presets, independent of the others.

i'm not sure i understand how to use your solution exactly.
may this be because i have not explained myself well?
taking a look at the storage-window picture in your link, i get the impression that you have a set of identical  sub-patchers, each one corresponding to a different channel FXsend. all of which may be active simultaneously, meaning that they all exist in the patch simultaneously?
in my case, i want just one b-patcher, just with an independent preset bank for each of the top-patcher preset slots.
i assume i could still use your solution to implement what i want, but then i would have 8 simultaneous versions of the same b-patcher running? (while i actually only need 1)

please correct me if i have misundertood your solution, i will try to have another look at it in the meantime.

 to help myself become more clear: this is what i had come up with before, but it only works when the 1st preset slot of the Main patcher works : 

each top-level preset slot corresponds to a different instrument.
and each b-patcher preset slot corresponds to a different chord.
i want each instrument to have it's own chord presets, independent of the others.



Oh Im sorry, if you want independent presets in the bpatchers, then it is much more difficult to use one pattrstorage object. One can do it with an uzi firing into 'setstoredvalue' messages to duplicate presets at the top level with different versions of the subpatcher preset, but it's very fiddly.

Oh Im sorry, if you want independent presets in the bpatchers, then it is much more difficult to use one pattrstorage object.  One can do it with an uzi firing into 'setstoredvalue' messages to duplicate presets at the top level with different versions of the subpatcher preset, but it's very fiddly.  

it seems that the subscribemode function is also not working properly when more than one pattrstorages are present. can anyone confirm this?

i have attached below an attempt to solve my problem using the subscribemode attribute.

save a slot on each of the master-patcher presets.

if you click on the storagewindow message box and put the 4 windows side by side, you will see that switching between master presets does not always fill the correct sub-pattrstorage with the clients/values.

can someone verify that using multiple pattrstorages in the same patch is forbidden? 

i don't fully get your idea, but i would be interested to try and implement it depending on what you mean by "very fiddly". 

also, i am open to suggestions that would require me to make my own [preset] interface object for the sub-level, if they have good chances to work in a stable manner.

and as a last resort: how much of a hassle would it be to implement a DIY sub-preset mechanism, using for example something like [coll] instead of [pattrstorage]?

unfortunately i'm leaning to the conclusion that it may be the only way to implement this sort of master-slave preset relationship.

it seems that the subscribemode function is also not working properly when more than one pattrstorages are present. can anyone confirm this?
i have attached below an attempt to solve my problem using the subscribemode attribute.
save a slot on each of the master-patcher presets.
if you click on the storagewindow message box and put the 4 windows side by side, you will see that switching between master presets does not always fill the correct sub-pattrstorage with the clients/values.
can someone verify that using multiple pattrstorages in the same patch is forbidden?  

@ernest:
i don't fully get your idea, but i would be interested to try and implement it depending on what you mean by "very fiddly".  

also, i am open to suggestions that would require me to make my own [preset] interface object for the sub-level, if they have good chances to work in a stable manner.

and as a last resort: how much of a hassle would it be to implement a DIY sub-preset mechanism, using for example something like [coll] instead of [pattrstorage]?
unfortunately i'm leaning to the conclusion that it may be the only way to implement this sort of master-slave preset relationship.


ps: on the autopattr helpfile it is stated that multiple [autopattr] objects should not be used in the same patcher level.

i have not seen the same stated about the [pattrstorage] object anywhere in the documentation, although i have seen on other threads that many users tend to this conclusion. 

or am i (and other users) just not understanding certain aspects of how it works?

ps: on the autopattr helpfile it is stated that multiple [autopattr] objects should not be used in the same patcher level.
i have not seen the same stated about the [pattrstorage] object anywhere in the documentation, although i have seen on other threads that many users tend to this conclusion. 
is it a bug? 
is it insufficiently documented? 
or am i (and other users) just not understanding certain aspects of how it works?


implemented a stable, simple, working solution, finally!

you have your MAIN [pattrstorage] and [preset], with let's say 8 slots.

on the b-patcher you have just one pattrstorage, but 8 times the slots you actually want for the B-patcher, so 8*16 = 128 slots for example.

for the interface of the b-patcher preset system you have a dummy [preset], which isn't actually saving anything you need, it's just routing the appropriate commands to the appropriate slots of the b-patcher [pattrstorage]

i would like to mark this subject as "solved".

but the question of whether or not it's possible to have multiple working [pattrstorage] objects in the same level of a patcher, remains unanswered.

and it is a question that has been bugging people on these forums from a couple of years ago to a decade ago, so it would be good to get some official answers and/or improve the documentation on the pattr system.

implemented a stable, simple, working solution, finally!
you have your MAIN [pattrstorage] and [preset], with let's say 8 slots.
on the b-patcher you have just one pattrstorage, but 8 times the slots you actually want for the B-patcher, so 8*16 = 128 slots for example.
for the interface of the b-patcher preset system you have a dummy [preset], which isn't actually saving anything you need, it's just routing the appropriate commands to the appropriate slots of the b-patcher [pattrstorage]


i would like to mark this subject as "solved".
but the question of whether or not it's possible to have multiple working [pattrstorage] objects in the same level of a patcher, remains unanswered.
and it is a question that has been bugging people on these forums from a couple of years ago to a decade ago, so  it would be good to get some official answers and/or improve the documentation on the pattr system.

Well, Im glad you figured out something that fits your needs. The typical problem is, if you change the presets in the subcomponents, the top-level presets stop working the way they did. But some people want that. There's no prescribed way to do it.

Master-Slave Preset Bank Help