tziteras

In my nightly jams with Ninjam I've recently found out loads about how it can be improved. Firstly there's now a linux client (there's always been one but this one is gui based). It's called gninjam. Best of all is that in doing this, Tobias the author of this first derivative, separated display from core functionality creating libninjam and a front end which he wrote in Glade. Setar and Tabla improvisation on very cheap microphone I want to write a new front end for it then, using libninjam and wxpython which looks simple enough , although this is all very ambitious, and I may never actually get to do it, but here's all the ideas meanwhile: a last.fm-like client that is able to : * Simplify the process of setting up audio: loads of ninjam users get in, but cant' hear themselves, some other player, or are coming through distorted etc and have to rely on the irc window to help them. For this I'd make a "testing room" - a room run on a standard serv...

Networks are by their nature, failure prone. Whether you are talking about a person in your extended network turning up as requested to a place, or a computer not crashing when you need it, you can't really control the remote points. But you can "influence" it - devote more time to any node and give it incentives such as quick replacement arrangements, money, systems administrator time etc. In working on the Locating Grid Technologies workshop series' last practical event, we had to take this into account. I envisioned the connections as being a central set of maybe 2-3 nodes that we really checked up on and ensured would be functioning on the day, and then as many other nodes as needed, but with no checks or involvement from us. In a much larger network we'd have had the chance to test out many more of the fallacies/problems/opportunities of distributed computing, but I'm impressed at how much a social/performance event resembles a generic computer procedur...