Stefan Tiedje

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 

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 

I always thought naming the patterstorage is ment for that purpose, but 

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...

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...

-- 
Stefan Tiedje------------x-------
--_____-----------|--------------
--(_|_ ----|-----|-----()-------
-- _|_)----|-----()--------------
----------()--------www.ccmix.com


presetmanagement-with-similar-subpatchers-in-pattrstorage

Unless I miss the point about why pattrstorages should be instantiated locally, the suggestion would be to have one globally?

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 ...

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?

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 ...

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
----------------------------------------------------


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.

> 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

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 

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... ;-)

Presetmanagement with similar subpatchers in pattrstorage