Thijs Koerselman

I'm building multiple jitter objects which connect to one another using the

findregistered function. The name of the object to link to is set by an

attribute value. My problem is that the order of the objects instantiated in

my patch is crucial to whether another object is able to find it (when its

I'm wondering if anybody knows a solution that doesn't involve manually

controlling some kind of init sequence from within the max patch. Scripting

every object in the right order is a solution, but I want to be able to use

* the data object acts as a server and contains all the data for the data

* analysis modules link to the data using findregistererd and get a pointer

* visualization modules link to an abritrary analysis module (using

findregistered as well) and get a pointer to the analysis output data.

All of the objects are using the same shared library.

Is there a way to solve the order of linkage using either the Max/Jitter API

I'm building multiple jitter objects which connect to one another using the
findregistered function. The name of the object to link to is set by an
attribute value. My problem is that the order of the objects instantiated in
my patch is crucial to whether another object is able to find it (when its
attributes are processed on load).

I'm wondering if anybody knows a solution that doesn't involve manually
controlling some kind of init sequence from within the max patch. Scripting
every object in the right order is a solution, but I want to be able to use
them in static patches as well.

* the data object acts as a server and contains all the data for the data
analysis modules.
* analysis modules link to the data using findregistererd and get a pointer
to the data structure.
* visualization modules link to an abritrary analysis module (using
findregistered as well) and get a pointer to the analysis output data.

Is there a way to solve the order of linkage using either the Max/Jitter API
or the shared library?

init-routine-for-server-client-linking

Can use loadbang, or lazy registration. We use the latter for Jitter 

OpenGL for example. We try to resolve upon first draw.

Can use loadbang, or lazy registration. We use the latter for Jitter  
OpenGL for example. We try to resolve upon first draw.

> Can use loadbang, or lazy registration. We use the latter for Jitter

> OpenGL for example. We try to resolve upon first draw.

Thanks I'll do the lazy registration since I want to script the objects as

well. I need to process them in sequence anyway because they rely on their

server data, so lazy registration will work fine I think.

On 3/14/07, Joshua Kit Clayton  wrote:
>
>
> Can use loadbang, or lazy registration. We use the latter for Jitter
> OpenGL for example. We try to resolve upon first draw.

Thanks I'll do the lazy registration since I want to script the objects as
well. I need to process them in sequence anyway because they rely on their
server data, so lazy registration will work fine I think.

init routine for server / client linking