Luigi Castelli

20 instances of 'foo' have been created in a Max patch.

10 instances are in the main patch, the remaining 10 are in subpatchers

Now, I need all 20 instances of 'foo' to output certain information in

response to a message that may be received in just ONE instance of any

So, I am guessing I need a way to traverse all object instantiated that

I did check the SDK of course, but I could not find anything related to

If someone could post an example or point me to some information about

------------------------------------------------------------

THIS E-MAIL MESSAGE IS FOR THE SOLE USE OF THE INTENDED RECIPIENT AND MAY CONTAIN CONFIDENTIAL AND/OR PRIVILEGED INFORMATION. ANY UNAUTHORIZED REVIEW, USE, DISCLOSURE OR DISTRIBUTION IS PROHIBITED. IF YOU ARE NOT THE INTENDED RECIPIENT, CONTACT THE SENDER BY E-MAIL AT SUPERBIGIO@YAHOO.COM AND DESTROY ALL COPIES OF THE ORIGINAL MESSAGE. WITHOUT PREJUDICE UCC1-207.

Tired of spam? Yahoo! Mail has the best spam protection around 

I have an external called 'foo'.
20 instances of 'foo' have been created in a Max patch.
10 instances are in the main patch, the remaining 10 are in subpatchers
at various depths.

Now, I need all 20 instances of 'foo' to output certain information in
response to a message that may be received in just ONE instance of any
'foo' object.

So, I am guessing I need a way to traverse all object instantiated that
belong to the class 'foo'.

I did check the SDK of course, but I could not find anything related to
this.

If someone could post an example or point me to some information about
it, I would appreciate it.

------------------------------------------------------------
THIS E-MAIL MESSAGE IS FOR THE SOLE USE OF THE INTENDED RECIPIENT AND MAY CONTAIN CONFIDENTIAL AND/OR PRIVILEGED INFORMATION.  ANY UNAUTHORIZED REVIEW, USE, DISCLOSURE OR DISTRIBUTION IS PROHIBITED.  IF YOU ARE NOT THE INTENDED RECIPIENT, CONTACT THE SENDER BY E-MAIL AT SUPERBIGIO@YAHOO.COM AND DESTROY ALL COPIES OF THE ORIGINAL MESSAGE. WITHOUT PREJUDICE UCC1-207.
------------------------------------------------------------

Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com


getting-all-object-that-belong-to-one-class

One way that doesn't involve any patcher traversal: maintain a global 

linked list of all instances of foo and iterate through it, sending 

You could do it with patcher traversal, but it would be much more 

Am 24.04.2007 um 23:00 schrieb Luigi Castelli:

> 20 instances of 'foo' have been created in a Max patch.

> 10 instances are in the main patch, the remaining 10 are in 

> Now, I need all 20 instances of 'foo' to output certain information in

> response to a message that may be received in just ONE instance of any

> So, I am guessing I need a way to traverse all object instantiated 

> I did check the SDK of course, but I could not find anything 

> If someone could post an example or point me to some information about

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

> THIS E-MAIL MESSAGE IS FOR THE SOLE USE OF THE INTENDED RECIPIENT 

> AND MAY CONTAIN CONFIDENTIAL AND/OR PRIVILEGED INFORMATION. ANY 

> UNAUTHORIZED REVIEW, USE, DISCLOSURE OR DISTRIBUTION IS 

> PROHIBITED. IF YOU ARE NOT THE INTENDED RECIPIENT, CONTACT THE 

> SENDER BY E-MAIL AT SUPERBIGIO@YAHOO.COM AND DESTROY ALL COPIES OF 

> THE ORIGINAL MESSAGE. WITHOUT PREJUDICE UCC1-207.

> Tired of spam? Yahoo! Mail has the best spam protection around

One way that doesn't involve any patcher traversal: maintain a global  
linked list of all instances of foo and iterate through it, sending  
each object the message.

You could do it with patcher traversal, but it would be much more  
complicated.

> Hi there,
>
> I have an external called 'foo'.
> 20 instances of 'foo' have been created in a Max patch.
> 10 instances are in the main patch, the remaining 10 are in  
> subpatchers
> at various depths.
>
> Now, I need all 20 instances of 'foo' to output certain information in
> response to a message that may be received in just ONE instance of any
> 'foo' object.
>
> So, I am guessing I need a way to traverse all object instantiated  
> that
> belong to the class 'foo'.
>
> I did check the SDK of course, but I could not find anything  
> related to
> this.
>
> If someone could post an example or point me to some information about
> it, I would appreciate it.
>
> Thank you.
>
> - Luigi
>
>
> ------------------------------------------------------------
> THIS E-MAIL MESSAGE IS FOR THE SOLE USE OF THE INTENDED RECIPIENT  
> AND MAY CONTAIN CONFIDENTIAL AND/OR PRIVILEGED INFORMATION.  ANY  
> UNAUTHORIZED REVIEW, USE, DISCLOSURE OR DISTRIBUTION IS  
> PROHIBITED.  IF YOU ARE NOT THE INTENDED RECIPIENT, CONTACT THE  
> SENDER BY E-MAIL AT SUPERBIGIO@YAHOO.COM AND DESTROY ALL COPIES OF  
> THE ORIGINAL MESSAGE. WITHOUT PREJUDICE UCC1-207.
> ------------------------------------------------------------
>
>
> Do You Yahoo!?
> Tired of spam?  Yahoo! Mail has the best spam protection around
> http://mail.yahoo.com


On 07-04-24, at 1400, Luigi Castelli wrote:

I can't post a whole example, but the following method works for me:

in the foo new routine, find or create a boxless object (foohelper)

keep a linked list of boxed objects in foohelper

each time you create or delete a foo, update the linked list in 

foohelper, and delete foohelper when all the foos are deleted (i.e. 

keep global state in foohelper, and pass messages through as needed.

This may be overly complicated for your needs, depending on the state 

that needs to be shared. In my case, I'm sharing a single network 

socket across a bunch of objects, so it has to live in its own 

object. You may be able to get away with a single global linked list 

that you manage in the foo new/free methods if you don't require that 

here is some code to find/create a hidden object:

    t_symbol *hidden = gensym("foohidden");

    if (hidden != _sym_nothing && hidden->s_thing) {

        if (ob_messlist(hidden->s_thing) != foo_hidden_class->c_messlist) {

            error("name in use", 0);

            xx = (t_foo_hidden *)hidden->s_thing;

        xx = foo_hidden_new(hidden);

        hidden->s_thing = (t_object *)xx;

Essentially this looks up an object by name in the global max symbol 

table. If it doesn't exist, it creates a new one and associates it 

If you need more code snips or explanations, let me know.

On 07-04-24, at 1400, Luigi Castelli wrote:
> Hi there,
>
> I have an external called 'foo'.
> 20 instances of 'foo' have been created in a Max patch.
> 10 instances are in the main patch, the remaining 10 are in  
> subpatchers
> at various depths.
>
> Now, I need all 20 instances of 'foo' to output certain information in
> response to a message that may be received in just ONE instance of any
> 'foo' object.
>
> So, I am guessing I need a way to traverse all object instantiated  
> that
> belong to the class 'foo'.
>
> I did check the SDK of course, but I could not find anything  
> related to
> this.
>
> If someone could post an example or point me to some information about
> it, I would appreciate it.
>
I can't post a whole example, but the following method works for me:

create a boxed object (foo)
in the foo new routine, find or create a boxless object (foohelper)
keep a pointer to foohelper in foo
keep a linked list of boxed objects in foohelper
each time you create or delete a foo, update the linked list in  
foohelper, and delete foohelper when all the foos are deleted (i.e.  
reference counting)
keep global state in foohelper, and pass messages through as needed.

This may be overly complicated for your needs, depending on the state  
that needs to be shared. In my case, I'm sharing a single network  
socket across a bunch of objects, so it has to live in its own  
object. You may be able to get away with a single global linked list  
that you manage in the foo new/free methods if you don't require that  
much sharing between your objects.

	if (hidden != _sym_nothing && hidden->s_thing) {
		if (ob_messlist(hidden->s_thing) != foo_hidden_class->c_messlist) {
			error("name in use", 0);
			return NULL;
		} else {
			xx = (t_foo_hidden *)hidden->s_thing;
		}
	} else {
		xx = foo_hidden_new(hidden);
		hidden->s_thing = (t_object *)xx;
	}

Essentially this looks up an object by name in the global max symbol  
table. If it doesn't exist, it creates a new one and associates it  
with that symbol.

I implemented your suggestion and it works like a charm.

I don't need too much sharing between my objects so the simple global

Now I find myself iterating through the linked list a lot, so I was

wondering if - for the sake of efficiency - there is any difference

...or is there any reason why I should want one over the other ?

> On 07-04-24, at 1400, Luigi Castelli wrote:

> > 20 instances of 'foo' have been created in a Max patch.

> > 10 instances are in the main patch, the remaining 10 are in 

> > Now, I need all 20 instances of 'foo' to output certain information

> > response to a message that may be received in just ONE instance of

> > So, I am guessing I need a way to traverse all object instantiated 

> > I did check the SDK of course, but I could not find anything 

> > If someone could post an example or point me to some information

> I can't post a whole example, but the following method works for me:

> in the foo new routine, find or create a boxless object (foohelper)

> keep a linked list of boxed objects in foohelper

> each time you create or delete a foo, update the linked list in 

> foohelper, and delete foohelper when all the foos are deleted (i.e. 

> keep global state in foohelper, and pass messages through as needed.

> This may be overly complicated for your needs, depending on the state

> that needs to be shared. In my case, I'm sharing a single network 

> socket across a bunch of objects, so it has to live in its own 

> object. You may be able to get away with a single global linked list 

> that you manage in the foo new/free methods if you don't require that

> here is some code to find/create a hidden object:

I implemented your suggestion and it works like a charm.
I don't need too much sharing between my objects so the simple global
linked list solution is what I went for.

Now I find myself iterating through the linked list a lot, so I was
wondering if - for the sake of efficiency - there is any difference
between these two constructs:

for (p = head; p; p = p->next) {
    // do something
}

p = head;
while (p) {
     p = p->next;
}

> On 07-04-24, at 1400, Luigi Castelli wrote:
> > Hi there,
> >
> > I have an external called 'foo'.
> > 20 instances of 'foo' have been created in a Max patch.
> > 10 instances are in the main patch, the remaining 10 are in  
> > subpatchers
> > at various depths.
> >
> > Now, I need all 20 instances of 'foo' to output certain information
> in
> > response to a message that may be received in just ONE instance of
> any
> > 'foo' object.
> >
> > So, I am guessing I need a way to traverse all object instantiated 
>
> > that
> > belong to the class 'foo'.
> >
> > I did check the SDK of course, but I could not find anything  
> > related to
> > this.
> >
> > If someone could post an example or point me to some information
> about
> > it, I would appreciate it.
> >
> I can't post a whole example, but the following method works for me:
>
> create a boxed object (foo)
> in the foo new routine, find or create a boxless object (foohelper)
> keep a pointer to foohelper in foo
> keep a linked list of boxed objects in foohelper
> each time you create or delete a foo, update the linked list in  
> foohelper, and delete foohelper when all the foos are deleted (i.e.  
> reference counting)
> keep global state in foohelper, and pass messages through as needed.
>
> This may be overly complicated for your needs, depending on the state
>
> that needs to be shared. In my case, I'm sharing a single network  
> socket across a bunch of objects, so it has to live in its own  
> object. You may be able to get away with a single global linked list 
>
> that you manage in the foo new/free methods if you don't require that
>
> much sharing between your objects.
>
> here is some code to find/create a hidden object:
>
> 	t_symbol *hidden = gensym("foohidden");
>
> 	if (hidden != _sym_nothing && hidden->s_thing) {
> 		if (ob_messlist(hidden->s_thing) != foo_hidden_class->c_messlist) {
> 			error("name in use", 0);
> 			return NULL;
> 		} else {
> 			xx = (t_foo_hidden *)hidden->s_thing;
> 		}
> 	} else {
> 		xx = foo_hidden_new(hidden);
> 		hidden->s_thing = (t_object *)xx;
> 	}
>
> Essentially this looks up an object by name in the global max symbol 
>
> table. If it doesn't exist, it creates a new one and associates it  
> with that symbol.
>
> If you need more code snips or explanations, let me know.
>
> r.
>

On 07-04-24, at 2259, Luigi Castelli wrote:

> I implemented your suggestion and it works like a charm.

> I don't need too much sharing between my objects so the simple global

> linked list solution is what I went for.

> Now I find myself iterating through the linked list a lot, so I was

> wondering if - for the sake of efficiency - there is any difference

I would recommend (a) worrying about readability over efficiency, and 

to that end (b) looking at ext_linklist.h, and not do any of the low- 

On 07-04-24, at 2259, Luigi Castelli wrote:
> Thank you Jeremy and Ritchie,
>
> I implemented your suggestion and it works like a charm.
> I don't need too much sharing between my objects so the simple global
> linked list solution is what I went for.
>
> Now I find myself iterating through the linked list a lot, so I was
> wondering if - for the sake of efficiency - there is any difference
> between these two constructs:
>
I would recommend (a) worrying about readability over efficiency, and  
to that end (b) looking at ext_linklist.h, and not do any of the low- 
level linklist stuff yourself.

On Apr 24, 2007, at 11:25 PM, Ritchie Argue wrote:

> I would recommend (a) worrying about readability over efficiency, 

> and to that end (b) looking at ext_linklist.h, and not do any of 

Not to mention thread safety. If your linked list may be modified in 

both the low priority and high priority threads, you'll need to use 

some kind of thread safe locks (see ext_systhread.h and online 

documentation about threads and locks like the following sample 

The linklist calls take care of this for you. However, while they 

will work in a DSP perform method, you may not want to use these 

functions internal to a DSP perform method for performance reasons, 

in which case you might want to use some lighter weight means of 

achieving synchronization than OS supplied mutexes.

Though, as *always*, optimize last, and even then use profiling tools 

and focus on code which is the bottle neck. Worrying about whether a 

while loop or a for loop is more efficient is typically the least 

efficient use of your mind. On OS X, Apple's Shark is a great 

> I would recommend (a) worrying about readability over efficiency,  
> and to that end (b) looking at ext_linklist.h, and not do any of  
> the low-level linklist stuff yourself.

Not to mention thread safety. If your linked list may be modified in  
both the low priority and high priority threads, you'll need to use  
some kind of thread safe locks (see ext_systhread.h and online  
documentation about threads and locks like the following sample  
chapters from Modern Operating Systems: http://www.cs.vu.nl/~ast/ 
books/mos2/samples.html

The linklist calls take care of this for you. However, while they  
will work in a DSP perform method, you may not want to use these  
functions internal to a DSP perform method for performance reasons,  
in which case you might want to use some lighter weight means of  
achieving synchronization than OS supplied mutexes.

Though, as *always*, optimize last, and even then use profiling tools  
and focus on code which is the bottle neck. Worrying about whether a  
while loop or a for loop is more efficient is typically the least  
efficient use of your mind. On OS X, Apple's Shark is a great  
profiling tool.

Quote: Luigi Castelli wrote on Wed, 25 April 2007 07:59

----------------------------------------------------

> ...or is there any reason why I should want one over the other ?

According to the C-spec the two are identical. Two different ways of generating the same machine code. There is certainly no difference in efficiency.

Either construct can be made thread-safe.

The for-loop has a certain atomicity in its syntax that some people may prefer.

Quote: Luigi Castelli wrote on Wed, 25 April 2007 07:59
----------------------------------------------------
> for (p = head; p; p = p->next) {
>     // do something
> }
>
> and
>
> p = head;
> while (p) {
>      p = p->next;
> }
>
> ...or is there any reason why I should want one over the other ?

According to the C-spec the two are identical. Two different ways of generating the same machine code. There is certainly no difference in efficiency. 

Either construct can be made thread-safe. 

The for-loop has a certain atomicity in its syntax that some people may prefer.


first of all, thanks Peter for your explanation.

It seems from what Joshua and Ritchie are saying that I am better off

using the ext_linklist.h API to manage my linked list. That way I don't

have to worry about thread safety, and don't have to come up with my

own linked list functions. Makes sense...

Now, the reason why I didn't go with the ext_linklist.h API yet, is

because I am not sure if it provides the low level functionality I

need. To be more specific, in my code I am acually managing two linked

In various parts of the code I need to perform the following action:

Is nesting two linked list like that something possible with the

Or am I now better off implementing my own linked list functions and

deal with all the thread issues of the case ?

> Quote: Luigi Castelli wrote on Wed, 25 April 2007 07:59

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

> > ...or is there any reason why I should want one over the other ?

> According to the C-spec the two are identical. Two different ways of

> generating the same machine code. There is certainly no difference in

> Either construct can be made thread-safe. 

> The for-loop has a certain atomicity in its syntax that some people

> Peter Castine +--> Litter Power & Litter Bundle for

> iCE: Sequencing, Recording & Interface Building for Max/MSP 

It seems from what Joshua and Ritchie are saying that I am better off
using the ext_linklist.h API to manage my linked list. That way I don't
have to worry about thread safety, and don't have to come up with my
own linked list functions. Makes sense...

Now, the reason why I didn't go with the ext_linklist.h API yet, is
because I am not sure if it provides the low level functionality I
need. To be more specific, in my code I am acually managing two linked
lists.

for (a = a_head; a; a = a->next) {
    for (b = b_head; b; b = b->next) {
         // do something
    }
}

Is nesting two linked list like that something possible with the
ext_linklist.h API ?
Or am I now better off implementing my own linked list functions and
deal with all the thread issues of the case ?

>
> Quote: Luigi Castelli wrote on Wed, 25 April 2007 07:59
> ----------------------------------------------------
> > for (p = head; p; p = p->next) {
> >     // do something
> > }
> >
> > and
> >
> > p = head;
> > while (p) {
> >      p = p->next;
> > }
> >
> > ...or is there any reason why I should want one over the other ?
>
> ----------------------------------------------------
>
> According to the C-spec the two are identical. Two different ways of
> generating the same machine code. There is certainly no difference in
> efficiency. 
>
> Either construct can be made thread-safe. 
>
> The for-loop has a certain atomicity in its syntax that some people
> may prefer. 
> --
> --------------    http://www.bek.no/~pcastine/Litter/   
> -------------
> Peter Castine             +--> Litter Power & Litter Bundle for
> Jitter
>
> iCE:  Sequencing,  Recording & Interface  Building  for Max/MSP  
> Extremely cool   http://www.dspaudio.com/
>
>

On Apr 25, 2007, at 5:51 PM, Luigi Castelli wrote:

> Is nesting two linked list like that something possible with the

> Or am I now better off implementing my own linked list functions and

> deal with all the thread issues of the case ?

Do you mean a list of lists? Sure. the nodes of the list can be any 

object (or a pointer or integer masquerading as an object):

linklist_append(mainlist,(t_object *)sublist);

You might find the methodall or funall routines useful for iteration. 

If you have a specific question, feel free to post it with relevant 

> Is nesting two linked list like that something possible with the
> ext_linklist.h API ?
> Or am I now better off implementing my own linked list functions and
> deal with all the thread issues of the case ?

Do you mean a list of lists? Sure. the nodes of the list can be any  
object (or a pointer or integer masquerading as an object):

t_linklist *mainlist = linklist_new();
t_linklist *sublist = linklist_new();
linklist_append(mainlist,(t_object *)sublist);

You might find the methodall or funall routines useful for iteration.  
If you have a specific question, feel free to post it with relevant  
code.

Just for my own curiosity, does the ext_linklist API implement singly

linked or doubly linked lists under the hood ?

> On Apr 25, 2007, at 5:51 PM, Luigi Castelli wrote:

> > Is nesting two linked list like that something possible with the

> > Or am I now better off implementing my own linked list functions

> > deal with all the thread issues of the case ?

> Do you mean a list of lists? Sure. the nodes of the list can be any 

> object (or a pointer or integer masquerading as an object):

> linklist_append(mainlist,(t_object *)sublist);

> You might find the methodall or funall routines useful for iteration.

> If you have a specific question, feel free to post it with relevant 

Just for my own curiosity, does the ext_linklist API implement singly
linked or doubly linked lists under the hood ?

>
> On Apr 25, 2007, at 5:51 PM, Luigi Castelli wrote:
>
> > Is nesting two linked list like that something possible with the
> > ext_linklist.h API ?
> > Or am I now better off implementing my own linked list functions
> and
> > deal with all the thread issues of the case ?
>
> Do you mean a list of lists? Sure. the nodes of the list can be any  
> object (or a pointer or integer masquerading as an object):
>
> t_linklist *mainlist = linklist_new();
> t_linklist *sublist = linklist_new();
> linklist_append(mainlist,(t_object *)sublist);
>
> You might find the methodall or funall routines useful for iteration.
>
> If you have a specific question, feel free to post it with relevant  
> code.
>
> -Joshua 
>

upon more careful reading of your answer I am not entirely sure I can

I don't really mean a list of lists, but a way of nesting iterations

how would you do the following with the ext_linklist.h API ?

obj = myobject_list_head; // point to head of list 1

        outlet_anything(obj->out, _sym_clear, 0, 0L);

        dev = mydevice_list_head; // point to head of list 2

            atom_setsym(a, gensym(dev->name));

            outlet_anything(obj->out, _sym_append, 1, a);

If you can confirm to me that the above if possible with the

ext_linklist.h API I will be happy to use it. Otherwise I am gonna have

upon more careful reading of your answer I am not entirely sure I can
do what I want.
I don't really mean a list of lists, but  a way of nesting iterations
of linked lists.

getting all object that belong to one class