jeffburger

What are the basic rules or strategies for using pattrstorage with nested bpatchers? I have a patcher containing a pattr object tied to the object I want to store values for. When I use that patcher as a bpatcher in a master patcher containing pattrstorage @greedy 1, things work as expected. But when I nest that same patcher inside an intermediate bpatcher (with or without autopattr in it), and then place that intermediate bpatcher in the master, the master pattrstorage no longer seems to control the parameters of the patcher at the lowest level.

--bpatcher containing patch with pattr parameters

--intermediate bpatcher (with or without autopattr)

---bpatcher containing patch with pattr parameters

I've seen threads referring to nested pattrstorage objects to handle nested bpatchers. Is that the only way to go? I thought greedy was greedy down through multiple bpatcher nesting levels?

What are the basic rules or strategies for using pattrstorage with nested bpatchers? I have a patcher containing a pattr object tied to the object I want to store values for. When I use that patcher as a bpatcher in a master patcher containing pattrstorage @greedy 1, things work as expected. But when I nest that same  patcher inside an intermediate bpatcher (with or without autopattr in it), and then place that intermediate bpatcher in the master, the master pattrstorage no longer seems to control the parameters of the patcher at the lowest level. 

-master with pattrstorage
--bpatcher containing patch with pattr parameters

-master with pattrstorage
--intermediate bpatcher (with or without autopattr)
---bpatcher containing patch with pattr parameters

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

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

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

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

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


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?

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

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. 

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.

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

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

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


I should add, what shows up in my pattrstorage (with nested autopattrs) is the scripting names of my bpatchers (but none of the contents inside of them (the actual pattr objects).

i just took a quick look. I removed the '@subscribemode 1' attribute from the (pattrstorage), and the (autopattr) object from the the bpatcher and everything worked fine. So maybe you could try that.

hi Rodrigo,
i just took a  quick look. I removed the '@subscribemode 1' attribute from the (pattrstorage), and the (autopattr) object from the  the bpatcher and everything worked fine. So maybe you could try that.


Ugh. That would break all the rest of my preset stuff as I have many pattrstorages all in subscribe mode so they don't gobble each others objects.

Is it possible to use greedy AND subscribe mode at the same time?

Ugh. That would break all the rest of my preset stuff as I have many pattrstorages all in subscribe mode so they don't gobble each others objects. 

Is it possible to use greedy AND subscribe mode at the same time?


A little sunday morning bump never hurt anyone right?

I'm really hoping this doesn't mean I can attach to the nested objects (without having to stop using @subscribe mode altogether).

Has anyone managed nested autopattr stuff using @subscribemode?

Rod, did you ever find a solution to this? I'm running into the same kind of problems.

I don't remember the specifics of it, but in the end I just used autopattrs as far down as I wanted to go with a pattrstorage 'above' it, then I have one master pattrstorage above those two and linked it up to what is controlling the individual sub-pattrstorages. Though the master one is overkill as I can just do regular interpolation/recall for what I want to to do at the top level.

if i understand the problem correctly, there seems to be *kind of* a solution to it.

in my case, naming pattrstorages in bpatchers via arguments that consist of 

 did not work. so substituting (part of) a pattrstorage's name with something like 1, 2, 3 (resulting in [pattrstorage 1_samename], [pattrstorage 2_samename]...) is a no-go :/

anyhow, using a unique word and setting the pattrstorage's full name by it (à la [pattrstorage #1] where "#1" is substituted by something like "first", "second", "third"...) actually did the job!

https://cycling74.com/forums/another-struggle-with-bpatchers-and-pattrstorages/

in my case, naming pattrstorages in bpatchers via arguments that consist of only a number did not work. so substituting (part of) a pattrstorage's name with something like 1, 2, 3 (resulting in [pattrstorage 1_samename], [pattrstorage 2_samename]...) is a no-go :/ 

anyhow, using a unique word and setting the pattrstorage's full name by it (à la [pattrstorage #1] where "#1" is substituted by something like "first", "second", "third"...) actually did the job! 

https://cycling74.com/forums/another-struggle-with-bpatchers-and-pattrstorages/


Rules/strategies for pattrstorage in nested bpatchers?