Forums > Java

talk to namedObject in different patcher

April 7, 2006 | 2:41 pm

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
{

private MaxPatcher _p = null;

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


April 7, 2006 | 6:32 pm

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.

Topher


April 8, 2006 | 3:34 pm

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


April 10, 2006 | 2:45 am

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?

best regards,
r.


April 10, 2006 | 8:09 am

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
to put jarred code there.

topher


April 11, 2006 | 12:51 am

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.

r.


April 11, 2006 | 1:58 am

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


April 11, 2006 | 2:24 am

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:

package com.cycling74.max;

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

// WATCHME = null;
// stumped

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

best regards,
r.


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