pattrstorage inside bpatcher accessing parent patcher's pattrs?

Jul 8, 2009 at 5:28pm

pattrstorage inside bpatcher accessing parent patcher's pattrs?

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

– Pasted Max Patch, click to expand. –
#44669
Jul 8, 2009 at 5:35pm

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?

lh

#160747
Jul 9, 2009 at 2:30pm

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

#160748
Jul 13, 2009 at 7:56pm

So no?

#160749
Jul 14, 2009 at 7:39pm

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.

#160750
Jul 14, 2009 at 7:55pm

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?

– Pasted Max Patch, click to expand. –
#160751
Jul 14, 2009 at 8:04pm

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.

#160752
Jul 14, 2009 at 8:12pm

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?

#160753
Jul 14, 2009 at 8:24pm

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.

#160754
Jul 14, 2009 at 8:43pm

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

#160755

You must be logged in to reply to this topic.