Forums > Java

what is lame about mxj

February 6, 2006 | 9:11 pm

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[][])

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?

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.

OK. Thanks.
Topher


February 7, 2006 | 1:34 am

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

methods/properties of MaxBox’s:

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?

Thanks for your work!

-jim

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


February 7, 2006 | 3:35 am

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


February 7, 2006 | 8:36 am

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.

Cheers

Nik


February 7, 2006 | 11:43 am

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.

– N.

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


February 7, 2006 | 11:46 am

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

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

– N.

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


February 7, 2006 | 11:48 am

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

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


February 7, 2006 | 11:51 am

Hi,

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.

Thanks, that would be great. :-)

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

Cheers

Nik


February 7, 2006 | 12:24 pm

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


February 7, 2006 | 11:54 pm

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.

int err = 0;

JNI_PUSH_LOCAL_FRAME

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;

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.

Topher



jbm
February 10, 2006 | 8:30 am

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!

J.


February 10, 2006 | 8:41 am

Hi Topher,

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.

Cheers

Nik


February 10, 2006 | 3:28 pm

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

Ben



jbm
February 10, 2006 | 4:41 pm

…ahh… yeah, I know…

I really have to get Jitter, don’t I?

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

cheers,

J.



f.e
February 12, 2006 | 8:37 am

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…

best

f.e


February 12, 2006 | 10:25 am

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.

wes


February 13, 2006 | 3:19 am

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?


Owen


February 13, 2006 | 3:22 pm

Hi Owen,

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?

Ben


February 16, 2006 | 11:46 am

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…



jbm
May 10, 2006 | 10:23 am

Okay, 2 things…

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.

J.

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


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