Forums > MaxMSP

Rules/strategies for pattrstorage in nested bpatchers?

May 23, 2012 | 3:01 pm

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


May 23, 2012 | 5:08 pm

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?


May 23, 2012 | 5:56 pm

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.


May 24, 2012 | 2:29 pm

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


November 7, 2012 | 10:22 pm

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


November 8, 2012 | 3:33 pm

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.


November 8, 2012 | 4:29 pm

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?


November 8, 2012 | 4:55 pm

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

November 8, 2012 | 5:03 pm

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


November 8, 2012 | 6:58 pm

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

November 8, 2012 | 7:02 pm

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


November 8, 2012 | 9:34 pm

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.


November 8, 2012 | 9:46 pm

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?


November 11, 2012 | 11:38 am

A little sunday morning bump never hurt anyone right?


November 22, 2012 | 8:49 am

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?


Viewing 15 posts - 1 through 15 (of 15 total)