I really like this idea. It sounds very interesting and I'll be excited to see the final product. Have any collaborators signed on yet?

Also I kinda wondered how it would work technically. I wondered how much of the other tile's pixels are sent to each collaborator. How many adjoining tiles would the pixels come from?

I'm interested in applying, but don't have any previous 'art' works. I do some VJ/visuals stuff but haven't done an installation.

Have a look at some sample Processing sketches on my blog. The Origami Butterfly may interest you (not my idea, I just optimised and animated it).

Are you talking about running something over multiple screens with multiple machines running it, or just a single video output And when you say it should be time based, is there also a requirement that it run in "real-time" (eg some minimum frames per second)

You could possibly provide a base class that has the input and output pixel arrays defined within it, and something like update() and draw() methods; each coder would then simply (or not so simply!) extend that base class and your calling code just plugs them in and calls the methods. This could even allow for shuffling of the tiles within the matrix.

-spxl

subpixel:  No prior installation work isn't a problem; the collaborators will essentially just be working on their own visualization projects that I'll merge together later.  By all means, go ahead and apply.  Visuals stuff is good.  

For your other questions:
- I'm looking at multiple machines and screens, connected by an MPE server
- By time-based I mostly just meant not static.  This project needs moving pixels in order to work, the more the better.  It should be able to run at some reasonable frame rate, again because more motion will create more interaction between tiles.  I need to look into MPE more to see if it allows things like different frame rates, but each tile should end up running on its own machine anyway so that should help.  
- Like I said, the tech side of it is still being worked out, partially because I want the collaborators to have some input on the process.  I have thought about creating a base class that can be extended since that seems like a good way of handling it (as well as a simulator so you can see how well your tile blends with the input data) but that's something that will be worked out when the project starts.

Rick:  Looping the canvas may be the best way to do it, I think it depends on the specific generators that end up being included in the piece.  I definitely want to try it and see how it looks.