johnpitcairn

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:

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

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

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


traversing-the-patcher-heirarchy

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

> 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:

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

> How do I go about finding p's immediate parent?

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

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?
>


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 

Am 10.05.2007 um 08:13 schrieb John Pitcairn:

> I'm looking for something equivalent to the patcher.parentpatcher 

> 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:

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.

>
> 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?


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.

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 

> 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:

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

> > How do I go about finding p's immediate parent?

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?
>
>
----------------------------------------------------


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 

There is some patcher traversal code in Jamoma. Take a look at 

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!

> 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

>> 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:

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

>>> How do I go about finding p's immediate parent?

> Hard- and software for interactive audiovisual sampling

> 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!

> 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


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

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.

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


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:

// get our patcher here - we're a non-UI object

x->p = (t_patcher *)((t_symbol *)gensym("

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

if(parent == NULL) // failed to find a parent in the patcher

{                                    

if(p->p_vnewobj != NULL) // go one level higher

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

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("

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; 
}


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

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 

> There is some patcher traversal code in Jamoma. Take a look at 

> 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!

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

> >> 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:

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

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


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.

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 

> Jeremy, would your example code shed a different light on this? Any 

> 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

>> There is some patcher traversal code in Jamoma. Take a look at

>> 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!

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

>>>> Am 10.05.2007 um 08:13 schrieb John Pitcairn:

>>>>> I'm looking for something equivalent to the patcher.parentpatcher

>>>>> functionality available in javascript.

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.

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


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.

> 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 

> > Jeremy, would your example code shed a different light on this? Any 

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

> >> There is some patcher traversal code in Jamoma. Take a look at

> >> 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!

> >>> Quote: Jeremy Bernstein wrote on Thu, 10 May 2007 11:34

> >>> ----------------------------------------------------

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


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

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

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?


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

Traversing the patcher heirarchy