Presetmanagement with similar subpatchers in pattrstorage

I have a question about strategies how to deal with the following problem:

If I have a mixer with multiple channelstrips, and lets say each strip
has its own filter. I would place a channelstrip into a bpatcher by the
way, but for voices of polyphonic synths/samplers the same problem would
apply:

Now what I want, ist o have a single pattrstorage to be shared among the
multiple strips/voices. As far as I know, if I place a pattrstorage into
one strip, and duplictate it, I get several independent pattrstorages…
But I want to acces them like a named coll and share their data across
multiple instances…

I always thought naming the patterstorage is ment for that purpose, but
it isn’t… :-(

The solution I have at the moment is, to writeagain the pattrstorage on
any change always to disk, and notify the other instances to readagain…

i think Stefan is looking for a dynamic system for applying specific sets of presets to identical modules.
these modules can probably have their own set of presets as well as copying the ones of any other moduleand/or having one set of presets from one module being applied to all the other modules.
right now i could only think about storing individual groups of presets into individual colls via "dump" message ( to pattrstorage) and have have a matrix based routing system from which routes the chosen contents of these colls back to chosen nested pattrstorages …

probably a little cumbersome …

Quote: jvkr wrote on Thu, 07 February 2008 14:21
—————————————————-
> Unless I miss the point about why pattrstorages should be instantiated locally, the suggestion would be to have one globally?
>
> _
> johan
—————————————————-

jvkr schrieb:
> Ok, Stefan, to make up for my previous stupid remark. This patch
> makes use of a pattrhub and an actual object performing as a hub. I
> believe it works.

Thanks for sharing, it does work. Though I’d probably prefer the
writeagain/readagain method, as its simpler and more readable in the
resulting XML files (Yours squeeze all the preset information into a
single pattr. I doubt it will scale easily into bigger patches).

I don’t mind to have several preset.XML files, as in that scenario the
way of thinking is also by seperate collections of presets. I just see
the impossibility to undo or not save a new setting with that method…

Maybe I have to save them to a temp file, which will in turn make it as
complex as your solution… ;-)