clients, distributed

I have gotten sclang, the client component of the 'supercollider' environment, up and running across a LAN.

Let's start with why this is significant...

Supercollider is a client-server application, communicating either over UDP or TCP. Thus, it can be readily implemented across a network where the client resides "locally," sending messages (I prefer UDP so I can handle my own redundancy) to a distributed cluster of servers, much like a single keyboard controlling many tone generators via MIDI. In the distributed server model, the single client acts as a hub for the server nodes to communicate through. The connections are essentially one-way, in the sense that the kind of data that can be sent back from the server alone is limited. We have audio, of course, but the dataflow from the server app is limited to error messages, trigger messages (say from inside a synthdef), or various state-dumps, where the server status is queried. While this is useful for certain applications (mostly debugging), eventually this gets old. Since communication is restricted to the server, I cannot write osc responders or evaluate sc code remotely. This has changed.

Now, I am able to distribute the client app in addition to the server, allowing truly bi-directional dataflow and much more complex paradigms for interaction. Say, for example, I wanted to distribute a control structure for several people to edit together. If all we have is one-way communication from the server nodes, I am limited to directly sending OSC messages to query the state of the server(s) and sending more packets to change the synth-nodes based on numeric id's. I have no access to, say, the underlying thread that generates those synth-nodes in the first place. With a distributed client app, it is elementary to set up a new process in the place of an old one, and the synthesis for this process could be occurring anywhere else in the cluster. It is all up to the constraints of the system.

The only thing I really did to allow this to happen was to set up the appropriate conditions for sclang to run remotely. This involved getting emacs to befriend sclang and setting up the embarrassingly simple file structure for sclang to work. The CCRMA tutorial by Fernando Lopez-Lezcano "How to make SuperCollider go 'beep'" was extremely helpful for this. It assumes one has installed supercollider, jack and emacs, which each of my Cattri boxes already has set up. Actually, the setup was so minor that I felt kind of stupid for not having done this before, instead opting to change my entire coding style to server-message so I could keep my client local.

Now I can set up the Cattri so that sclang code can be remotely evaluated on my local machine, thus reducing the amount of time spent in ssh tunnels using emacs. That being said, I kind of like emacs. I just miss my backspace sometimes.

Leave a Reply

Your email address will not be published. Required fields are marked *