topher lafata

I am wondering if you have any things that really bother you

about mxj or the mxj API. The only thing I am not interested in

hearing about right now is that swing on OS X doesn't always work as anticipated. I am talking about more general things that something could actually be done about without resorting to months of black box digging.

For instance, would it be useful to have a compound outlet method

to try and get around some of the JNI boundary crossing overhead in instances where you wish to send a lot of messages at once?

outlet_high(int index, Atom messages[][])

At some point I would also like to write something similar to jsui for java users so people can use all the normal java 2d stuff to make UI or graphics stuff. In a nutshell the drawing would probably be driven by max. So you would have a method called draw(Graphics2D g) that would be called at appropriate times etc.

This is the sort of thing I am talking about. Any other ideas or problems?

My own approach to this problem at one point was to begin development on an external called cfunk which works pretty much

like mxj except it loads actually c code modules, called funklets, developed in something similar to [mxj quickie]. I might get an opportunity to get back to this at some point. It is pretty cool to pop open an editor window and write message handler in C without having to worry about any configuration and still having access to the whole max api.If that does happen it would be cool to port some of the more useful java classes to C so we could have access to all the things we like about java in this other paradigm Strings,Vectors,Hashtables etc. with the same interface they have in java.

Hi All,
I am wondering if you have any things that really bother you
about mxj or the mxj API. The only thing I am not interested in
hearing about right now is that swing on OS X doesn't always work as anticipated. I am talking about more general things that something could actually be done about without resorting to months of black box digging. 

For instance, would it be useful to have a compound outlet method
to try and get around some of the JNI boundary crossing overhead in instances where you wish to send a lot of messages at once?
outlet(int index, Atom messages[][])
outlet_high(int index, Atom messages[][])

As an aside...
My own approach to this problem at one point was to begin development on an external called cfunk which works pretty much
like mxj except it loads actually c code modules, called funklets, developed in something similar to [mxj quickie]. I might get an opportunity to get back to this at some point. It is pretty cool to pop open an editor window and write message handler in C without having to worry about any configuration and still having access to the whole max api.If that does happen it would be cool to port some of the more useful java classes to C so we could have access to all the things we like about java in this other paradigm Strings,Vectors,Hashtables etc. with the same interface they have in java.

what-is-lame-about-mxj

As I and other people have begged before... the following would be 

String getArguments() //the whole thing, including the object name

MaxBox[] inletConnectedFrom(int inletindex)

MaxBox[] outletConnectedTo(int outletindex)

And also: it would be great to have access to fftinfo~-like stuff within 

p.s. good idea for the outlet dumping methods. it would be great for 

Topher,
  As I and other people have begged before... the following would be 
awesome.

int getInlets()
int getOutlets()
String getArguments() //the whole thing, including the object name
MaxBox[] inletConnectedFrom(int inletindex)
MaxBox[] outletConnectedTo(int outletindex)

And also: it would be great to have access to fftinfo~-like stuff within 
an MXJ.  Would this be difficult?

p.s. good idea for the outlet dumping methods.  it would be great for 
data intensive objects.


I guess the short answer is that these are nontrivial things to 

they would be there already. This also explains why they are not 

I am not saying it will never happen but nothing probably in short 

I guess the short answer is that these are nontrivial things to 
implement  otherwise
they would be there already. This also explains why they are not 
present in js as well.
I am not saying it will never happen but nothing probably in short 
order. I know it sucks.
Sorry.
Topher


mxj is one of the things I use the most with Max/MSP. My two issues are on

reloading and debug messages. To take the debugging messages first, I still

haven't been able to make a standalone application that doesn't give me the

dreaded "unable to init mxj classloader. ERROR: -10", even though we've

talked much about it by email. If there was some flag I could turn on to

make it spit out loads of debug messages (log4j is great :) ) then I'm sure

it would be easier to track down these errors.

On the reloading, when programming an object I make mistakes. I haven't

figured out a good way of reiniting the object other than to edit the box or

open/close the patch. I'd love to be able to send a "reload" message or

Hi Topher,
mxj is one of the things I use the most with Max/MSP. My two issues are on
reloading and debug messages. To take the debugging messages first, I still
haven't been able to make a standalone application that doesn't give me the
dreaded "unable to init mxj classloader. ERROR: -10", even though we've
talked much about it by email. If there was some flag I could turn on to
make it spit out loads of debug messages (log4j is great :) ) then I'm sure
it would be easier to track down these errors.

On the reloading, when programming an object I make mistakes. I haven't
figured out a good way of reiniting the object other than to edit the box or
open/close the patch. I'd love to be able to send a "reload" message or
something similar while developing.

On 7 Feb 2006, at 08:36, Niklas Saers wrote:

> My two issues are on reloading and debug messages.

Certainly there are some subtle issues with the classloading stuff. 

For example, I'm using log4j for my logging, and for some reason, 

after every _zap I get an additional line of output for every message 

I log. (And log4j is in the static classpath, not the dynamic one.)

Anyway, that aside (and it's a minor thing, no doubt a log4j funny, 

that I'll track down at some stage), I guess the only thing that 

comes to mind is the untidiness of logging (System.out.println(), post 

(), etc.) vs. sending diagnostic messages via an outlet(). I'd quite 

like to be able to make log4j send stuff to outlets. But again, it's 

something that I'll tackle when it becomes sufficiently annoying.

nick rothwell -- composition, systems, performance -- 

Certainly there are some subtle issues with the classloading stuff.  
For example, I'm using log4j for my logging, and for some reason,  
after every _zap I get an additional line of output for every message  
I log. (And log4j is in the static classpath, not the dynamic one.)

Anyway, that aside (and it's a minor thing, no doubt a log4j funny,  
that I'll track down at some stage), I guess the only thing that  
comes to mind is the untidiness of logging (System.out.println(), post 
(), etc.) vs. sending diagnostic messages via an outlet(). I'd quite  
like to be able to make log4j send stuff to outlets. But again, it's  
something that I'll tackle when it becomes sufficiently annoying.

   nick rothwell -- composition, systems, performance -- http:// 
www.cassiel.com


> On the reloading, when programming an object I make mistakes. I 

> haven't figured out a good way of reiniting the object other than 

> to edit the box or open/close the patch. I'd love to be able to 

> send a "reload" message or something similar while developing.

Actually, I can give you something for this. It's an mxj object which 

does some scripting: it takes an object name and attributes as 

arguments. You send it a "reload" message and it deletes the named 

target, puts out a _zap, and reinstantiates it. You need to name the 

upstream and downstream object too - so I usually put a [t l] above 

But yes, native support for this in MXJ would be nice. Also, having 

MXJ track changes to all class files (not just the MXJ ones directly) 

would be nice, but that's probably more complicated.

> On the reloading, when programming an object I make mistakes. I  
> haven't figured out a good way of reiniting the object other than  
> to edit the box or open/close the patch. I'd love to be able to  
> send a "reload" message or something similar while developing.

Actually, I can give you something for this. It's an mxj object which  
does some scripting: it takes an object name and attributes as  
arguments. You send it a "reload" message and it deletes the named  
target, puts out a _zap, and reinstantiates it. You need to name the  
upstream and downstream object too - so I usually put a [t l] above  
and below.

But yes, native support for this in MXJ would be nice. Also, having  
MXJ track changes to all class files (not just the MXJ ones directly)  
would be nice, but that's probably more complicated.

On 6 Feb 2006, at 21:11, topher lafata wrote:

> My own approach to this problem at one point was to begin 

> development on an external called cfunk which works pretty much

> like mxj except it loads actually c code modules, called funklets, 

> developed in something similar to [mxj quickie].

As an aside, I've been looking at integration of Groovy (

groovy.codehaus.org/) into MXJ. I have it kind-of working, but the 

linkage is a bit messy. Groovy is a nice little language, rather 

JavaScript like, with Java reflection and bean properties integrated, 

but semantically it's still a bit of a moving target.

> My own approach to this problem at one point was to begin  
> development on an external called cfunk which works pretty much
> like mxj except it loads actually c code modules, called funklets,  
> developed in something similar to [mxj quickie].

As an aside, I've been looking at integration of Groovy (http:// 
groovy.codehaus.org/) into MXJ. I have it kind-of working, but the  
linkage is a bit messy. Groovy is a nice little language, rather  
JavaScript like, with Java reflection and bean properties integrated,  
but semantically it's still a bit of a moving target.

Actually, I can give you something for this. It's an mxj object which

> does some scripting: it takes an object name and attributes as

> arguments. You send it a "reload" message and it deletes the named

> target, puts out a _zap, and reinstantiates it. You need to name the

> upstream and downstream object too - so I usually put a [t l] above

But yes, native support for this in MXJ would be nice. Also, having

> MXJ track changes to all class files (not just the MXJ ones directly)

> would be nice, but that's probably more complicated.

I think Tomcat does this by keeping track of the changedate of the file and

then just polling every now and then and sending a message to the log when a

Actually, I can give you something for this. It's an mxj object which
> does some scripting: it takes an object name and attributes as
> arguments. You send it a "reload" message and it deletes the named
> target, puts out a _zap, and reinstantiates it. You need to name the
> upstream and downstream object too - so I usually put a [t l] above
> and below.

But yes, native support for this in MXJ would be nice. Also, having
> MXJ track changes to all class files (not just the MXJ ones directly)
> would be nice, but that's probably more complicated.

I think Tomcat does this by keeping track of the changedate of the file and
then just polling every now and then and sending a message to the log when a
class is reloaded

> You send it a "reload" message and it deletes the named target, 

> puts out a _zap, and reinstantiates it.

actually i never clearly understood why i should be using "_zap" (as 

far as i can remeber it's meaning/necessity has at least changed once 

when i recompile a class that i'm already using in a patch, i simply 

retype its name (or simply one character of it) and the recompiled 

class will be loaded - and i am ready to go.

> You send it a "reload" message and it deletes the named target,  
> puts out a _zap, and reinstantiates it.

actually i never clearly understood why i should be using "_zap" (as  
far as i can remeber it's meaning/necessity has at least changed once  
in mxj's live time).
when i recompile a class that i'm already using in a patch, i simply  
retype its name (or simply one character of it) and the recompiled  
class will be loaded - and i am ready to go.
so what is _zap good for?
thanks for clarifications.
volker.


The stuff that is failing for youyr standalones is all in C

so the log4j stuff wouldnt help much. Once again her is the part where that error is coming from.

    s_loader_class      = MXJ_JNI_CALL(env,FindClass)(env,"com/cycling74/max/MXJClassLoader ");

    s_loader_class = MXJ_JNI_CALL(env,NewGlobalRef)(env,s_loader_class);

So it seems like it is not finding max.jar for some reason. I would like to track this down though. If there was a really simple example of a standalone not working on windows. LIke something that just had one java class I can take a look at it on windows when i get a chance and try to track down your problem.

As far as the reloading goes I would like to do something like autowatch in the js object. Not sure when but it seems useful. The other part of it which is sort of a pain and is in reference to nicks comment is figuring out a way to track dependencies so if you change a class that is not the actual mxj class it will still be reloaded upon change. "zap" was added back into the mix as a workaround for this latter case.

The stuff that is failing for youyr standalones is all in C
so the log4j stuff wouldnt help much. Once again her is the part where that error is coming from.

	s_loader_class 	   = MXJ_JNI_CALL(env,FindClass)(env,"com/cycling74/max/MXJClassLoader ");
	s_loader_class     = MXJ_JNI_CALL(env,NewGlobalRef)(env,s_loader_class);
	err = checkException(env);
	if(err)return -10;

I just wanted to chime in on this and say YES!!!

I would LOVE a Java-based, jsui-like system. I've been on deadlines lately, and thus have done very little coding, but trying to build some UI stuff in Java was next on my "to do" list, so I'd be excited to try something like this out. On that note, if you do pursue this, I'd be happy to do some testing for you. ([edit] -- In what object would the actual drawing be done? LCD? Or would it access a jsui object directly?)

And the cfunk idea sounds very cool, as well. Though, it sounds like a pretty big project to me... But, if I understand it correctly, the idea of being able to access the Max api directly from a Max object (without worrying about initializing, compiling, etc., "real" externals) would be extremely handy!

> so the log4j stuff wouldnt help much. Once again her is the part where

Ah, I was under the impression that it was on the java-side of the bridge.

Thanks for clearing this up, and explaining what the error means.

So it seems like it is not finding max.jar for some reason. I would like to

> track this down though. If there was a really simple example of a standalone

> not working on windows. LIke something that just had one java class I can

> take a look at it on windows when i get a chance and try to track down your

I'm sorry, but all my work is on OS X. If I can supply anything from OS X,

including source and a description of what I do, I'd love to help. :-)

As far as the reloading goes I would like to do something like autowatch in

> the js object. Not sure when but it seems useful.

Thanks. :-) From my development work the entire thing is recompiled when

dependencies are changed, so I don't know how big the dependency problem is.

The stuff that is failing for youyr standalones is all in C
> so the log4j stuff wouldnt help much. Once again her is the part where
> that error is coming from.

Ah, I was under the impression that it was on the java-side of the bridge.
Thanks for clearing this up, and explaining what the error means.

So it seems like it is not finding max.jar for some reason. I would like to
> track this down though. If there was a really simple example of a standalone
> not working on windows. LIke something that just had one java class I can
> take a look at it on windows when i get a chance and try to track down your
> problem.

I'm sorry, but all my work is on OS X. If I can supply anything from OS X,
including source and a description of what I do, I'd love to help. :-)

As far as the reloading goes I would like to do something like autowatch in
> the js object. Not sure when but it seems useful.

Thanks. :-) From my development work the entire thing is recompiled when
dependencies are changed, so I don't know how big the dependency problem is.

> I would LOVE a Java-based, jsui-like system.

Jitter is such an animal, and the fact that the openGL drawing is

hardware accelerated is a pretty important bonus!

Jitter is such an animal, and the fact that the openGL drawing is
hardware accelerated is a pretty important bonus!

I guess I'm going to have to look up the $$$ again.

I haven't checked it out in quite a while.

I guess I'm going to have to look up the $$$ again.
I haven't checked it out in quite a while.

dear Topher, indeed, a "reload" would be appreciated. The _zap thing 

never worked for me (or i didn't understand how it is supposed to work too).

As a suggestion : the thing that drive me crazy with mxj is that we 

can't explore the whole max patch easily looking for an object (have to 

dig then go up again), and we can't send/forward all kind of messages to 

any named object everywhere in the patch. I'm sure it's not easy to 

dear Topher, indeed, a "reload" would be appreciated. The _zap thing 
never worked for me (or i didn't understand how it is supposed to work too).

As a suggestion : the thing that drive me crazy with mxj is that we 
can't explore the whole max patch easily looking for an object (have to 
dig then go up again), and we can't send/forward all kind of messages to 
any named object everywhere in the patch. I'm sure it's not easy to 
implement, so we may do without...

This is kind of a pain, but really not that bad. If you name your

objects, it's really easy to access them. I beleive (but could be

wrong) that the patcher is modelled as a linked list, so iterating

through it is understandable. If you name your objects, you can

circumvent this by doing a symbol lookup. Then, you can store a

reference to it in your mxj and not have to worry about finding it

again. Once you have that, you can very easily send messages to the

This is kind of a pain, but really not that bad.  If you name your
objects, it's really easy to access them.  I beleive (but could be
wrong) that the patcher is modelled as a linked list, so iterating
through it is understandable.  If you name your objects, you can
circumvent this by doing a symbol lookup.  Then, you can store a
reference to it in your mxj and not have to worry about finding it
again.  Once you have that, you can very easily send messages to the
object.

No, but the recent singing of praises for eclipse's wonderful 

refactoring gizmos gave me a thought. If it were possible to load 

patcher files into instances of MaxPatcher, decoupled from the max 

environment itself, what would be the scope for developing either handy 

batch process things for patchers or, more ambitiously, augmentations to 

the max environment of eclipsesque coolness?

No, but the recent singing of praises for eclipse's wonderful 
refactoring gizmos gave me a thought. If it were possible to load 
patcher files into instances of MaxPatcher, decoupled from the max 
environment itself, what would be the scope for developing either handy 
batch process things for patchers or, more ambitiously, augmentations to 
the max environment of eclipsesque coolness?

Max programming doesn't have the same rigid syntax of Java

programming, so I'm not sure exactly what kind of refactoring could be

accomplished. Can you give us an example of what you are imagining?

Max programming doesn't have the same rigid syntax of Java
programming, so I'm not sure exactly what kind of refactoring could be
accomplished.  Can you give us an example of what you are imagining?

I didn't have anything specific in mind, beyond a vague notion that by 

keeping track of multiple patchers' contents there would be scope for 

some higher level abstraction of, say, message flow between patches. 

Also things like dependency tracking, an abstraction Doclet, serialized 

I didn't have anything specific in mind, beyond a vague notion that by 
keeping track of multiple patchers' contents there would be scope for 
some higher level abstraction of, say, message flow between patches. 
Also things like dependency tracking, an abstraction Doclet, serialized 
patcher instances...


I just lost a bunch of work because I unknowingly had two mxj editor windows open. I made changes to one, saved, then closed it. I saw the other window, and before I noticed what actual file it was, I habitually did command-S and over-wrote all my work! VERY frustrating. This could be prevented by making sure only one window at a time could have the same file open... I think most text editors are idiot-proofed in this way(?) No? In other words, save me from myself!

Also, I'd still love to be able to scroll with my mouse in the mxj editor.

I guess most people are developing in eclipse or something, but I haven't gone through that whole setup yet. Besides, the built-in editor/compiler should be a perfectly good option for most situations.

[ edit ] Oh, the other way this could have been avoided, maybe, is if the editor windows appeared in the "Window" menu... but I seem to remember you mentioning that this was a real pain...

I just lost a bunch of work because I unknowingly had two mxj editor windows open. I made changes to one, saved, then closed it. I saw the other window, and before I noticed what actual file it was, I habitually did command-S and over-wrote all my work! VERY frustrating. This could be prevented by making sure only one window at a time could have the same file open... I think most text editors are idiot-proofed in this  way(?) No? In other words, save me from myself! 

[ edit ] Oh, the other way this could have been avoided, maybe, is if the editor windows appeared in the "Window" menu... but I seem to remember you mentioning that this was a real pain...


what is lame about mxj