a pattrstorage that manages pattrstorages

Yes! This is how pattrstorage is designed. The top-level pattrstorage (not in greedy mode) will see the child pattrstorage objects. You can set the values of those pattrstorages (the presets) from the master. What isn't working for you?

Jeremy

thanks as always, jeremy!

i think i still don't really get pattrstorage :) for my current understanding:
if i *recall 1* from the parent's pattrstorage, all bpatcher pattrstorages recall (the settings of) their first preset.
i how ever would like to find a way to store e.g. 10 different presets of a bpatcher pattrstorage to one preset of a parent pattrstorage. so:
> i *recall 1* at parent level – a set of 10 presets if recalled for the bpatchers.
> i *recall 2* at parent leven – a set of 10 other presets is recalled for the bpatchers

is anything as such possible? a simple transfer:
parent pattrstorage manages my "songs" – bpatcher pattrstorages manage my parts in each song. i want to recall a new "song" and therefore the 10 according "parts" of this song :)

thanks again

Maybe it's easier to show than to tell. See attached project. The master stores the "preset of presets", the children store their own presets. You can change the state of the children all at once (by recalling a preset in the master), or individually (by recalling a preset for a named child). Hope this helps...

Jeremy

EDIT: sorry the website doesn't allow us to upload Max documents at the moment... here's a dropbox link.

awww! you're incredible! thanks you so much :)

dude... Maxzip?!

.maxzip files are created when you make a snapshot of a project. They're just zip files, of course, but since you want them associated with Max, well... .maxzip!

Jeremy

yeah, I'm just stunned at how cool it is. I love a simple solution that's "just" something yet still killer.

Bumping this for a further strategy question:

say I have 4-5 areas of my patch, and I want to be able to save and recall presets for these areas separately or at times collectively, would placing these areas in their own bpatcher with their own pattrstorage be the way to go? Even if that means having nested bpatchers?

Thanks for any input - trying to clear up some of my max "blind spots" for my current performance patch.

That's how I would do it. Nested bpatchers are nothing to be afraid of. :-)

Jeremy