Forums > Dev

Traversing the patcher heirarchy

May 10, 2007 | 6:13 am

I’m looking for something equivalent to the patcher.parentpatcher functionality available in javascript.

I want to find the parent of the patcher my object is instantiated in, then look for any instantiations of my object in that parent (and if there aren’t any, in its parent, and so on).

Since I’m a non-UI object I think I need to get a reference to the patcher I’m in at object creation, in my object_new function, ie:

void *p;
p = ((t_symbol *)gensym("#P"))->s_thing;

How do I go about finding p’s immediate parent?


May 10, 2007 | 6:32 am

I would imagine this can be done using a pointer to a t_patcher
object, I haven’t invoked anything through the patcher hierarchy for
referencing something outside patcher for the object itself but this
is the thing that comes to mind…probably would look like a bunch of
nested pointers if it’s further up in the hierarchy of patcher
windows…

Brandon Nickell

On 5/9/07, John Pitcairn wrote:
>
> I’m looking for something equivalent to the patcher.parentpatcher functionality available in javascript.
>
> I want to find the parent of the patcher my object is instantiated in, then look for any instantiations of my object in that parent (and if there aren’t any, in its parent, and so on).
>
> Since I’m a non-UI object I think I need to get a reference to the patcher I’m in at object creation, in my object_new function, ie:
>
> void *p;
> p = ((t_symbol *)gensym("#P"))->s_thing;
>
> How do I go about finding p’s immediate parent?
>


May 10, 2007 | 9:34 am

This is trickier than it sounds. I might suggest waiting for Max 5,
if you can, where it’ll be much easier. If you can’t wait, I could
send you some code which does it.

jb

Am 10.05.2007 um 08:13 schrieb John Pitcairn:

>
> I’m looking for something equivalent to the patcher.parentpatcher
> functionality available in javascript.
>
> I want to find the parent of the patcher my object is instantiated
> in, then look for any instantiations of my object in that parent
> (and if there aren’t any, in its parent, and so on).
>
> Since I’m a non-UI object I think I need to get a reference to the
> patcher I’m in at object creation, in my object_new function, ie:
>
> void *p;
> p = ((t_symbol *)gensym("#P"))->s_thing;
>
> How do I go about finding p’s immediate parent?


May 10, 2007 | 12:13 pm

Working on the same project (see the thread ‘how to apply oo in max’), I’m interested in this too. I’d love to be able to at least make a prototype in max 4.

Thanks,
Mattijs

Quote: Jeremy Bernstein wrote on Thu, 10 May 2007 11:34
—————————————————-
> This is trickier than it sounds. I might suggest waiting for Max 5,
> if you can, where it’ll be much easier. If you can’t wait, I could
> send you some code which does it.
>
> jb
>
> Am 10.05.2007 um 08:13 schrieb John Pitcairn:
>
> >
> > I’m looking for something equivalent to the patcher.parentpatcher
> > functionality available in javascript.
> >
> > I want to find the parent of the patcher my object is instantiated
> > in, then look for any instantiations of my object in that parent
> > (and if there aren’t any, in its parent, and so on).
> >
> > Since I’m a non-UI object I think I need to get a reference to the
> > patcher I’m in at object creation, in my object_new function, ie:
> >
> > void *p;
> > p = ((t_symbol *)gensym("#P"))->s_thing;
> >
> > How do I go about finding p’s immediate parent?
>
>
—————————————————-


May 10, 2007 | 12:36 pm

On May 10, 2007, at 7:13 AM, Mattijs Kneppers wrote:

> Working on the same project (see the thread ‘how to apply oo in
> max’), I’m interested in this too. I’d love to be able to at least
> make a prototype in max 4.

There is some patcher traversal code in Jamoma. Take a look at
jcom_core_subscribe() in this file:
http://jamoma.svn.sourceforge.net/viewvc/jamoma/trunk/Externals/
common/jcom.core.cpp?revision=1863&view=markup

This function is used by other objects (jcom.parameter, jcom.message,
jcom.return, etc.) to find a jcom.hub object in the patch. If it
can’t find it then it looks for the next parent patcher, etc. When
it finds a jcom.hub, it sends it a message.

This code, however, will all break in Max 5 – it is very unsafe to be
relying on patcher and box structs such as what has been done in this
code. If you use it, be prepared for it to break!

best,
Tim

> Quote: Jeremy Bernstein wrote on Thu, 10 May 2007 11:34
> —————————————————-
>> This is trickier than it sounds. I might suggest waiting for Max 5,
>> if you can, where it’ll be much easier. If you can’t wait, I could
>> send you some code which does it.
>>
>> jb
>>
>> Am 10.05.2007 um 08:13 schrieb John Pitcairn:
>>
>>>
>>> I’m looking for something equivalent to the patcher.parentpatcher
>>> functionality available in javascript.
>>>
>>> I want to find the parent of the patcher my object is instantiated
>>> in, then look for any instantiations of my object in that parent
>>> (and if there aren’t any, in its parent, and so on).
>>>
>>> Since I’m a non-UI object I think I need to get a reference to the
>>> patcher I’m in at object creation, in my object_new function, ie:
>>>
>>> void *p;
>>> p = ((t_symbol *)gensym("#P"))->s_thing;
>>>
>>> How do I go about finding p’s immediate parent?
>>
>>
> —————————————————-
>
>
> –
> SmadSteck – http://www.smadsteck.nl
> Hard- and software for interactive audiovisual sampling


May 10, 2007 | 8:24 pm

Quote: Jeremy Bernstein wrote on Thu, 10 May 2007 21:34
—————————————————-
> This is trickier than it sounds. I might suggest waiting for Max
> 5, if you can, where it’ll be much easier. If you can’t wait, I
> could send you some code which does it.

Ah, thanks. This begs the question "wait how long?", but I guess you can’t answer that (privately)?

Would the code you’re suggesting be similar to the Jamoma example Tim suggests? And will it also break in Max 5?

Possible dumb interim workaround – have my object instantiate a pattrforward/pattrexists behind the scenes and use those to traverse the parent heirarchy looking for a specific name (though I’d rather avoid requiring a name)…


May 11, 2007 | 3:25 am

I have it working, I think – thanks Tim for the example code, which can be easily modified for my requirements.

If it breaks in Max 5, it shouldn’t be a big deal to rewrite the findParent() function according to whatever new functionality is in place. For anyone referring to this in future, here’s my test code:

void *obj_new(void)
{
t_obj *x;
x = (t_obj *)newobject(obj_class);
// get our patcher here – we’re a non-UI object
x->p = (t_patcher *)((t_symbol *)gensym("#P"))->s_thing;
return x;
}

void obj_loadbang(t_obj *x)
{
x->parent = findParent(x);
}

t_obj* findParent(t_obj *x)
{
t_patcher *p = x->p;
t_box *b;
void *parent = NULL;
if(p->p_vnewobj != NULL) // we start in the same patcher, go up
{
b = (t_box *)p->p_vnewobj;
p = b->b_patcher;

again:
for(b = p->p_box; b; b = b->b_next) // traverse the boxes
{
if(ob_name(b->b_firstin) == ob_name(x)) // if we find a parent
{
parent = b->b_firstin; // store the pointer to it
break; // then stop looking
}
}
if(parent == NULL) // failed to find a parent in the patcher
{
if(p->p_vnewobj != NULL) // go one level higher
{
b = (t_box *)p->p_vnewobj;
p = b->b_patcher;
goto again;
}
else
{
error("could not find a parent object");
}
}
}
else
{
return NULL; // we’re at the top level
}
return parent;
}


May 11, 2007 | 3:08 pm

That’s great, Tim, thanks! Didn’t realize Jamoma could be so valuable as a resource for practical implementation solutions. Just curious: is there a specific reason not to choose for a recursive lookup function?

Jeremy, would your example code shed a different light on this? Any info is welcome.. :)

Mattijs

Quote: Timothy Place wrote on Thu, 10 May 2007 14:36
—————————————————-
> On May 10, 2007, at 7:13 AM, Mattijs Kneppers wrote:
>
> > Working on the same project (see the thread ‘how to apply oo in
> > max’), I’m interested in this too. I’d love to be able to at least
> > make a prototype in max 4.
>
> There is some patcher traversal code in Jamoma. Take a look at
> jcom_core_subscribe() in this file:
> http://jamoma.svn.sourceforge.net/viewvc/jamoma/trunk/Externals/
> common/jcom.core.cpp?revision=1863&view=markup
>
> This function is used by other objects (jcom.parameter, jcom.message,
> jcom.return, etc.) to find a jcom.hub object in the patch. If it
> can’t find it then it looks for the next parent patcher, etc. When
> it finds a jcom.hub, it sends it a message.
>
> This code, however, will all break in Max 5 – it is very unsafe to be
> relying on patcher and box structs such as what has been done in this
> code. If you use it, be prepared for it to break!
>
> best,
> Tim
>
>
> > Quote: Jeremy Bernstein wrote on Thu, 10 May 2007 11:34
> > —————————————————-
> >> This is trickier than it sounds. I might suggest waiting for Max 5,
> >> if you can, where it’ll be much easier. If you can’t wait, I could
> >> send you some code which does it.
> >>
> >> jb
> >>
> >> Am 10.05.2007 um 08:13 schrieb John Pitcairn:
> >>
> >>>
> >>> I’m looking for something equivalent to the patcher.parentpatcher
> >>> functionality available in javascript.
> >>>
> >>> I want to find the parent of the patcher my object is instantiated
> >>> in, then look for any instantiations of my object in that parent
> >>> (and if there aren’t any, in its parent, and so on).
> >>>
> >>> Since I’m a non-UI object I think I need to get a reference to the
> >>> patcher I’m in at object creation, in my object_new function, ie:
> >>>
> >>> void *p;
> >>> p = ((t_symbol *)gensym("#P"))->s_thing;
> >>>
> >>> How do I go about finding p’s immediate parent?
> >>
> >>
> > —————————————————-
> >
> >
> > –
> > SmadSteck – http://www.smadsteck.nl
> > Hard- and software for interactive audiovisual sampling
>
>
—————————————————-


May 11, 2007 | 3:13 pm

My code would probably confuse matters, since it handles additional
cases like bpatchers, poly~s and the like. I think it’s better if you
don’t start messing with those cases, personally, and just wait until
some more comfortable ways exist to handle them.

jb

Am 11.05.2007 um 17:08 schrieb Mattijs Kneppers:

>
> That’s great, Tim, thanks! Didn’t realize Jamoma could be so
> valuable as a resource for practical implementation solutions. Just
> curious: is there a specific reason not to choose for a recursive
> lookup function?
>
> Jeremy, would your example code shed a different light on this? Any
> info is welcome.. :)
>
> Mattijs
>
> Quote: Timothy Place wrote on Thu, 10 May 2007 14:36
> —————————————————-
>> On May 10, 2007, at 7:13 AM, Mattijs Kneppers wrote:
>>
>>> Working on the same project (see the thread ‘how to apply oo in
>>> max’), I’m interested in this too. I’d love to be able to at least
>>> make a prototype in max 4.
>>
>> There is some patcher traversal code in Jamoma. Take a look at
>> jcom_core_subscribe() in this file:
>> http://jamoma.svn.sourceforge.net/viewvc/jamoma/trunk/Externals/
>> common/jcom.core.cpp?revision=1863&view=markup
>>
>> This function is used by other objects (jcom.parameter, jcom.message,
>> jcom.return, etc.) to find a jcom.hub object in the patch. If it
>> can’t find it then it looks for the next parent patcher, etc. When
>> it finds a jcom.hub, it sends it a message.
>>
>> This code, however, will all break in Max 5 – it is very unsafe to be
>> relying on patcher and box structs such as what has been done in this
>> code. If you use it, be prepared for it to break!
>>
>> best,
>> Tim
>>
>>
>>> Quote: Jeremy Bernstein wrote on Thu, 10 May 2007 11:34
>>> —————————————————-
>>>> This is trickier than it sounds. I might suggest waiting for Max 5,
>>>> if you can, where it’ll be much easier. If you can’t wait, I could
>>>> send you some code which does it.
>>>>
>>>> jb
>>>>
>>>> Am 10.05.2007 um 08:13 schrieb John Pitcairn:
>>>>
>>>>>
>>>>> I’m looking for something equivalent to the patcher.parentpatcher
>>>>> functionality available in javascript.
>>>>>
>>>>> I want to find the parent of the patcher my object is instantiated
>>>>> in, then look for any instantiations of my object in that parent
>>>>> (and if there aren’t any, in its parent, and so on).
>>>>>
>>>>> Since I’m a non-UI object I think I need to get a reference to the
>>>>> patcher I’m in at object creation, in my object_new function, ie:
>>>>>
>>>>> void *p;
>>>>> p = ((t_symbol *)gensym("#P"))->s_thing;
>>>>>
>>>>> How do I go about finding p’s immediate parent?
>>>>
>>>>
>>> —————————————————-
>>>
>>>
>>> –
>>> SmadSteck – http://www.smadsteck.nl
>>> Hard- and software for interactive audiovisual sampling
>>
>>
> —————————————————-
>
>
> –
> SmadSteck – http://www.smadsteck.nl
> Hard- and software for interactive audiovisual sampling


May 11, 2007 | 3:31 pm

Ok.

Mattijs

Quote: Jeremy Bernstein wrote on Fri, 11 May 2007 17:13
—————————————————-
> My code would probably confuse matters, since it handles additional
> cases like bpatchers, poly~s and the like. I think it’s better if you
> don’t start messing with those cases, personally, and just wait until
> some more comfortable ways exist to handle them.
>
> jb
>
> Am 11.05.2007 um 17:08 schrieb Mattijs Kneppers:
>
> >
> > That’s great, Tim, thanks! Didn’t realize Jamoma could be so
> > valuable as a resource for practical implementation solutions. Just
> > curious: is there a specific reason not to choose for a recursive
> > lookup function?
> >
> > Jeremy, would your example code shed a different light on this? Any
> > info is welcome.. :)
> >
> > Mattijs
> >
> > Quote: Timothy Place wrote on Thu, 10 May 2007 14:36
> > —————————————————-
> >> On May 10, 2007, at 7:13 AM, Mattijs Kneppers wrote:
> >>
> >>> Working on the same project (see the thread ‘how to apply oo in
> >>> max’), I’m interested in this too. I’d love to be able to at least
> >>> make a prototype in max 4.
> >>
> >> There is some patcher traversal code in Jamoma. Take a look at
> >> jcom_core_subscribe() in this file:
> >> http://jamoma.svn.sourceforge.net/viewvc/jamoma/trunk/Externals/
> >> common/jcom.core.cpp?revision=1863&view=markup
> >>
> >> This function is used by other objects (jcom.parameter, jcom.message,
> >> jcom.return, etc.) to find a jcom.hub object in the patch. If it
> >> can’t find it then it looks for the next parent patcher, etc. When
> >> it finds a jcom.hub, it sends it a message.
> >>
> >> This code, however, will all break in Max 5 – it is very unsafe to be
> >> relying on patcher and box structs such as what has been done in this
> >> code. If you use it, be prepared for it to break!
> >>
> >> best,
> >> Tim
> >>
> >>
> >>> Quote: Jeremy Bernstein wrote on Thu, 10 May 2007 11:34
> >>> —————————————————-
> >>>> This is trickier than it sounds. I might suggest waiting for Max 5,
> >>>> if you can, where it’ll be much easier. If you can’t wait, I could
> >>>> send you some code which does it.
> >>>>
> >>>> jb
> >>>>
> >>>> Am 10.05.2007 um 08:13 schrieb John Pitcairn:
> >>>>
> >>>>>
> >>>>> I’m looking for something equivalent to the patcher.parentpatcher
> >>>>> functionality available in javascript.
> >>>>>
> >>>>> I want to find the parent of the patcher my object is instantiated
> >>>>> in, then look for any instantiations of my object in that parent
> >>>>> (and if there aren’t any, in its parent, and so on).
> >>>>>
> >>>>> Since I’m a non-UI object I think I need to get a reference to the
> >>>>> patcher I’m in at object creation, in my object_new function, ie:
> >>>>>
> >>>>> void *p;
> >>>>> p = ((t_symbol *)gensym("#P"))->s_thing;
> >>>>>
> >>>>> How do I go about finding p’s immediate parent?
> >>>>
> >>>>
> >>> —————————————————-
> >>>
> >>>
> >>> –
> >>> SmadSteck – http://www.smadsteck.nl
> >>> Hard- and software for interactive audiovisual sampling
> >>
> >>
> > —————————————————-
> >
> >
> > –
> > SmadSteck – http://www.smadsteck.nl
> > Hard- and software for interactive audiovisual sampling
>
>
—————————————————-


May 12, 2007 | 12:45 am

Quote: Jeremy Bernstein wrote on Fri, 11 May 2007 17:13
—————————————————-
>> My code would probably confuse matters, since it handles
>> additional cases like bpatchers, poly~s and the like.

Quote: Mattijs wrote on Sat, 12 May 2007 03:31
—————————————————-
> Ok.

Hmm. I think we’ll be wanting this to work from inside a bpatcher at least, won’t we?


May 12, 2007 | 1:05 am

On May 11, 2007, at 7:45 PM, John Pitcairn wrote:

> Quote: Jeremy Bernstein wrote on Fri, 11 May 2007 17:13
> —————————————————-
>>> My code would probably confuse matters, since it handles
>>> additional cases like bpatchers, poly~s and the like.
>
> Quote: Mattijs wrote on Sat, 12 May 2007 03:31
> —————————————————-
>> Ok.
>
> Hmm. I think we’ll be wanting this to work from inside a bpatcher
> at least, won’t we?

That code snippet I posted from Jamoma works from within a bpatcher.
It doesn’t work from inside a poly~ though. Of course the Jamoma
code is only looking upwards – it never drills downwards into objects.

best,
Tim


May 12, 2007 | 1:26 am

Quote: Timothy Place wrote on Sat, 12 May 2007 13:05
—————————————————-
> That code snippet I posted from Jamoma works from within a
> bpatcher. It doesn’t work from inside a poly~ though. Of course
> the Jamoma code is only looking upwards

Thanks again – I just tested and it does work from inside a bpatcher. I don’t think I’ll need it to work from inside a poly, though Mattijs might(?). An upward search is all I need too.


May 12, 2007 | 8:44 am

Quote: johnpitcairn wrote on Sat, 12 May 2007 03:26
—————————————————-
> Quote: Timothy Place wrote on Sat, 12 May 2007 13:05
> —————————————————-
> > That code snippet I posted from Jamoma works from within a
> > bpatcher. It doesn’t work from inside a poly~ though. Of course
> > the Jamoma code is only looking upwards
>
> Thanks again – I just tested and it does work from inside a bpatcher. I don’t think I’ll need it to work from inside a poly, though Mattijs might(?). An upward search is all I need too.
—————————————————-

I think at some point I do need it to work from inside a poly~. But first I’m interested in a working prototype that can be benchmarked.

Upward should be enough, downward will be too costly anyway.

Mattijs


May 14, 2007 | 12:06 am

Quote: Mattijs wrote on Sat, 12 May 2007 20:44
—————————————————-
> I think at some point I do need it to work from inside a poly~.

Just tested – as it stands, it won’t traverse upward from inside a poly~. But yes, lets cross that bridge a little later, if we can.


June 1, 2007 | 12:12 am

Hey Jeremy, I tried your pattrvoyant script. From what I
can see, it should print the name (if present) of the patcher
you click on. But for some reason it finds nothing. Might I be
doing something wrong? I am running Max 4.6 on XP.


June 1, 2007 | 9:08 am

Unfortunately, I’m not clairvoyant. The patch works ok for me, using
Max 4.6.3 on OSX. It should work identically on Windows, but I don’t
have time at this instant to test it. Clicking on the subpatcher box
"p stank" correctly reports "stank" in the Max window.

jb

Am 01.06.2007 um 02:12 schrieb Anthony Palomba:

> Might I be
> doing something wrong? I am running Max 4.6 on XP.


June 8, 2007 | 12:06 am

Hey Jeremy, I took a look at the patch and it looks
like the mouse clicks are using some other origin
point then the drawing origin. I can get it to say
"stank" but I have to click about 100 pixels above the
patcher stank. Is there a reason why mouse clicks would
not match what is visibly seen?

Anthony

—– Original Message —–
From: Jeremy Bernstein
Date: Friday, June 1, 2007 4:09 am
Subject: Re: [dev] Re: Traversing the patcher heirarchy

> Unfortunately, I’m not clairvoyant. The patch works ok for me,
> using
> Max 4.6.3 on OSX. It should work identically on Windows, but I
> don’t
> have time at this instant to test it. Clicking on the subpatcher
> box
> "p stank" correctly reports "stank" in the Max window.
>
> jb
>
> Am 01.06.2007 um 02:12 schrieb Anthony Palomba:
>
> > Might I be
> > doing something wrong? I am running Max 4.6 on XP.
>
>


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