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 pmDon'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 pmif 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 pmThanks 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
- Nov 07 2012 | 10:22 pmI'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
- Nov 08 2012 | 3:33 pmYou 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.
- Nov 08 2012 | 4:29 pmNo 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?
- Nov 08 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)
- Nov 08 2012 | 5:03 pmWhat 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).
- Nov 08 2012 | 6:58 pmOk, 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.
- Nov 08 2012 | 7:02 pmI 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).
- Nov 08 2012 | 9:34 pmhi 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.
- Nov 08 2012 | 9:46 pmUgh. 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?
- Nov 11 2012 | 11:38 amA little sunday morning bump never hurt anyone right?
- Nov 22 2012 | 8:49 amI'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?
- Dec 17 2014 | 3:00 pmRod, did you ever find a solution to this? I'm running into the same kind of problems.
- Dec 17 2014 | 3:04 pmI 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.
- Dec 26 2014 | 10:54 amif 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 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!
