Rules/strategies for pattrstorage in nested bpatchers?

May 23, 2012 at 3:01pm

Rules/strategies for pattrstorage in nested bpatchers?

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.

In other words, this hierarchy works:

-master with pattrstorage
–bpatcher containing patch with pattr parameters

But this hierarchy doesn’t work:

-master with pattrstorage
–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?

Thanks so much!

Jeff

#61650
May 23, 2012 at 5:08pm

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?

#222544
May 23, 2012 at 5:56pm

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.

#222545
May 24, 2012 at 2:29pm

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

#222546
Nov 7, 2012 at 10:22pm

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

#222547
Nov 8, 2012 at 3:33pm

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.

#222548
Nov 8, 2012 at 4:29pm

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?

#222549
Nov 8, 2012 at 4:55pm

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

– Pasted Max Patch, click to expand. –
#222550
Nov 8, 2012 at 5:03pm

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

#222551
Nov 8, 2012 at 6:58pm

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

Heres the section of my main patch:

– Pasted Max Patch, click to expand. –

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

– Pasted Max Patch, click to expand. –
#222552
Nov 8, 2012 at 7:02pm

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

#222553
Nov 8, 2012 at 9:34pm

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.

#222554
Nov 8, 2012 at 9:46pm

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?

#222555
Nov 11, 2012 at 11:38am

A little sunday morning bump never hurt anyone right?

#222556
Nov 22, 2012 at 8:49am

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?

#222557

You must be logged in to reply to this topic.