rip64 is the proto-type pro-audio server, the hardware implementation of the jack audio server. Its a dell poweredge 850 I got off craigslist, put in an audio interface with abreakout box and installed, configured and compiled a minimalist gentoo linux installation. The kernel has been stripped of nearly everything except the server needs to function for the purpose of routing signals, dsp, sequencing, etc.

The project is more than just about recycling cheap used web servers, since there are so many components now its somewhat dizzying. There was a wiki on hackaudio.org that was started to document the project, but it recently got bombed so I've taken down the wiki and am slowly starting to rebuild the site.

The current state of the servers components:

Currently, I have been using rip64 to mix and master my new album, but I have also been routing my hardware gear through the server and into anything else and back. So my sequencer (muse) can play my hardware synth. The synths signal is routed into the server, through an effects plugin through jack-rack, then out into my sampler where I run another effect on it, and back into server to be recorded and/or mixed and sent out to the speakers. This happens while everything else is also being handled.

Because electronic music harnesses electricity to make sound, we have a very liberal area to work with in terms of our 'instruments'. The audio server is part router, part master-DSP, part multi-person electronic instrument. The touchscreens are intended as performance interfaces, and I am working on a semi-graphical modular programming langage (with python api) like pure data, except it will navigate through a spreadsheet like hierarchy of layers. Interfaces can be embedded into the cells and navigated, all without using a mouse (or a touchscreen for that matter).

These servers come with 2 Gigabit NICs, so a  netjack session is just the beginng for what can be done, since netjack only works by thin clients controlling the server, which is the DSP. Clients may be synced via midi, but if they are running apps themselves, they are not jacked-in. I have toyed with the idea of making the jack audio server and 'jack-aware' application-- perhaps this has already be discussed and/or done. Doing so would distribute the audio server architecture into a peer to peer, rather than a client/server relationship. Sound files, waveforms, midi sequences, patches, etc could be stored in a central repository ( I got a powervault RAID array the other week for this purpose). Latency over a LAN is going to be the driving factor in the creation of the buffer and how far in advance from "now" the playhead would be. But the central server could then start delegating other tasks on how to distribute the processing. Much of this could be done by allocating resources from the start. I also have collected a poweredge 1850 and 2850. These are bigger and LOUDER!, but I was thinkin of dedicating one to being solely running linuxsampler (which is a sampler designed as a server, controllable via TCP)

anyway, im done writing now. I was told to keep my gear footprint light, so Im not planning on bringing anything but a laptop to the hack day, unless the organizers specifically want me to bring the server out. 5lowershop and Spaz sound systems have shown support and come out to help hack on it. Others interested can get in touch with me at siris@hackaudio.org

godspeed  you black cats