3spds

tuesday, december ninth, I installed an 8 channel network piece expressing micro-rhythmic patterns with flocking algorithms and force simulations. in each of the four computers on the LAN, I placed a world with 40 agents, each representing a train of semi-pitched impulses, resembling steel drums. the x coordinates represent the rate of the train, and the y coordinates represent the position within the cycle (phase). these drummers each had proportional masses to their pitch, and exhibited the following behaviours:

1) move toward the average location of the nearest drummers you can see

a) visibility is determined by an angle width and a distance.

b) width is centered around the drummer’s heading, the distance is proportionate to the drummer’s mass.

2) steer to avoid those drummers that are too close

3) collisions are possible, forces determine outcome

each of the other 3 nodes in the LAN are represented, in terms of their average position, as supermassive drummers in the worlds. they do not react to their surroundings directly, but pose as obstacles for each flock.

for debugging purposes, i used sc’s cocoa interface to animate the drummers. this video is from one of the local debug runs.

each drummer plays a single drum whose pitch remains constant, so the resulting texture is a pitch constellation whose changing parameters include timing relationships, overall density, local coherence, and speaker position.

the performance on tuesday was well received, despite the fact that the context was less than ideal.  to show a piece like this in a setting where the focus is on particulars and not on the subtle aspects of experience is tough and somewhat frustrating.  regardless of this, i feel as though my explanation was adequate for that setting, and the system worked just about flawlessly, with the only hiccup my being locked out of one of the computers and needing a reboot.

as i explained to the group, this setback actually fulfilled part of my aesthetic requirements for the piece as i disapproved  of the power paradigm implied by the piece.  if i am to be positioned as a godlike dictator over these four computers, then an act of civil disobedience is only responsible.

later in the week, on the 15th, i presented an improved incarnation of the piece which added to this self-organizing  flocking algorithm a second, more insidious one. this behaviour i programmed to spread virally and without bounds across the network, choking the router and the distributed virtual machines.  once triggered, this behaviour almost immediately results in a Denial Of Service lockout from LAN access.  the only way to kill the virus is by quarantine.

the virus is essentially a version of the network oscillator pieces i had come up with early in my experiments with networked systems.   essentially, each receptor, on being triggered with a value of 1 or -1, broadcasts to the network the opposite of that signal.  as a result, in systems larger than 2, this results in an oscillation between 1 and -1 on each node in the network.  this value is used as an excitation signal to a karplus-strong-like pluck algorithm which is sensitive to the timing between plucks.  imagine a frettless  (or alternately, slide) guitarist whose left hand moves closer to the bridge as his right hand’s tremolo moves faster.  i took extra measures to make the sound extra-plinky, and to give it more dynamic range.

click here for a recording of both textures running, as each computer is faded in.

the performance on the 15th was at diapason, an art space  run by michael schumacher.  before i began i explained a bit about the process.  i used my laptop to wirelessly start the flocks on each computer, which were panned around the space’s 12-channel system.  since i re-initialized the environment prior to the performance, i set up the entire composition right there in front of the audience using the interface Ron and I came up with.  This provided a nice parsing between computers, as each one started in turn.  Having informed the audience about the viral code I would deploy, I simply waited for a few minutes to allow the flocks to organize and shift around each other, and then at a moment I determined to be opportune, I infected the network, giving the audience a visual cue.  Finally, after a few minutes of letting the clogged network suffer, I ping-flooded a few of the computers on the LAN, experiencing 100% packet loss.  Then I got up and somewhat dramatically unplugged each of the cat-5 cables connecting to the router, giving a few moments between them so we could hear each infection site heal.  The flockers continued plinking away after this, and I reconnected the nodes to allow for networking between the flocks.  Then, having regained access to the router, I stopped the flocks one by one from my laptop.

I was very happy with the performativity of the system in this form, but I would like to improve on the composition by allowing the virus to inject vm’s with its code receptors programmatically, and chase it with some kind of healing function or antivirus.  This incarnation of the composition could then be installed, with perhaps distributed, bus-driven led systems (anything visual but non-cgi) to portray more clearly which nodes are infected and which are not.

this was my first experience of the composition in a true multichannel context, previous versions (like the recording above) had been mixed down to 2 channels.  i found the system a lot simpler to navigate, its processes more immediate to locate, in this new context.  i look forward to the next opportunity to work in a massively multichannel arena.

i am coming up with a proposal for this  installation to  be deployed at several sites, such as the supercollider symposium at Wesleyan University in the spring, as well as at Diapason once again in the above mentioned installation form.  it would really be a treat to show Ron and the other guys what i’ve been up to.

I developed the following paradigm for writing code on a network of arbitrary size, allowing me to stay in one authoring environment while communicating to several machines and receiving posts as though they were local. When set up with a terminal multiplexer like gnu ’screen’, it allows for a scalable solution to writing distributed code clearly and effectively. To set up the system, on each compute node I run screen, and within the screen session I run emacs in sclang mode. I then add a responder that allows remote interpreting and postback, and a function that flushes the post buffer for regular updates. Then I detach from the screen session and close the ssh tunnel. From here on in, as long as nothing traumatic happens to those remote machines, I have remote interpreter access and posting using OSC packets, and total decoupling between my representation of those language processes and the processes themselves. Here’s a screenshot:

source code

click to listen

this is a recording of the cattri, my cluster, “performing” (read: generating in real time) a piece of music that has much in common with things like fractals and wavelet noise.  actually, the algorithm itself was inspired by some reading i had been doing about computer graphics, to which often i find my work relates.  the individual notes, occasionally long and sustained, often short enough to be perceived as granular, consist of band-limited noise with formants, generated by phase-modulating a bank of sine oscillators with white noise.  the paths these note-events take through frequency-space is a lattice derived from 3 intervals: 4/3, 7/4, 8/7 and their inverses: 3/4, 4/7, 7/8.  these intervals are sorted and then shuffled like a deck of cards (split in half and interleaved), twice.  there is a variable depth of recursion on the following phrases: forward through the row, backward through the row, and random.  the frequency-space lattice also reflects rhythm, with lower bands generally moving slower than higher bands from the same compute node.  each compute node is relegated to a different frequency region, from 50 to 400 by octaves.  finally, the output is summed to 2 channels and processed by a fifth computer, on which i am live-coding various effects, such as waveshaping, physical modeling, and comb-filtering.

i left the cattri (just the four nodes, not the effects) running this algorithm for about 24 hours straight. i did this because kapow, my parakeet, gets lonely when jenny and i aren’t home.  he loves fractals.

future modifications of this piece will allow for dynamic communication between nodes, and not simply a divide-and-conquer strategy.  also, i would love to work out how to incorporate network errors into this system;  i’m thinking i could infect this network with a virus that moves from node to node, pelting the other nodes with spam and infecting the weakest node.

installation of this piece could be done arranging the nodes in space.  a simple visualization, projected into the site, could accompany.

I did it again. Bigger. This time, instead of making two oscillators (and actually the previous recording only had one oscillator), I made four. Each machine gets sent to a different channel in my crappy samson mixer (the one that I used for no-input mixing with the Braxton ensemble back in undergrad), where I made a desperate attempt at spatializing them with panning and equalization (don’t hold your breath). Here is a recording (sorry for the codec & remote hosting: I’m trying to save on server space). I mess with the eq a bit toward the end, but that pulse-width sounding stuff that happens is totally an emergent property of the network. Sweet!

In this system, each node waits for a message containing either a 1 or a -1. On receiving this message, 2 of 4 nodes invert the signal while the other 2 do nothing to the signal. The signal (normal or inverted as the case may be) is sent directly to the soundcard as a dc offset, and the node sends its signal to all the other nodes. All of this happens ‘instantaneously’, which is a fancy word for ‘as soon as possible’. So, what we hear is the result of all different sorts of bottlenecks in the system, as well as packet collisions or outside interference. We hear the time constant of the network itself, plus the language, plus the soundcard, plus the mixer.

//dukkha:
s.boot;
SynthDef(\NetOsc, {|dc = 0, vol=0.5| var osc; osc = Silent.ar + (dc*vol);Out.ar(0, osc!2)}).store;

~langs = ["192.168.2.5","192.168.2.6","192.168.2.7"].collect{|ip| NetAddr(ip, 57120)};

~count = OSCresponder(nil, ‘/count’, {|t,r,m,a|
var dc;
dc = m[1].neg;
s.sendMsg(15, 1000, ‘dc’, dc);
~langs.do{|addr, index| addr.sendMsg(’/count’, dc);};
dc.postln;
}).add;

s.sendMsg(9, ‘NetOsc’, 1000, 0, 0);

//samudaya:
s.boot;

SynthDef(\NetOsc, {|dc = 0, vol=0.5| var osc; osc = Silent.ar + (dc*vol);Out.ar(0, osc!2)}).store;

~langs = ["192.168.2.5","192.168.2.6","192.168.2.7"].collect{|ip| NetAddr(ip, 57120)};

~count = OSCresponder(nil, ‘/count’, {|t,r,m,a|
var dc;
dc = m[1];
s.sendMsg(15, 1000, ‘dc’, dc);
~langs.do{|addr, index| addr.sendMsg(’/count’, dc);};
dc.postln;
}).add;

s.sendMsg(9, ‘NetOsc’, 1000, 0, 0);

//nirodha:
s.boot;

SynthDef(\NetOsc, {|dc = 0, vol=0.5| var osc; osc = Silent.ar + (dc*vol);Out.ar(0, osc!2)}).store;

~langs = ["192.168.2.5","192.168.2.6","192.168.2.7"].collect{|ip| NetAddr(ip, 57120)};

~count = OSCresponder(nil, ‘/count’, {|t,r,m,a|
var dc;
dc = m[1];
s.sendMsg(15, 1000, ‘dc’, dc);
~langs.do{|addr, index| addr.sendMsg(’/count’, dc);};
dc.postln;
}).add;

s.sendMsg(9, ‘NetOsc’, 1000, 0, 0);

//marga:
s.boot;

SynthDef(\NetOsc, {|dc = 0, vol=0.5| var osc; osc = Silent.ar + (dc*vol);Out.ar(0, osc!2)}).store;

~langs = ["192.168.2.5","192.168.2.6","192.168.2.7"].collect{|ip| NetAddr(ip, 57120)};

~count = OSCresponder(nil, ‘/count’, {|t,r,m,a|
var dc;
dc = m[1];
s.sendMsg(15, 1000, ‘dc’, dc);
~langs.do{|addr, index| addr.sendMsg(’/count’, dc);};
dc.postln;
}).add;

s.sendMsg(9, ‘NetOsc’, 1000, 0, 0);

//sunnata:
NetAddr(”dukkha”, 57120).sendMsg(’/count’, 1);

for those of you nerdy enough to withstand the source code, your reward is the following ascii graph:

where dukkha and marga invert the signal before passing it along, and samudaya and nirodha simply echo the same signal back.  if the network were arranged as a loop, instead of being fully distributed, each node communicating with the next instead of broadcasting to everyone, it gets trickier to make the system oscillate.  for this behavior to emerge, we must have an odd number of inverting nodes.  however, the distributed topology of this network allows us to have an arbitrary number of inverters.  next, i will try out different topologies and mixes of individual node behaviours, and also different sound mappings…

Ron Kuivila and I have been working on some SC3 code that would allow for remote interpretation of the language across a network.  Of course, there already exist several options for the SC3 user that provide various advantages (Client/LocalClient, BroadcastServer, oscGroups, PB_UP, etc), but these were way too complicated in their implementation for my needs, and provided features that I simply had no use for.  The result is very paired-down and simple to use.  On the local side, there is a window for typing SC3 code, with a header consisting of a smaller text box for the target IP.  

Entire blocks of SC3 code can be placed into the window and interpreted remotely (also works on loopback) by pressing enter.  The overall behavior is a lot like the SC3 IDE, although somewhat limited in terms of key-commands.  However, this allows me to simply write my code in the SC3 system and remain there in order to execute it remotely.  On the remote side, all that is necessary to run is SC-Lang and an OSCresponder that listens to calls from the local machine.

There are other advantages to this approach over others, namely that each instance of this editor can be used for communication with a different node on a LAN.  As a result, the process of composing for 4 networked machines has become rather simple, no longer the logistical nightmare it once was.

Despite my naming the paradigm “remote_lang2.0″, it is still in the development stage.  Additions to functionality must be added before I can say this stage has been surpassed.  For now I have to keep an ssh tunnel into each of those remote machines in order to view post-window data.  This is in the process of being improved.  Also, I’d like to see a command-log for each window, so I can save a document of legal SC3 code as a transcript of the commands sent to each server.  Furthermore, there are some environment access issues that should be solved before I’ll be totally happy with it.  But this is a start, and allows me to actually get back to composing instead of trudging along in emacs.  For the curious, you can download the code here.

(click here for sound) 

one particularly dumb thing you can do with a network is arrange two nodes to bounce messages back and fourth as fast as they possibly can, like a game of ping pong. while activity this is fun in and of itself (at least perhaps for some), the more interesting things occur when we tie the act of sending and receiving to something we can experience directly. the first thing i tried was to have either node count the number of times it caught a message and threw it back. this was interesting for about three seconds, which is just about how long it took for a packet collision to stop the whole process anyway. then i had a particularly stupid idea: why not use a network as an oscillator? here’s what happened:

so most simple square-wave oscillators work by outputting a ‘hi’ or in our case a ‘1′, feeding that back into the input, inverting it to a ‘low’ (-1), and starting the process over again. using various methods of ’slowing down’ this feedback process, we get differences in what we perceive as pitch (or rate, if it’s lower than ~20hz). unfortunately, i decided this would be fun to accomplish over a udp network.

in the above tastefully coloured ascii diagram, you will notice a main feedback loop between two nodes whose names are in Pali: Dukkha, translating to ’suffering’, and Sunnata, or ‘emptiness’. Don’t worry about my mental state– Dukkha is the first of the four Noble Truths of Buddhism (aka the Cattri) and the concept of ‘emptiness’ given this context is actually much more complex than it is angsty. in addition to these names are assignment operations taking place on variable ‘i’: i=-1*i, and i=i, respectively. this is an abstraction of the process that takes place inside of a schmitt trigger or some similar square oscillator. however, in this implementation, the rate at which the system feeds back is directly related to the conditions of the network, which is being utterly flooded with messages at a rate that is limited only by the language that is sending those messages, in my case SuperCollider. since, as i said before, packet collisions generally stop this game before longer than a few seconds, every once in a while one of the nodes sends out a message that isn’t contingent on the other node, just to keep things rolling.

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.

author’s preface: this is probably one of those ‘youthful indiscretions’ people have a tendency to regret after a few years… oh well.

i’ve said it before and i’ll say it again:  this somewhat unquestioned notion (at least in certain circles) that “an instrument is a performance tool that amplifies greatness” bugs me.  it bugs me almost as much as the glitzy, technology-driven gizmo cultures that find it to be so self-evident.  occasionally i hear the resounding snarl of zappa’s “big swifty and associates” in the detritus of the program i participate in.  we (all of us) are making feeble abaci from piles of sand.  tomorrow, what will keep the systems we worship like desiccated fetishes backwards-compatible and airtight?  my g4 died just two months after my senior concert at wesleyan, and with it died code and file-systems and programs necessary for the reproduction of such a performance.  most of the synthesizers i wrote for the ‘composition’ (ie recording into a buffer) and ‘playback’ (interpreting those files appropriately) of those pieces no longer work in the recent builds of scsynth.  i have not tried to update most of them.  the only idea that seems to have survived is “the king of pentacles,” wherein a guitar player, having detuned his strings, uses his instrument as a source of an amplitude curve, the primary control signal for the piece.  another idea of that era which has survived is to use the process of cooking and burning meat as a source of control voltage for sonification.  i even cringe at the word ’sonification’ now, because it is absolutely meaningless to me anymore.  don’t most processes already come with sounds ‘built-in?’  aren’t they usually way more interesting than any of the crap a computer can do right now?  even if it in some oblique way uses the ever-revered (if only because of IDM) granular synthesis, the fetish of all fetishes?  i feel like somehow i was warned about this, but i was too indolent to listen.  i have to be honest, i’d be more inclined to quit making computer music (and perhaps music in general) if one of my compositions got sampled by radiohead… paul.  i also recognize that to do so, aside from its sensationalism, would simply emphasize the problematic logic to which it is a response.  not that i have that much pull.  better to allow my attention to be captivated by my surroundings and to respond accordingly.  another thing that bugs me is the fact that in order for the realization of a digital system or networked composition to be considered ‘performative,’ it must be written and interpreted by the programmer(s) and machine(s) respectively on a stage, in front of an audience, otherwise the performer must use some morally degrading control interface, otherwise it’s an installation.  i have an updated version of 4′33” you all might like- the performer brings her laptop on stage with her and plugs it into a projector.  she then proceeds to steal the neighbors’ wifi and check her email, refreshing the page three times.

Big Net.

a network:

(key for above network: – - – - means one time interaction; —– means constant communication)

a network with directionality between connections:

a network with variably weighted connections: