Processing in mxj

May 23, 2007 at 12:29pm

Processing in mxj

Has anybody managed to get a Processing window to load from mxj? Is it even possible? It feels like it should be possible. I’ve tried making a wrapper mxj to load the classes I’ve written for processing, but it seems like the problem is that I can’t tell the processing code *where* to draw into… maybe I’m missing something very basic.

It’s not a huge deal, since I can always communicate via network or using maxlink, but it would be nice not to limit communication to primitives, which should be possible if mxj is loading the processing stuff. No?

J.

#32045
May 23, 2007 at 12:50pm

oh, oh!

Okay, sweet! I got it to work… or, erm… at least, I got it to load. That is, I can see the Max window posting a message coming from my Processing class… the trouble is, I can’t see the window!

This is the mxj:

package kompose;

import processing.core.*;
import com.cycling74.max.*;

public class Kompose_GUI extends MaxObject
{
public Kompose_GUI()
{
declareInlets(new int[]{DataTypes.ALL});
declareOutlets(new int[]{DataTypes.ALL});

declareIO(1,4);

GUILoader gui = new GUILoader();
}
}

and this is the GUILoader:

package kompose;

import java.awt.BorderLayout;
import java.awt.Frame;
import processing.core.*;

public class GUILoader extends Frame
{

public GUILoader()
{
super(“Kompose Applet”);

setLayout(new BorderLayout());
PApplet embed = new Main();
add(embed, BorderLayout.CENTER);
embed.init();
}
}

Then my “Main.class” just extends PApplet and does its stuff!

But how do I actually open the window? I’ll keep poking, but if anyone knows the last little trick, I’d love a little hint.

J.

#104791
May 23, 2007 at 1:08pm

I think if you just add the line ‘setVisible(true)’ to your
GUILoader’s constructor you’ll get what you want. setVisible(boolean
x) is inherited from Frame, which inherits it from Container.

Ollie

On 23 May 2007, at 13:50, jbmaxwell wrote:

>
> oh, oh!
>
> Okay, sweet! I got it to work… or, erm… at least, I got it to
> load. That is, I can see the Max window posting a message coming
> from my Processing class… the trouble is, I can’t see the window!
>
> This is the mxj:
>
> package kompose;
>
> import processing.core.*;
> import com.cycling74.max.*;
>
> public class Kompose_GUI extends MaxObject
> {
> public Kompose_GUI()
> {
> declareInlets(new int[]{DataTypes.ALL});
> declareOutlets(new int[]{DataTypes.ALL});
>
> declareIO(1,4);
>
> GUILoader gui = new GUILoader();
> }
> }
>
>
> and this is the GUILoader:
>
> package kompose;
>
> import java.awt.BorderLayout;
> import java.awt.Frame;
> import processing.core.*;
>
> public class GUILoader extends Frame
> {
>
> public GUILoader()
> {
> super(“Kompose Applet”);
>
> setLayout(new BorderLayout());
> PApplet embed = new Main();
> add(embed, BorderLayout.CENTER);
> embed.init();
> }
> }
>
> Then my “Main.class” just extends PApplet and does its stuff!
>
> But how do I actually open the window? I’ll keep poking, but if
> anyone knows the last little trick, I’d love a little hint.
>
> J.

#104792
May 23, 2007 at 1:20pm

Quote: Ollie Bown wrote on Wed, 23 May 2007 14:08
—————————————————-
> I think if you just add the line ‘setVisible(true)’ to your
> GUILoader’s constructor you’ll get what you want. setVisible(boolean
> x) is inherited from Frame, which inherits it from Container.
>
> Ollie
>

hmm… yeah, I just tried that (found it in a post from Topher somewhere), but no love, no window. I put it right after I create my “embed” PApplet.

public class GUILoader extends Frame
{

public GUILoader()
{
super(“Kompose Applet”);

setLayout(new BorderLayout());
PApplet embed = new Main();
embed.setVisible(true);
add(embed, BorderLayout.CENTER);
embed.init();
}
}

#104793
May 23, 2007 at 1:28pm

Aha! Got it!

package kompose;

import java.awt.BorderLayout;
import java.awt.Frame;
import processing.core.*;

public class GUILoader extends Frame
{

public GUILoader()
{
Frame gui = new Frame(“Kompose Applet”);
gui.setLayout(new BorderLayout());
PApplet embed = new Main();
gui.add(embed, BorderLayout.CENTER);
gui.setVisible(true);
embed.init();
}
}

…hehe… never actually made a proper Frame!
Processing is alive and well in mxj!!!

J.

#104794
May 23, 2007 at 1:41pm

That’s the one. But what I meant was…

public class GUILoader extends Frame
{

public GUILoader()
{
super(“Kompose Applet”);
setLayout(new BorderLayout());
PApplet embed = new Main();
add(embed, BorderLayout.CENTER);
embed.init();
setVisible(true); < -- HERE
}
}

You’re plan to extend Frame was a perfectly good one, but then you
ARE the frame, so you need to say this.setVisible(true), or just
setVisible(true);

Cool. I’ve not tried Processing, but now I will.

Ollie

On 23 May 2007, at 14:28, jbmaxwell wrote:

>
> Aha! Got it!
>
> package kompose;
>
> import java.awt.BorderLayout;
> import java.awt.Frame;
> import processing.core.*;
>
> public class GUILoader extends Frame
> {
>
> public GUILoader()
> {
> Frame gui = new Frame(“Kompose Applet”);
> gui.setLayout(new BorderLayout());
> PApplet embed = new Main();
> gui.add(embed, BorderLayout.CENTER);
> gui.setVisible(true);
> embed.init();
> }
> }
>
> …hehe… never actually made a proper Frame!
> Processing is alive and well in mxj!!!
>
> J.

#104795
May 23, 2007 at 2:02pm

Quote: Ollie Bown wrote on Wed, 23 May 2007 14:41
—————————————————-
> That’s the one. But what I meant was…
>
> public class GUILoader extends Frame
> {
>
> public GUILoader()
> {
> super(“Kompose Applet”);
> setLayout(new BorderLayout());
> PApplet embed = new Main();
> add(embed, BorderLayout.CENTER);
> embed.init();
> setVisible(true); < -- HERE
> }
> }
>
> You’re plan to extend Frame was a perfectly good one, but then you
> ARE the frame, so you need to say this.setVisible(true), or just
> setVisible(true);
>
> Cool. I’ve not tried Processing, but now I will.
>
> Ollie
>

Oh, you know, I thought I tried that – putting the setVisible() at the end, but I had typed embed.setVisible(true), which did nothing… of course, that’s obvious, now that I see it done properly! I’ll give your approach a quick try.

thanks.

J.

#104796
May 23, 2007 at 2:14pm

Just noticed a tendency to crash if I try to hide/show by changing the setVisible() flag. Looking at the crash report is pretty interesting – it looks like it’s somehow calling js functions!

Thread 0 Crashed:
0 com.cycling74.js 0x164903d0 jsmax_getproperty + 472
1 com.cycling74.MaxJSRef 0x164ee664 js_GetProperty + 1012
2 com.cycling74.MaxJSRef 0x164cc7fc js_Interpret + 24880
3 com.cycling74.MaxJSRef 0x164d0404 js_Invoke + 1856
4 com.cycling74.MaxJSRef 0x164d0624 js_InternalInvoke + 200
5 com.cycling74.MaxJSRef 0x164a2cc4 JS_CallFunctionName + 84
6 com.cycling74.js 0x164922f4 js_calljsfun + 1164
7 com.cycling74.MaxMSP46 0x000acb4c defer + 200 (defer.c:84)
8 com.cycling74.MaxMSP46 0x000acf48 defer_medium + 124 (defer.c:141)
9 com.cycling74.MaxAPI 0x0180d60c defer_medium + 188
10 com.cycling74.js 0x164927d8 js_messagehandler + 576
11 com.cycling74.MaxMSP46 0x000456a8 typedmess_fun + 2412 (message.c:631)
12 com.cycling74.MaxMSP46 0x0014b76c outlet_anything + 560 (inletoutlet.c:967)
13 com.cycling74.MaxMSP46 0x000456a8 typedmess_fun + 2412 (message.c:631)
14 com.cycling74.MaxMSP46 0x0014b76c outlet_anything + 560 (inletoutlet.c:967)
15 com.cycling74.MaxMSP46 0x000e5218 send_anything(send*, symbol*, short, atom*) + 80 (send.c:57)

Don’t know if that’s a bug, or something. But I know I’m in pretty heavily unsupported territory, so I’m not asking anyone for a fix. Just thought it was interesting. If I decide to use my new processing window in Max/mxj, I’ll leave it open!

J.

#104797
May 23, 2007 at 2:47pm

Hey James,

You’ve no JS stuff in your patch? Weird (or maybe not, I dunno :)

As a shot in the dark, try executing all your AWT stuff in the AWT event
thread via SwingUtilities.invokeLater().


Owen

jbmaxwell wrote:
> Just noticed a tendency to crash if I try to hide/show by changing
> the setVisible() flag. Looking at the crash report is pretty
> interesting – it looks like it’s somehow calling js functions!
>
>
> Thread 0 Crashed: 0 com.cycling74.js 0x164903d0
> jsmax_getproperty + 472 1 com.cycling74.MaxJSRef
> 0x164ee664 js_GetProperty + 1012 2 com.cycling74.MaxJSRef
> 0x164cc7fc js_Interpret + 24880 3 com.cycling74.MaxJSRef
> 0x164d0404 js_Invoke + 1856 4 com.cycling74.MaxJSRef
> 0x164d0624 js_InternalInvoke + 200 5 com.cycling74.MaxJSRef
> 0x164a2cc4 JS_CallFunctionName + 84 6 com.cycling74.js
> 0x164922f4 js_calljsfun + 1164 7 com.cycling74.MaxMSP46
> 0x000acb4c defer + 200 (defer.c:84) 8 com.cycling74.MaxMSP46
> 0x000acf48 defer_medium + 124 (defer.c:141) 9 com.cycling74.MaxAPI
> 0x0180d60c defer_medium + 188 10 com.cycling74.js
> 0x164927d8 js_messagehandler + 576 11 com.cycling74.MaxMSP46
> 0x000456a8 typedmess_fun + 2412 (message.c:631) 12
> com.cycling74.MaxMSP46 0x0014b76c outlet_anything + 560
> (inletoutlet.c:967) 13 com.cycling74.MaxMSP46 0x000456a8
> typedmess_fun + 2412 (message.c:631) 14 com.cycling74.MaxMSP46
> 0x0014b76c outlet_anything + 560 (inletoutlet.c:967) 15
> com.cycling74.MaxMSP46 0x000e5218 send_anything(send*,
> symbol*, short, atom*) + 80 (send.c:57)
>
> Don’t know if that’s a bug, or something. But I know I’m in pretty
> heavily unsupported territory, so I’m not asking anyone for a fix.
> Just thought it was interesting. If I decide to use my new processing
> window in Max/mxj, I’ll leave it open!
>
> J. _______________________________________________ java-dev mailing
>

#104798
May 23, 2007 at 3:39pm

On May 23, 2007, at 7:14 AM, jbmaxwell wrote:

> Just noticed a tendency to crash if I try to hide/show by changing
> the setVisible() flag.

Your crashlog is weird, but I think the key on OS X is to do things
like making windows visible/invisible is to do so in a different
thread in order to make some Carbon< ->Cocoa runloop event management
happy. Not positive about this, and but it’s the first thing I’d try.
Perhaps Ben or Topher know more about it.

-Joshua

#104799
May 23, 2007 at 3:49pm

Quote: owen wrote on Wed, 23 May 2007 15:47
—————————————————-
> Hey James,
>
> You’ve no JS stuff in your patch? Weird (or maybe not, I dunno :)

Nope, no js at all. In fact, this was just a test patch, with nothing but the mxj object in it!

I do remember Topher talking about invokeLater() in a thread a while back about opening windows from mxj. I may give that a shot. I’m not sure how far I’ll go with this Processing-from-mxj thing, as it might be good, in some ways, to have all the GUI stuff running completely outside Max, but if I can get it stable, then it might be worthwhile. As I said, it would be nice to have the opportunity to pass more than just primitives between my GUI and Max.

cheers,

J.

#104800
May 23, 2007 at 4:12pm

Jkc is right.you should do things like setvisible from the swing ui
thread using swingutilities.invokelater.sun suggests this as well.
t

#104801
May 24, 2007 at 7:18am

Okay, I hope I’m doing this correctly… I still find that hide/show crashes Max. Or, to be more precise, the hide/show is fine, but when I try to do anything in the window after “showing” it again, Max quits. I did the hide and show basically the same as “closeWindow()” below:

package kompose;

import java.awt.BorderLayout;
import java.awt.Frame;
import processing.core.*;

public class GUILoader extends Frame
{
public GUILoader()
{
javax.swing.SwingUtilities.invokeLater(new Runnable()
{
public void run()
{
setLayout(new BorderLayout());
setSize(1024, 712);
setVisible(true);
PApplet embed = new Main();
add(embed, BorderLayout.CENTER);
embed.init();
}
});
}

public void closeWindow()
{
javax.swing.SwingUtilities.invokeLater(new Runnable()
{
public void run()
{
dispose();
}
});
}
}

I’m not too worried about hide/show. This window will be my main app window, so it will only close when the main max app quits. It would, however, be nice to at least know how to get everything working properly. Who knows, it could be a problem with the way Processing handles events.

cheers,

J.

#104802
May 24, 2007 at 8:40am

IIRC, once you’ve called dispose() on a frame, that’s it, and you can’t
use it any more. What happens if you just have setVisible(false) to hide
the window and leave off calling dispose() until your MaxObject’s
notifyDelete moment?

Owen

jbmaxwell wrote:
> Okay, I hope I’m doing this correctly… I still find that hide/show
> crashes Max. Or, to be more precise, the hide/show is fine, but when
> I try to do anything in the window after “showing” it again, Max
> quits. I did the hide and show basically the same as “closeWindow()”
> below:

#104803
May 24, 2007 at 9:05am

I think that’s what I did originally. I had public methods for hideWindow() and showWindow(), written like:

public void hideWindow()
{
javax.swing.SwingUtilities.invokeLater(new Runnable()
{
public void run()
{
setVisible(false);
}
});
}
}

…and a similar one for showWindow(). They worked fine, but when I tried to do anything in the re-shown window, Max crashed. This was before I even bothered with a closeWindow()/dispose().

Anyway, I’m not really concerned about hide/show, and I’ve got bigger problems now… I can’t seem to get any communication going on between my mxj and my actual Processing sketch. I can get the PApplet, but I can only see public methods of PApplet, not of my “Main()” class (the basic Processing sketch), which extends PApplet. How do people communicate, back and forth, between the applet? I was hoping to be able to send objects between my Processing sketch and the primary mxj in my patch, but I can’t find a way to do this. Any pointers greatly appreciated.

thanks,

J.

#104804
May 24, 2007 at 10:25am

duh, okay. I got the embedding backwards. I should have embedded my “Main()” processing class, which extends PApplet, not the PApplet itself. A pretty simple explanation, if I’d thought about it for a few seconds… gulp.

J.

#104805
May 25, 2007 at 10:51am

what, no updates?

On 5/24/07, jbmaxwell wrote:
>
>
> duh, okay. I got the embedding backwards. I should have embedded my
> “Main()” processing class, which extends PApplet, not the PApplet itself. A
> pretty simple explanation, if I’d thought about it for a few seconds…
> gulp.
>
> J.
>

#104806
May 25, 2007 at 12:22pm

Quote: yair r. wrote on Fri, 25 May 2007 11:51
—————————————————-
> what, no updates?
>

hmm… sarcasm?

Just in case, though. I did get the ability to call methods on my Processing class, once I instantiated the right class! On the other hand, hide/show is still crashing Max. I’m leaving that for now, and just working on the Processing stuff in Eclipse. If you want to know how things come together, I can post when I have a better idea how stable/usable this is going to be.

J.

#104807
May 25, 2007 at 1:28pm

no sarcasm, really looking fwd to hear if you get anything interesting going
on there.
I’m in the process of evaluating the world wind SDK for java and one
processing example got me pretty far.
processing is a fat slob at times, its video support is a joke compared to
jitter, but its abstraction of the java why of things fits nicely with my
programming thinking.
cheers

On 5/25/07, jbmaxwell wrote:
>
>
> Quote: yair r. wrote on Fri, 25 May 2007 11:51
> —————————————————-
> > what, no updates?
> >
>
> hmm… sarcasm?
>
> Just in case, though. I did get the ability to call methods on my
> Processing class, once I instantiated the right class! On the other hand,
> hide/show is still crashing Max. I’m leaving that for now, and just working
> on the Processing stuff in Eclipse. If you want to know how things come
> together, I can post when I have a better idea how stable/usable this is
> going to be.
>
> J.
>
>
>

#104808
May 25, 2007 at 2:16pm

Quote: yair r. wrote on Fri, 25 May 2007 14:28
—————————————————-
> no sarcasm, really looking fwd to hear if you get anything interesting going
> on there.
> I’m in the process of evaluating the world wind SDK for java and one
> processing example got me pretty far.
> processing is a fat slob at times, its video support is a joke compared to
> jitter, but its abstraction of the java why of things fits nicely with my
> programming thinking.
> cheers
>

Oh, okay. I’ll keep you posted.

I sometimes feel pretty goofy with the amount of posts I throw up in a short space of time! ;-) But I’ve always felt it was better to let people know when you find a solution to a previous problem – it saves them thinking about it anymore (assuming they thought about it in the first place!).

btw, With the whole possibility that this might bog Max down too much, or just be generally buggy with Cocoa/Carbon thread problems, I’m still considering that my UI will run totally outside Max and communicate via network. I have one question, though: do you know how practical/possible it is to send objects or data structures over the network? This could offer me more possibilities, in the event that embedding Processing in mxj doesn’t work out.

cheers,

J.

#104809
May 25, 2007 at 2:37pm

my biggest network project involved 8 slaves + 1 master all with heavy usage
of jit.cv.
i used osc-route for the parsing the messages, the network never gave me
trouble.
I’m using winXp btw.

On 5/25/07, jbmaxwell wrote:
>
>
> Quote: yair r. wrote on Fri, 25 May 2007 14:28
> —————————————————-
> > no sarcasm, really looking fwd to hear if you get anything interesting
> going
> > on there.
> > I’m in the process of evaluating the world wind SDK for java and one
> > processing example got me pretty far.
> > processing is a fat slob at times, its video support is a joke compared
> to
> > jitter, but its abstraction of the java why of things fits nicely with
> my
> > programming thinking.
> > cheers
> >
>
> Oh, okay. I’ll keep you posted.
>
> I sometimes feel pretty goofy with the amount of posts I throw up in a
> short space of time! ;-) But I’ve always felt it was better to let people
> know when you find a solution to a previous problem – it saves them thinking
> about it anymore (assuming they thought about it in the first place!).
>
> btw, With the whole possibility that this might bog Max down too much, or
> just be generally buggy with Cocoa/Carbon thread problems, I’m still
> considering that my UI will run totally outside Max and communicate via
> network. I have one question, though: do you know how practical/possible it
> is to send objects or data structures over the network? This could offer me
> more possibilities, in the event that embedding Processing in mxj doesn’t
> work out.
>
> cheers,
>
> J.
>

#104810
May 25, 2007 at 5:10pm

As far as sending objects across the wire goes you need some sort of
serialization mechanism.the java one
,objectinputstreamobjectoutputstream are probably a good place to
start.there are a lot of ways to do this sort of thing. You may find
that if you just want a free standing ui you never need to send objectds
at all whicwould be better performing in the end. Typically you would
send an event I’d and a value or something like that…

#104811
May 25, 2007 at 6:25pm

Quote: topher lafata wrote on Fri, 25 May 2007 18:10
—————————————————-
> As far as sending objects across the wire goes you need some sort of
> serialization mechanism.the java one
> ,objectinputstreamobjectoutputstream are probably a good place to
> start.there are a lot of ways to do this sort of thing. You may find
> that if you just want a free standing ui you never need to send objectds
> at all whicwould be better performing in the end. Typically you would
> send an event I’d and a value or something like that…
>
—————————————————-

Thanks, Topher. That’s *very* good to know. Although I’m kind of thrilled by seeing my Processing stuff running in mxj, I am a little nervous about throwing more stuff at Max. The patch this UI is going to run is already doing a lot, so keeping it as clean as possible is probably a good idea. Mind you, it’s not really a UI, in a way… It’s a score editor, so it will ultimately contain a representation of actual music. In my overall design, it will also provide a sort of constraint mechanism for generative stuff happening in Max. This is why I wanted the two running *together* in mxj – that way, they could both operate on a single representation of the score, just looking at it from different angles. Does that make sense?

…But the more I think about it, since my main mxj is actually just sending and receving floats, ints, and strings from its inlets and outlets (as is the habit for mxjs!), perhaps I should pull my main mxj *out* of Max, and into the Processing applet… (??) I assume the only pressing need for mxjs to extend MaxObject is to be max-box/patcher savvy…. yes? No reason a Processing applet couldn’t just import the necessary com.cycling74 stuff (I think I’m only regularly using Atom and the MaxSystem file locating stuff), is there? Then I could just send the basic, Max-cable-style, messages over Maxlink. And from the final max app, I could even use your swanky syscommand mxj to launch the PApplet. That could be sweet!

hmmm… got to re-think some stuff, it seems.

Thanks for the eye-opener.

J.

#104812
Jan 4, 2008 at 10:34pm

I know this is an old thread but I am interested in loading
processing.org pde files in Jitter using [mxj].
Did anyone figure out how to do this? The java source posted on
this thread does not seem to specify how a .pde file would be
loaded and displayed. Does anyone have an example they can post?

#104813
Jan 4, 2008 at 10:50pm

Quote: Anthony Palomba wrote on Fri, 04 January 2008 22:34
—————————————————-
> I know this is an old thread but I am interested in loading
> processing.org pde files in Jitter using [mxj].
> Did anyone figure out how to do this? The java source posted on
> this thread does not seem to specify how a .pde file would be
> loaded and displayed. Does anyone have an example they can post?
>
—————————————————-

I don’t imagine you could ever load a .pde file (that’s the native Processing file, right?) in mxj. But if you run Processing in “java mode”, then you can build what is pretty much a generic java applet, and _that_ can be made to work with mxj. I can’t remember exactly how I was doing it (I’m just using OSC now to communicate between my applet and Max), but it seems to me it was just a matter of making a kind of wrapper mxj which opened a window and embedded the PApplet in that window.

I doubt that helps much, but perhaps a little…

J.

#104814
Oct 28, 2010 at 6:04pm

Hi, I know that no one has written here for a while, but can anyone tell me how to load a processing sketch (.jar file) into max msp?

#104815
Oct 28, 2010 at 11:20pm
#104816
Aug 4, 2011 at 3:35pm

Hi all. I realize that this post is 4 years old so people might not still be around or this might not even be relavant, but I’m hoping to get some advice anyway. I was attempting to get the above two pieces of code (GUILoader and Kompose_GUI) to compile this and kept running into errors about the Main() symbol not being found. I see above that there’s something about putting ones own main class somewhere, but I don’t understand where. Anyway, if anyone has any instructions on how I might be able to get this going that’d be incredible.

I also have a thread going on the processing forums here with a different solution that people might be interested in: https://forum.processing.org/topic/processing-and-jitter

#104817
Aug 5, 2011 at 11:53am

Hi Edward. I am also very interested (but am yet to try in earnest), so please share the developments.

Have you seen this? Is this of help?

http://cycling74.com/forums/topic.php?id=33927

#104818
Aug 5, 2011 at 4:25pm

Hey jhdkfj39929.

I did see that and hadn’t really checked it out. I can’t tell if it’s allowing me to send messages to/from processing/max or allows me to get processing pixel data in the form of a jitter matrix. I’m trying to do the latter.

I did give this thing a shot though. I don’t really understand how to work it and get some errors about needing to use Import Library. Let me know if you get the same thing.

#104819
Aug 6, 2011 at 12:58am

I tried and got markmarijnissen’s setup going, compiling from Eclipse. His arrangement is only passing messages, key presses and strings as far as I can see but I do not see why more should not work.

I am also curious if one could write a sketch using Processing core and libraries but, with the use of Jitter matrices, that could be driven by MAX input and post-processed within MAX too.

If anybody has done anything similar, some samples would be great – I am doing all of this for the first time…

#104820
Aug 12, 2011 at 4:41pm

hello jhdkfj39929( that is a hard nickname ;-) )
Porting from processing can be a very tricky thing. Most of the issues might come from ‘scaling’ the data into matrices, which is already a science in itself. Mostly is about criteria.

1-If the porting case is doable mostly with matrices it is better to stick to it. That would mean to re-desing the patch in order to get a similar result using the jitter resources.
For example, think about the next case:
void setup(){
size(800, 600);
}

void draw(){
background(0);

stroke(255);
line(width *0.5f, height *0.5f, mouseX, mouseY);
}

As simple as it is seems it would take a little bit of tweak for porting it to jitter-java( at least for my limited skills). So i would do something like this:

import com.cycling74.max.*;
import com.cycling74.jitter.*;

public class Lesson2 extends MaxObject{

JitterMatrix l2= new JitterMatrix(3,”float32″,2);
int[] cells = new int[2];
float x, y;

public Lesson2(){
declareInlets(new int[]{DataTypes.ALL});
declareOutlets(new int[]{DataTypes.ALL});
x = 0; y = 0;
cells[0]=0; cells[1] = 0;
}

public void setX(float _x){
x = _x;
}

public void setY(float _y){
y = _y;
}

public void resetValues(){
x = 0;
y = 0;
}

public void bang(){
int plane = 0;
l2.setcell(cells, plane, x);

plane = 1;
l2.setcell(cells, plane, y);

plane = 2;
l2.setcell(cells, plane, 0.0f);

outlet(0,”jit_matrix”, l2.getName());
}

}

with the next patch:

– Pasted Max Patch, click to expand. –

As you can see a rather baroque way of getting the same result.
Notice that I am using setcell here. It is, together with copyArrayToVectorPlanar, one of my favorite methods to port data into matrices( as far as I know jitter doesn’t handle multidimensional arrays).

2-One of the best reasons for porting processing code into jitter might be the use of their amazing libraries. There was an example of MSA fluids on this forum, check it out as it would be an amazing source of study!
I was so curious myself about the possible solutions for porting processing libraries that i asked a good friend of mine( a very good java user of course) to give me his opinion on the topic, in specific about the possible prting of the traer physics library. As we were checking out the sources I was amazed how many possible solutions there were to wrap the original classes. In the end it seemed that the best option was to keep most of the original classes and to have a toMatrix method in order to bring all the data to matrix-land. The method looks like this:

public void toMatrix(JitterMatrix jm) {
if (jm == null) { return;}
final int size = (jm.getDim()[0] >= _particles.size()) ? _particles.size() : jm.getDim()[0] ;
if (_particles.isEmpty()) {
populateParticleList();
}
Vector3D vec = null;

for (int i = 0; i < size; i++) {
vec = _particles.get(i).position();
pos[0] = i;
jm.setcell(pos, 0,(vec.x() – 200.0f) / 200.0f );
jm.setcell(pos, 1,(vec.y() – 200.0f) / 200.0f );
jm.setcell(pos, 2,(vec.z() – 200.0f) / 200.0f );
}
}

Notice the use of setcell again!

I will try to clean the code and post it here( it is a really big mess right now!)

Hope all this long speech is useful!

#104821
Aug 13, 2011 at 4:11pm

@efe Thank you so much for the code examples. Very useful and look forward to more.

Thanks even more to directing me towards the MSAfluids and (by extension) to the projects on t-linked.com – all very useful too.

In addition to the technicalities, I’d be interested to know about example that explain why people take Processing (or Java) code into MAX rather than running it as Processing. I suspect I am missing some interesting opportunities.

Best wishes.

#104822
Aug 14, 2011 at 5:27am

Hey!
I guess the idea to integrate code facilities into the patching style of programming is all around: vvvv has its dynamic c# plugins( c# is the microsoft java), touchdesigner has its c++ templates. Even more, I am wondering why c74 hasn’t boosted more the use of java with jitter as it would be the perfect way to bridge the program with external libraries. I am curious about max6. More than a auto code creator, I would love to see a dynamic compiler for java and glsl.

#104823
Aug 14, 2011 at 10:57am

That the code useful as an extension of node-based interfaces is uncontroversial. I was thinking about the opposite direction – why use visual programming in MAX when one can write, for example, a Processing/Java program…

#104824

You must be logged in to reply to this topic.