what is lame about mxj

    topher lafata
    Feb 06 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
    • maxmsp@tweeg.net
      Feb 07 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.
    • topher lafata
      Feb 07 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
    • Niklas Saers
      Feb 07 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
    • nick rothwell / cassiel
      Feb 07 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:// www.cassiel.com
    • nick rothwell / cassiel
      Feb 07 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:// www.cassiel.com
    • nick rothwell / cassiel
      Feb 07 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:// www.cassiel.com
    • Niklas Saers
      Feb 07 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
    • volker böhm
      Feb 07 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.
    • topher lafata
      Feb 07 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
      Feb 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.
    • Niklas Saers
      Feb 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
    • projects
      Feb 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
      Feb 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
      Feb 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
    • Wesley Smith
      Feb 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
    • Owen Green
      Feb 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
    • projects
      Feb 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
    • Owen Green
      Feb 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...