volker böhm

i'm trying to send data to a namedObject from within a mxj class, 

which is working fine as long as the receiving object is in the same 

but i can't figure out how to proceed if the named object is in a 

different patcher (not a subpatcher, but a completely independent max 

patch, which is actually loaded dynamically with [pcontol] ).

is it possible to connect to a patcher, if i only know the window title?

i looked at the getPatcher() method of the Max Window class, without 

or maybe something analog to getAllBoxes(), like "getAllPatchers()", 

another possible way would be to talk to a regular max [receive] 

object from within mxj, because of it's global scope, but something 

in the back of my head tells me, that this is not possible. wrong? 

        _p = this.getParentPatcher();        // how can i change this to 

        MaxBox b = _p.getNamedBox("myNum");

        b.send(i);        

hi,
i'm trying to send data to a namedObject from within a mxj class,  
which is working fine as long as the receiving object is in the same  
patcher as the mxj object.
but i can't figure out how to proceed if the named object is in a  
different patcher (not a subpatcher, but a completely independent max  
patch, which is actually loaded dynamically with [pcontol] ).
is it possible to connect to a patcher, if i only know the window title?
i looked at the getPatcher() method of the Max Window class, without  
any further enlightenment...
or maybe something analog to getAllBoxes(), like "getAllPatchers()",  
to cycle through all available patchers?

another possible way would be to talk to a regular max [receive]  
object from within mxj, because of it's global scope, but something  
in the back of my head tells me, that this is not possible. wrong?  
(would be nice...)
thanks.
volker.

public class namedObj extends MaxObject
{

	namedObj (Atom[] a) {	
		_p = this.getParentPatcher();		// how can i change this to  
reference another patcher?
	}

	public void ss( int i ) {
		MaxBox b = _p.getNamedBox("myNum");
		b.send(i);		
	}
}


talk-to-namedobject-in-different-patcher

What I would do is put an instance of an mxj class in each patcher.

Each instance would reference its parent patcher. Each instance would

register itself in a global static table. That way they could all 

When a patcher is closed I would remove the instance from the table.

I am sure there is more than one way to do what you want but this is 

What I would do is put an instance of an mxj class in each patcher.
Each instance would reference its parent patcher. Each instance would
register itself in a global static table. That way they could all  
talk to each other.
When a patcher is closed I would remove the instance from the table.

I am sure there is more than one way to do what you want but this is  
what came
to mind for me.

ok, thanks, topher.
will investigate in that direction.
vol.


hi topher, could you be a little more explicit in how you would 

actually execute this plan (i.e. the global static table part)? I 

will need to do something similar in the near future, and the only 

way I can figure to do it cleanly is to use a boxless object but 

(afaik) that hasn't been made available yet in the mxj sdk.

I have a hack that works, but it involves people putting things in 

the c74/java/lib folder, which I presume you would rather I didn't 

do. will this be forthcoming in a future version of the mxj sdk, or 

am I approaching this from the wrong angle completely?

hi topher, could you be a little more explicit in how you would  
actually execute this plan (i.e. the global static table part)? I  
will need to do something similar in the near future, and the only  
way I can figure to do it cleanly is to use a boxless object but  
(afaik) that hasn't been made available yet in the mxj sdk.

I have a hack that works, but it involves people putting things in  
the c74/java/lib folder, which I presume you would rather I didn't  
do. will this be forthcoming in a future version of the mxj sdk, or  
am I approaching this from the wrong angle completely?

On Apr 9, 2006, at 7:46 PM, ritchie wrote:

> hi topher, could you be a little more explicit in how you would 

> actually execute this plan (i.e. the global static table part)?

well all the mxj instances are running in the same JVM so if a 

variable is declared static, a hashtable for instance, all instances will have the same reference.

> I have a hack that works, but it involves people putting things in 

> the c74/java/lib folder, which I presume you would rather I didn't 

> do. will this be forthcoming in a future version of the mxj sdk, or 

> am I approaching this from the wrong angle completely?

why not?it is fine to put things in that folder. it is automatically 

searched upon JVM startup for any jars so it makes the most sense

> hi topher, could you be a little more explicit in how you would  
> actually execute this plan (i.e. the global static table part)?

well all the mxj instances are running in the same JVM so if a  
variable is declared static, a hashtable for instance, all instances will have the same reference.

> I have a hack that works, but it involves people putting things in  
> the c74/java/lib folder, which I presume you would rather I didn't  
> do. will this be forthcoming in a future version of the mxj sdk, or  
> am I approaching this from the wrong angle completely?

why not?it is fine to put things in that folder. it is automatically  
searched upon JVM startup for any jars so it makes the most sense
to put jarred code there.

On 06-04-10, at 0509, topher lafata wrote:

> well all the mxj instances are running in the same JVM so if a 

> variable is declared static, a hashtable for instance, all instances

> why not?it is fine to put things in that folder. it is 

> automatically searched upon JVM startup for any jars so it makes 

the only reason I put stuff there is to access package-private 

methods/data in com.cycling74.max.*. presumably the access levels are 

set for a reason, no? if not, could you make mxjObjectWasDeleted() 

package-private instead of object-private as well? it would make my 

On 06-04-10, at 0509, topher lafata wrote:
>
> well all the mxj instances are running in the same JVM so if a  
> variable is declared static, a hashtable for instance, all instances
> will have the same reference.
>
good to know.

> why not?it is fine to put things in that folder. it is  
> automatically searched upon JVM startup for any jars so it makes  
> the most sense
> to put jarred code there.
>
the only reason I put stuff there is to access package-private  
methods/data in com.cycling74.max.*. presumably the access levels are  
set for a reason, no? if not, could you make mxjObjectWasDeleted()  
package-private instead of object-private as well? it would make my  
hack a little cleaner. thanks.

> the only reason I put stuff there is to access package-private 

> methods/data in com.cycling74.max.*. presumably the access levels 

> are set for a reason, no? if not, could you make mxjObjectWasDeleted 

> () package-private instead of object-private as well? it would make 

couldn't you just add another method to your object. 

registerNotifyDeleted(Object o) or something like that.

Than you could notify everyone that registed with that instance in 

Just an idea. There is always more than one way to skin a cat.

>>
> the only reason I put stuff there is to access package-private  
> methods/data in com.cycling74.max.*. presumably the access levels  
> are set for a reason, no? if not, could you make mxjObjectWasDeleted 
> () package-private instead of object-private as well? it would make  
> my hack a little cleaner. thanks.

couldn't you just add another method to your object.  
registerNotifyDeleted(Object o) or something like that.
Than you could notify everyone that registed with that instance in  
your overridden mxjObjectWasDeleted.
Just an idea. There is always more than one way to skin a cat.
Topher


On 06-04-10, at 2259, topher lafata wrote:

>> the only reason I put stuff there is to access package-private 

>> methods/data in com.cycling74.max.*. presumably the access levels 

>> are set for a reason, no? if not, could you make 

>> mxjObjectWasDeleted() package-private instead of object-private as 

>> well? it would make my hack a little cleaner. thanks.

> couldn't you just add another method to your object. 

> registerNotifyDeleted(Object o) or something like that.

> Than you could notify everyone that registed with that instance in 

> Just an idea. There is always more than one way to skin a cat.

the problem is that I can't call mxjObjectWasDeleted() from whatever 

I write (overridden method or otherwise), and I can't implement my 

own mxjObjectWasDeleted() fully w/o greater access to the object- 

private member variables it deals with. granted I think I get enough 

of them to get the job done, but it's not a very faithful reproduction:

* for this to work it must live in c74/java/lib

public abstract class MaxBoxlessObject extends MaxObject {

     * expose public version of mxjObjectWasDeleted()

     * can't get at any private stuff in MaxObject, so

     * this is the best we can do. presumably all the

     * instance variables listed will let go when this

     * object is garbage collected anyway, no?

        MaxContext.unregister(this);

        setName(null); // public equivalent

        declareInlets(NO_INLETS); // next best thing

        declareOutlets(NO_OUTLETS); // next best thing. what about info 

                                    // we can't mess with it once it's been created..

        setInletAssist(null); // public equivalent

        setOutletAssist(null); // public equivalent

        // this should almost always be null it seems,

        // unless delete() gets called in the middle of

        // doing something else which seems impossible.

really it seems to me that the important things in here are 

MaxContext.unregister(this) and notifyDeleted(), but (a) you go to 

all the trouble to set everything else to null (or jad is telling 

stories), and (b) perhaps in future versions there'll be some more 

critical stuff in there that I similarly can't deal with. my solution 

seems a little fragile from my point of view.

On 06-04-10, at 2259, topher lafata wrote:
>>>
>> the only reason I put stuff there is to access package-private  
>> methods/data in com.cycling74.max.*. presumably the access levels  
>> are set for a reason, no? if not, could you make  
>> mxjObjectWasDeleted() package-private instead of object-private as  
>> well? it would make my hack a little cleaner. thanks.
>
> couldn't you just add another method to your object.  
> registerNotifyDeleted(Object o) or something like that.
> Than you could notify everyone that registed with that instance in  
> your overridden mxjObjectWasDeleted.
> Just an idea. There is always more than one way to skin a cat.
>
the problem is that I can't call mxjObjectWasDeleted() from whatever  
I write (overridden method or otherwise), and I can't implement my  
own mxjObjectWasDeleted() fully w/o greater access to the object- 
private member variables it deals with. granted I think I get enough  
of them to get the job done, but it's not a very faithful reproduction:

/**
* boxless max object wrapper hack by r.
*
* for this to work it must live in c74/java/lib
*/
public abstract class MaxBoxlessObject extends MaxObject {
	/**
	 * expose public version of mxjObjectWasDeleted()
	 * can't get at any private stuff in MaxObject, so
	 * this is the best we can do. presumably all the
	 * instance variables listed will let go when this
	 * object is garbage collected anyway, no?
	 */
	public void delete() {
		MaxContext.unregister(this);
         notifyDeleted();

//        mName = null;
		setName(null);              // public equivalent

//        mInlets = null;
		declareInlets(NO_INLETS);   // next best thing

//        mOutlets = null;
		declareOutlets(NO_OUTLETS); // next best thing. what about info  
outlet? seems like
									// we can't mess with it once it's been created..

//        mInletAssist = null;
		setInletAssist(null);       // public equivalent

//        mOutletAssist = null;
		setOutletAssist(null);      // public equivalent

//        _attributes = null;
		// stumped

//        _flash_watch = null;
		// this should almost always be null it seems,
		// unless delete() gets called in the middle of
		// doing something else which seems impossible.

//        _source_editor = null;
		// stumped
	}
}

really it seems to me that the important things in here are  
MaxContext.unregister(this) and notifyDeleted(), but (a) you go to  
all the trouble to set everything else to null (or jad is telling  
stories), and (b) perhaps in future versions there'll be some more  
critical stuff in there that I similarly can't deal with. my solution  
seems a little fragile from my point of view.

talk to namedObject in different patcher