I just attended the Most Pixels Ever workshop by Daniel Shiffman at the OFFF festival. Although it was a very short workshop (2 hours) I think it was a good workshop and time well spent.
Most of the times the workshops I attend are just excuses to start working on something and this one was no different. I don't have access to big screens like the ones at IAC, but we, at the School of Arts (UCP), do have a lot of small screens that can be used to create something interesting.
The MPE library is rather simple (which is good) and it basically does time and space synchronization among the several screens, which means that you can create a program that uses a display are that spans multiple physical displays. It is well described here, but I'll summarize how it works:
- Each screen is managed by a computer (client) which runs the Processing (or OF) program. The program that runs on on each client is essentially the same (at least from the programmer's point of view). And each program uses a screen dimension equal to the sum of the dimensions of the total screens (each program "thinks" it has a large window).
- Time syncing: MPE has a server (which can run on a separate computer or on one of the clients) which sends messages like "draw the next frame" to each of the clients. It then waits for all clients to respond saying they have finished drawing the frame. It then repeats this (at 30 FPS or whatever framerate we have configured). This means that the whole system will run as slow as the slowest computer and that it will crash if one of them crashes.
- Spatial syncing: MPE uses .ini files at each client that say what portion of the big screen the client is responsible for. When the program draws it's screen (the program draws the entire big screen but only a part will be shown - remember that all clients are equal), MPE issues translate calls to show only the portion that is assigned to that client.
This is a very simple setup, which is nice, and it essentially allows each client to define a window over the "big screen".
Of course all clients and server must run on a local network to exchange messages. Also since all programs must behave exactly the same, random calls must use a common seed among all clients.
One of the problems with this architecture is laying out the several clients. The .ini files must be created by hand which may be kind of a hassle if you have a lot of screens. But since the library is open source, I may work on some sort of solution for this (may creating a server program that allows you to graphically lay out all the clients and dynamically updating the client's information about their part of the screen).
Suggestions on what to do with this library and 12 or so iMacs are appreciated.