Daniel P

I am trying to save different groups of patcher states to different xml files using multiple instances of pattrstorage.

Eg, I want the settings of my midi routing in one xml, my tuning chart (when it is complete... argh) in one xml, and my synth settings (filters, levels, waveforms etc) in one xml.

Is there an easy way of doing this? For example pointing a certain pattr or autopattr to a certain pattrstorage, and to that pattrstorage only?

I seem to be getting problems when using "subscribe" or "active", the fundamental issue being that one pattrstorage seems to be the master and storing all of my pattrs values, while other instances of pattrstorage don't store a thing, no matter how much I subscribe or activate.

I am trying to save different groups of patcher states to different xml files using multiple instances of pattrstorage. 

multiple-pattrstorage-objects-in-a-patcher

you *could* have all of your different controls in differing subpatchers and expose them with pattrhub.

you could also have a separate pstore for each of those subpatchers.

if you want to go the subscribe/activate route you need to make sure that you're writing to slots where it's undesirable, and that you're not recalling on the wrong state, so all in all that seems more clunky. doesn't mean it's not possible.

if you want to go the subscribe/activate route you need to make sure that you're writing to slots where it's undesirable, and that you're not recalling on the wrong state, so all in all that seems more clunky.  doesn't mean it's not possible.

> you *could* have all of your different controls in differing subpatchers and expose them with pattrhub.

I am not sure if I get the method described above: Would that enable me to route my controls via a certain pattrhub in a subpatch, to a certain pstore in the main patch? What kind of attribute do I use in pattrhub or pattrstorage to make this happen?

> you could also have a separate pstore for each of those subpatchers.

This is what I am leading towards, but still it seems like an awkward solution. I would much prefer to lay out my patch as practical as possible when it comes to signal flow, and not subpatching it just to get pattrstorage to work for me.

Still the question of master "pattrstorage" and "slave" pattrstorage puzzles me. How do I change this behaviour?

>
> you could also have a separate pstore for each of those subpatchers.

Still the question of master "pattrstorage" and "slave" pattrstorage puzzles me. How do I change this behaviour?


So I made a proof of concept in a separate patch that actually worked. It seems as if my working synth patch got some erratic behaviour with the pattrstorage objects, that needs to be taken care of.

Anyway, in the patch below (proof of concept) there is one thing that still bugs me. The pattrstorage furthest to the right is NOT set to subsrcribemode, which normally would let it see all the pattr objects, BUT it sees none! Why? It feels lika a slave - master relationship vs the other pattrstorage objects. How do I manipulate this behaviour? Is there a way to make it see all?

So I made a proof of concept in a separate patch that actually worked. It seems as if my working synth patch got some erratic behaviour with the pattrstorage objects, that needs to be taken care of. 

Anyway, in the patch below (proof of concept) there is one thing that still bugs me. The pattrstorage furthest to the right is NOT set to subsrcribemode, which normally would let it see all the pattr objects, BUT it sees none! Why? It feels lika a slave - master relationship vs the other pattrstorage objects. How do I manipulate this behaviour? Is there a way to make it see all? 

Personnaly, I tend to put the different parameters I want to control in different bpatchers, with a pattrstorage in each of them. 

You could then also have a pattrstorage that manage which preset is on in each bpatcher.

Personnaly,  I tend to put the different parameters I want to control in different bpatchers, with a pattrstorage in each of them. 
You could then also have a pattrstorage that manage which preset is on in each bpatcher.
Hope this could help you...


I have been struggling with this problem as well. My MIDI assignments are strewn throughout my patch and I want those MIDI assignment boxes to have a separate preset from the other parameters.

The only thing I've thought of is having a bpatch that has all the MIDI assignments in it, and then the MIDI controls are routed to the controls throughout the patch.

I just don't want to motivate to build that bpatch/hate the idea of having to keep it up as I add/subtract parameters. I'm thinking perhaps a javascript could dynamically build that for me at startup of the patch.

Multiple pattrstorage objects in a patcher