Rules/strategies for pattrstorage in nested bpatchers?

Don't get that here... Not sure why. Is the behaviour the same as you describe if you create a similar hierarchy (master::bpatcher::bpatcher) from scratch without altering the default attributes of the pattr or pattrstorage objects?

if you reset the master [pattrstorage], does it then "see" the lowest [pattr]? I have the feeling that sometimes if things get moved around, they need to be reinstantiated. I can't say for sure that's true though, and if it is, on what version it was true.

Thanks all! More experimentation based on your suggestions shed more light on the subject. Pattrstorage is seeing all the way down the hierarchy. The problem is that the two items in the child patcher I most need to control don't seem to be pattr friendly.

The first is a umenu containing preset names that I'm changing dynamically with a textedit object. Unfortunately, only the original placeholder menu item names are being saved/recalled, not the dynamically replaced ones. I've tried checking the "Pattr stores symbol" attribute... no change.

The second is a coll. OK, I already knew that colls are excluded from the pattr system. That's why I took to embedding the child patcher that holds the coll (and having the coll set to embed it's data in the patcher).

Putting this all together, both the umenu and coll in the child patcher save/recall their values properly with pattrstorage as long as the child is embedded. But here's the linchpin... it seems that in order for this to work with several levels of nesting, the intermediate-level bpatchers between the master pattrstorage and child must be embedded as well. Alas, my patch is too complicated to make embedding everything practical, so I'm going to look for a different (disk-based) strategy to handle the umenu and coll save/recall in the child patches.

Please advise if you think I'm missing something.

Thanks again!

Jeff

I'm running into some similar problems as the OP.

I've got a pattrstorage on my main patch level, and there's a 'p patcher' in that, with 10 bpatchers using arguments to define the names of pattr objects connected to the things I want to store presets (numberboxes/umenus).

I'm using subscribe mode on my main pattrstorage, but sending it the names of the pattrs in the bpatchers doesn't work. If I put autopattrs inside the bpatchers doesn't show up either (though it shouldn't be necessary since I have pattrs in there).

So to simplify I have:

-master with pattrstorage
--intermediate 'p patcher'
---bpatcher containing patch with pattr parameters

You have to have autopattr all the way down the hierarchy.

Are you using live. controls? I've found some things with them to be a PITA.

No live. controls.
Does it matter that my objects are 'manually' connected via pattrs?

Also, not sure if this is the best thread for this, but how does one then approach having a umenu that is dynamic, and controllable by the pattr system?

@Rodrigo. In answer to your second question regarding umenu, you can use pattr to store the symbol of the umenu instead of the index. I assume that this is what you mean? (edit: forgot to paste example)

What happens if the umenu is changed independently of the hierarchy above it?

As in, my local level is being managed/stored in a umenu. So the symbols of this umenu can/will change.

My plan is to have a global preset level above that which just stores presets of the child umenu.

Wait, I think I may have answered my own question. Not sure if this is right as I've not done nested local/global presets before in max.

local presets with pattrstorage storing the parameters (and not touching the umenu)
global presets with another pattrstorage that attaches to the local preset umenu (I guess storing index, and NOT symbols, so the symbols can change).

Ok, having autopattrs on the way down isn't helping.

Heres the section of my main patch:

And the bpatcher (named "lfo.maxpat"). There's a poly~ in that, but it shouldn't matter for the pattr stuff.