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.