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.

http://www.youtube.com/watch?v=3BFrDjh0j4w&feature=channel_page

Despite the fact that the poster has misspelled my last name, I am grateful this documentation exists.  There will be more footage to come (thanks Clembie).

click to listen

a flooded network.  each node broadcasts the opposite value of what it receives, so signals oscillate from hi to low, reaching network capacity very quickly.  the nodes measure the time between messages, using regions of network lag as the organizing principle for hitting notes of various registers.

an idiosyncrasy of the code (whose artifacts i enjoy) causes the network glitches to come at regular intervals.  in later code this was fixed.  but in this recording, i find the fragile regularity of the rhythmic organization to be just varied enough to remain interesting for extended listening.  the resulting texture is somehow reminiscent of later Feldman.

also, karplus-strong algorithm ftw.

[

[ [ 15, 2 ], [ 24, 2 ], [ 22, 2 ], [ 14, 1 ], [ 27, 3 ], [ 16, 2 ] ],

[ [ 26, 7 ], [ 12, 2 ], [ 18, 3 ], [ 25, 4 ], [ 21, 3 ], [ 20, 10 ] ],

[ [ 28, 14 ], [ 30, 15 ] ]

]

(more…)

the meta-notation is as follows:

play silences of various durations. if you make a sound, you have made a mistake. make mistakes.

this should be familiar as i’ve been trying to realize this notation into a more concrete score over the course of this semester.

the rules for interpreting the score break down as follows:

roll the ball continuously through the entirety of the performance.  the figures you produce may be ellipses, figure-eights, or three-circled knots.  orientation (horizontal vs vertical) is open to interpretation, as is direction.

the score is comprised of an ordered set of events.  each event has two values: a duration and a number of loops.  produce a figure or set of figures containing the notated number of loops, over the notated length of time.

there is now a simple patch for generating score values, written in the supercollider language.  it is available here: www.joemariglio.com/window_proto/score_gen_0.rtf

if one runs the whole patch, what is returned is an array containing all the information for a single realization of the piece.  at the innermost level, there are tuples describing duration and loop number.  these are grouped into three approximate ’sections’, two lasting 120 seconds and the final one 60 seconds.  in practice, the performer only need note the durations and loop numbers, so this final parsing is omitted from the ~score environment variable.

this ‘divination patch’ is necessary to generate scores that are statistically identical in difficulty, but unique in particulars.  it is important that each performance be unique so that practice only improves ones ability to read the notation, leaving the possibility for mistakes due to score difficulty intact.

for those not fluent in supercollider, the algorithm is as follows:

all the possible durations for events are the non-primes between 12 and 30, inclusive.  no duration is repeated and they occur in no particular order (the order is determined with each realization).

break the durations into three approximate sections of 120, 120 and 60 seconds each.

the difficulty is determined to be the ratio of loops per second.  there are 5 approximate values for this ratio: 1/2, 1/4, 1/6, 1/8, and 1/10.  these are chosen anew each event.  distribution weights depend on which of the three sections the event is in.  for the first section, values tend toward 1/10, for the middle section, values tend toward 1/6, and for the final section, values tend toward 1/2.  the curve is exponential with a factor of 3.

the number of loops in each event is determined by the difficulty ratio * the duration.  this value is rounded to the nearest integer.

running the patch just a moment ago yielded the following score:

[

[ [ 30, 4 ], [ 25, 3 ], [ 12, 2 ], [ 16, 2 ], [ 26, 3 ], [ 22, 2 ] ],   //section ‘a’
[ [ 28, 7 ], [ 27, 3 ], [ 24, 12 ], [ 15, 2 ], [ 20, 3 ] ],   //section ‘b’
[ [ 21, 5 ], [ 14, 2 ], [ 18, 5 ] ]   //section ‘c’

]

since these arrays are pretty difficult to read, especially while rolling a ball around on a window and watching a clock, i am considering borrowing an idea from cage’s ‘cartridge music’, wherein lengths of time are denoted as arcs of a unit circle, one for each minute of the piece.  following the composition, then, is as simple as following the second hand as it travels around the clock’s face, and taking note of the regions that make up each minute.

as far as the resulting sound goes, i’m relatively content leaving things as they are.  i like the sound of the ball on glass, and i believe there will be enough bells and whistles throughout the nime concert to make this five minutes of focus and simplicity engaging.

i started trying to work out the notation system for this performance. the idea has been that, prior to each performance, a new score would be generated algorithmically so that the likelihood of my making an error would follow some nominal curve. obviously, if the score were static i would practice it, and thus throw off the whole effect.

i began by cataloguing each curve i could make with the ball on the surface. for ideas, i played with polar coordinate functions, and tried to narrow down the family of curves that would be most appealing on the materials. i found the lissajous family of curves to be quite nice, since they cover a rectangular area. also appealing were the rose curves, although eventually i determined those to be too difficult to execute. i limited my scope to lissajous shapes with a/b = 1 (ellipse), 1/2 (figure-8, infinity sign), and 1/3. these shapes could be oriented horizontally or vertically, and traced in a clockwise or counter-clockwise fashion. i decided not to explicitly state the direction, for several reasons. i found that treating the change of direction as an event itself made more sense ultimately.

as for durations, i decided simply to come up with some set of durations which add up to the target duration (5 minutes). then, as long as all elements of the set are used, the performance will always be the same length. i eventually landed on the set of non-primes between 12 and 30, although this could very well change.

i also wanted to parameterize how fast the ball should move, as this is the best predictor of failure in this system. however, rather than using the rate of shapes to produce, i decided a looser approach would be more beautiful. while this rate is used as a constraint for the composition algorithm, i will display the instruction in terms of ‘how many’ rather than ‘how often’.

i am currently using a metronome to keep track of seconds, and i think i’ll be doing that in the performance as well. other things remain less clear. i initially imagined cards would be sufficient to help me keep track of the tasks, but now i’m starting to wonder whether some kind of graphical display would make things simpler. i dislike having the score ultimately reside in the computer. perhaps i will eventually have the card system totally worked out and have both representations. the computer version is more a conductor than a score, really, so i think it’s ok as long as i get some kind of notation that has been printed out or transcribed.

i have been using the following (very simple, buggy) supercollider patch to test possible score outcomes and hone in on reasonable constraints. here’s what i have:

a = (12..30).reject({|x| x.isPrime});
b = 1/(1..5);
d = 2;
~score = Routine({
[
{
{Impulse.ar(1/d)}.play
},{
i = 1;
loop({
i.post;
" : ".post;
c.post;
" : ".post;
(c*e).round.postln;
i=i+1;
wait(d);
})
},{
loop({
"__________________________".postln;
c = a.choose.postln;
i = 1;
e = b.choose.postln;
"events: ".post;
(c*e).round.postln;
"__________________________".postln;
wait(c*d);
})
}
].fork
}).play;

and here are some lissajous pictures…

a/b = 1

a/b = 1/2

a/b = 1/3

* * *

also, as i got progressively worn down by the process of composing with logical constraints, i started messing with more feedback systems that used the window-ball system as a source of richness. using one piezo as a pickup and the other as a driver, i had previously been discouraged by the incredibly screechy results. taking a cue from a discussion with hans, i decided to try implementing a pitch-shifter into the signal path, to reduce the shriek and get some harmonically related and physiologically comfortable feedback. of course, instead of using my computer to do this, i breadboarded a simple circuit.

the resulting feedback was mostly noise-ridden, but every once in a while it would converge on a tone. i used the ball like a 2-dimensional glass slide on a guitar string, a technique which worked well, especially near either piezo. i discovered some rich aural terrain by trying to locate the node points on the glass. the resulting mayhem i posted here.

despite how fun that exercise was, i definitely would like a simpler nime performance than that. i think in other contexts, a performance like that would be awesome, and i can’t wait to try it with some of my other circuits and patches, but the dialogue i’ve set up is way too subtle for me to simply do a feedback piece as a result. mostly, i am relieved i still know how to make a circuit, considering i haven’t done anything but code and think all semester.

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 intend my nime performance to question some of the fundamental tenets of the nime conference. it might be pithily asserted that the project is neither new, an interface, nor for expressing music. the instrument is a found object (in this case a window) which is amplified with piezo discs. masses, such as a stone ball, marbles, and grains of rice are placed on the surface of the window, which is tilted manually by the performer to induce shapes like circles and figure-eights. prior to each concert, a score is generated with a computer program which notates the intended shapes, their order and durations. the reasoning behind generating a new score with each performance is to forbid mastery through memorization, and the reason for the computerized divination versus, say, bird entrails, is to parameterize the probability that the performer will make a mistake. in this case, a mistake may consist of many events. private ones, such as an error in interpreting the score, will not be noticeable. the public mistakes, such as a collision between a mass and the window frame, or one mass with another, will be amplified by the very nature of the system.

i was tempted at first to use complex machine listening algorithms to determine the event of a private mistake, or at least to better encode the public mistakes into synthesized note events. several prototypes of this patch exist, but i have decided to eschew convention and stick to the acoustic properties that charmed me in the first place. currently my plan is to produce an algorithm that composes well and with the intention of throwing me off, and to practice this task so i can give it a run for its money.

that being said, a subtle amount of processing will probably be added to the signal, to emphasize those beautiful resonant characteristics of the system. also, toward the end of the performance i may add a touch of commentary from the computer. but this will be tastefully done, if at all.

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…