Hi, good question. I was going to say "depends what you mean by streaming", but it actually doesn't - regardless of what you mean by streaming, I'm sure its technically possible to get a processing sketch to connect to another one, and do some communication. Peel back a fairly thin layer in Processing and you've got java, and can do anything that java can do. There's a couple of hoops to jump through to do with the way that processing executes its code, vs the way that most java programs get executed, but I'd be surprised if those problems have not already been well-solved. If nothing else, a network protocol could be used to open a socket between the two sketches.

HOwever, all of that is a bit of a moot point because the polargraph controller does not (at this time) have any interface for such a connection - which is, I guess, what
you were actually asking.

The question I have is what do you need the controller for? To take a cartesian coordinate pair and send it off to the arduino? There's definitely a better solution. Really, there should be a kind of back-end library that does all that stuff, with a good API, and the front end is all the wizzy graphical stuff. So the library could be reused in any program that wants to be able to talk to a polargraph. It doesn't have that yet, so to use a polargraph machine you need to reimplement all the comms, coordinate conversion and commands stuff, which is [at least one reason] why nobody has done it.

I don't think it would be at all hard to modify the controller so that it could have commands sent to it over a socket, and they would then land in the command queue and be dealt with like any other. The real issue is that that would probably not be enough to be useful. What I would actually want (if I was writing another client for polargraph), is the ability to get a "machine" object, set it to my target size (or ask it what size it is), then be able to ask it to convert between two coordinate systems. The comms side of things might be better separated out into another object so that the comms is not coupled to the coordinatey stuff.

So the process might be
1. Instantiate new _Machine_ object, tell it the size of itself (physically).
2. Generate your coordinate for your first point,
3. Ask the Machine object for the _Command_ required to draw to the coordinate
4. Add the new Command object to the Dispatcher

Where the Machine knows all about machine sizes, coordinate systems, the command syntax etc.
And the Dispatcher object knows all about the USB ports, wireless dongles, esoteric network connections required to actually get the command into the arduino itself.

Drop me an email (sandy dot noble at gmail) about this if you would like to take it forward - the above looks a bit like a spec for an API, but it'll be much easier for me to figure out where to draw the line (ha) if I have a real person who wants to use it! If not, well it might happen spontaneously, but then it might not!

cheers!
sn