Hugobox

Is it possible to have a pattrstorage inside a bpatcher that accesses the parent patcher's pattrs and also the parent patcher's other bpatchers' pattrs? I thought the greedy attribute would help me, but I could't make it work. For the following non-working patch below, I used subpatcher's instead of bpatchers which I'd use ultimately. Thanks

Hi fellow maxers,
Is it possible to have a pattrstorage inside a bpatcher that accesses the parent patcher's pattrs and also the parent patcher's other bpatchers' pattrs? I thought the greedy attribute would help me, but I could't make it work. For the following non-working patch below, I used subpatcher's instead of bpatchers which I'd use ultimately. Thanks

pattrstorage-inside-bpatcher-accessing-parent-patchers-pattrs

You seem to be doing exactly what the "passing_messages" subpatch of the [pattrstorage] helpfile is doing. Can't you just copy the relevant sections from the helpfile?

I believe that's what I did in my example. The only difference with the help file is that I put the pattrstorage inside a subpatcher (master) which makes it not able to see the pattrs inside other top-level subpatchers (slider1 and slider2).

No, the pattrstorage has to be in the same patch or a direct ancestor patch of the pattrs in order to be able to see them. By ancestor I mean the parent, the parent of the parent, the parent of the parent of the parent, and so on. Because you stuck your pattrstorage in a subpatch of an ancestor, this won't work.

This is slightly annoying if you are trying to make your patch as clean as possible, but also keeps from running into confusing structure-related bugs when working on really big patches (think about what would happen if you introduce another subpatch with another pattrstorage). So use presentation mode to clean things up and keep the pattrstorage in an ancestor of the pattrs' patch.

Thanks for the info. It makes sense but its weird as I didn't give up and tried some more with the parent:: prefix.here's what I have so far:

1 set slider_1 (parent::slider_1::slider $1) that works (not sure why the other set doesn't)

And the gets doesn't work (parent::getslider_1::slider)

and double-clicking on the pattstorage (inside the "master" subpatcher reveals it being empty)

so why does it work for setting 1 slider?

Check the scripting name of the [p slider_2] subpatcher object in the inspector. It is set to "slider_2[1]". This can happen when copying objects because two objects are not allowed to have the same scripting name. If you change that it will work.

Right. So two objects cannot have the same scripting name unless they are in subpatchers (both sliders inside the subpatchers have the same scripting name)

But while the parent::set slider works, the parent::get slider doesn't. Because in order to use the gets, the pattrstorage has to see the pattrs (double-clicking the pattrstorage)? Kinda weird that the sets work no?

Oh, sorry, didn't read closely enough. I see what you are saying. Hmm, well the pattrstorage reference says:

"Incoming messages to the pattrstorage object are analyzed. If the first element of the message matches the path name or alias of an object maintained by the pattrstorage object (visible in the object's client list), the subsequent arguments in the message set that object's value. Otherwise, the message is ignored."

I think the getslider style messages only work with a pattrhub object, not pattrstorage.

Also the syntax "parent::getslider_1::slider" looks wrong. Even with pattrhub you might need to do "getparent::slider_1::slider" or something like that.

Oh, sorry, didn't read closely enough. I see what you are saying. Hmm, well the pattrstorage reference says:
"Incoming messages to the pattrstorage object are analyzed. If the first element of the message matches the path name or alias of an object maintained by the pattrstorage object (visible in the object's client list), the subsequent arguments in the message set that object's value. Otherwise, the message is ignored."

I think the getslider style messages only work with a pattrhub object, not pattrstorage. 

Also the syntax "parent::getslider_1::slider" looks wrong. Even with pattrhub you might need to do "getparent::slider_1::slider" or something like that.


Excellent! "getparent::slider_1::slider" works! Thanks! No need for pattrhubs !!! Simple and elegant, love it.

pattrstorage inside bpatcher accessing parent patcher's pattrs?