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?

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. 

processing-in-mxj

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!

public class Kompose_GUI extends MaxObject

        declareInlets(new int[]{DataTypes.ALL});

        declareOutlets(new int[]{DataTypes.ALL});

        GUILoader gui = new GUILoader();

        setLayout(new BorderLayout());

        PApplet embed = new Main();

        add(embed, BorderLayout.CENTER);

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.

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! 

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});

		GUILoader gui = new GUILoader();
		}
	}

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

	public GUILoader()
		{
		super("Kompose Applet");

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

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.

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

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

> public class Kompose_GUI extends MaxObject

>         declareInlets(new int[]{DataTypes.ALL});

>         declareOutlets(new int[]{DataTypes.ALL});

>         GUILoader gui = new GUILoader();

>         super("Kompose Applet");

>         setLayout(new BorderLayout());

>         PApplet embed = new Main();

>         add(embed, BorderLayout.CENTER);

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.

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


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.

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.

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
>

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


        Frame gui = new Frame("Kompose Applet");

        gui.setLayout(new BorderLayout());

        gui.add(embed, BorderLayout.CENTER);

...hehe... never actually made a proper 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!!!

        super("Kompose Applet");        

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 

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

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

>         Frame gui = new Frame("Kompose Applet");

>         gui.setLayout(new BorderLayout());

>         gui.add(embed, BorderLayout.CENTER);

> ...hehe... never actually made a proper Frame!

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

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);

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


Quote: Ollie Bown wrote on Wed, 23 May 2007 14:41

> That's the one. But what I meant was...

>         super("Kompose Applet");        

> 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 

> Cool. I've not tried Processing, but now I will.

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.

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);
> 	}
> }
>
> 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
>

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!

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!

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)

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 

> 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

> J. _______________________________________________ java-dev mailing

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

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
>


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

> Just noticed a tendency to crash if I try to hide/show by changing 

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

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

Quote: owen wrote on Wed, 23 May 2007 15:47

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

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 :)

Jkc is right.you should do things like setvisible from the swing ui 

thread using swingutilities.invokelater.sun suggests this as well.

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


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:

        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();

                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.

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();
				}
			});
		}
	}

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 

> 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()"

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?

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:

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

                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.

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

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.

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

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

Quote: yair r. wrote on Fri, 25 May 2007 11:51

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.

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

no sarcasm, really looking fwd to hear if you get anything interesting going

I'm in the process of evaluating the world wind SDK for java and one

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

> Quote: yair r. wrote on Fri, 25 May 2007 11:51

> ----------------------------------------------------

> 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

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

Quote: yair r. wrote on Fri, 25 May 2007 14:28

> no sarcasm, really looking fwd to hear if you get anything interesting going

> I'm in the process of evaluating the world wind SDK for java and one

> 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

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.

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
>

my biggest network project involved 8 slaves + 1 master all with heavy usage

i used osc-route for the parsing the messages, the network never gave me

> Quote: yair r. wrote on Fri, 25 May 2007 14:28

> > no sarcasm, really looking fwd to hear if you get anything interesting

> > I'm in the process of evaluating the world wind SDK for java and one