Archive for the ‘Uncategorized’ Category

mornings sit on roofs

Tuesday, September 15th, 2009

every morning i spend in greenpoint, i climb onto the roof and sit for about an hour. i have been doing this since i moved into the place in july. my practice is nothing fancy, mostly just counting my breaths up to 21 – if i make it that far – and starting over. sometimes i repeat specific phrases.

the neighborhood is rather industrial. largely it consists of auto-body garages, construction shops, and the water treatment plant. the first thing i noticed about the area was the beautiful swirling hiss that the plant emits. on some days, the various metalworking machines pound polyrhythms, their origins confounded by their reverberations through the concrete.

the recording was made on a pair of binaural microphones. they can very closely simulate the experience of being there listening to the sounds they record. i recorded for just over an hour straight, and i left the recording completely unedited and unprocessed. it won’t stay that way, but i wanted to start by presenting the entire hour untouched. unfortunately, it was somewhat windy today and the wind-guards couldn’t keep everything out.

i truly enjoy these mornings. it was a pleasure bringing you along with me this time.

acousmatic comets

Tuesday, September 8th, 2009

today i started working on some sound design for an acousmatic piece.  i mentioned in an earlier post that i was interested in working on a few compositions with more narrative presence.  in the itemized list you’ll find in that earlier post, this piece is #3a– or as i have come to call it, “the damned grotto.”  it’s inspired by the gorgeous scene in “harry potter and the half-blood prince” where dumbledor fights hordes of the living dead with fireballs as they climb out of the black water in a cavern.  for tonight’s work, i laid the foundations (still buggy) for some of the sound design in general, as well as specifically beginning the design process for a short (~14.5 second) sequence where a few fireballs skitter by and ignite some debris in a safely distant part of the cave.  everything needs work, nothing is final.  any criticism would be helpful at this stage.

click here to look at the code.

click here to listen to the sample.

ps- thank you so much, freesound!  and more specifically, thank you, homejrande for your beautiful field recording!

reel whirled

Tuesday, September 8th, 2009

i’m fixing this otari mx5050 8-track reel-to-reel for a client who’s a recording engineer. this thing is so pretty i thought i’d share some pictures:
mx5050_0

and here’s a shot of it in my studio.  i just might have to “test” it -by recording some stuff- once it’s fixed.  it’s kind of like how parents justify eating their kids’ halloween candy by saying it could be poisoned…

mx5050_1

mmmm poison…

hackpact day 1

Tuesday, September 1st, 2009

for a definition of what hackpact is, or who else might be doing something like this, see the dedicated page on the TOPLAP website.  essentially this all means I’ll be making and documenting one creative thing every day for the month of September.

for this first piece, i decided to go with something that could be thought of as both complete and as a spring board for a few other projects.

I drove out to San Fransisco with my partner of 4 years.  We made quite the road trip out of it, staying with old friends along the way.  It was such a great experience.  I love driving, and it took a particularly brutal stretch of road– which lasted for more than 20 hours and landed us somewhere in Montana– to get me to give up the wheel.  Something about the constant state of focus really calms me down and helps me think.  We had been living together for about 3 years, and both of us were looking forward to this summer as a way of establishing some space before she started classes at San Diego in the fall, and I moved out there with her.  Unfortunately, it doesn’t look like this is going to happen anymore.

Along the way, I made quite a few field recordings.  I brought a cheap but discrete lav mic and set up my computer to record in just about each place we stopped and stayed during our trip.  The recordings are unique because they are the result of a simple supercollider patch.  Every 12 seconds or so (I experimented with the specifics as I went), the patch recorded one second of audio.  The resulting streams I stored as individual files in a directory tree, so that someday I’d figure out what to do with them and iterating over them would be simple.  Today is the first time in a long time that I’ve listened to these recordings.

My hackpact goal for today was to come up with a simple assemblage for one of these micro-recording sessions.  While I am not totally satisfied with the assemblage as a self-contained whole, my secondary goal for today was to end up with a framework for playing with similar material in the future.  This piece uses the entire last night we spent together.  It’s very personal, and I find it pretty difficult to listen to.  Hopefully you’ll find it beautiful.

Here’s the code:
//load all samples in directory:
(
var pipe, line, dir, index;
dir = "/Users/josephmariglio/Music/samples/pennsylvania/sf/";
pipe = Pipe.new("ls -f"+ dir, "r");
line = pipe.getLine;
index = 0;
while(
{line.notNil},
{
var path;
path = dir ++ line;
Buffer.read(s, path, bufnum: index); line = pipe.getLine;
index = index + 1;
});
pipe.close;
~num_bufs = index;
)
//a synthdef for playing them:
(
SynthDef(\samp, {|rate = 1, vol = 1, out = 16, buf = 0| Out.ar(out, (PlayBuf.ar(1, buf, rate, doneAction:2))*vol)}).store;
)
//define patterns to arrange the sound-events
(
~a = Pbind(*[
instrument: \samp,
out: 0,
buf: Pseq((0..~num_bufs), 1),
dur: 1
]);
~b = Pbind(*[
instrument: \samp,
out: 1,
buf: Pseq((0..~num_bufs).reverse, 1),
dur: 1
]);
)
//play them together
[~a, ~b].do{|x| x = x.play;}

So the piece is a near palindrome, made up of a stream of samples indexed diachronically and reversed, one stream on either channel of audio.  They meet up in the middle.

Click here for the mp3.

hackpact 09/09!

Tuesday, September 1st, 2009

For a definition and links to other participants, check out:

http://toplap.org/index.php/Hackpact

Basically, I want to use this month to make and document something small, creative and techie every day.  I imagine these things will be mostly sonic in nature, but i can’t promise that I won’t document at least a few days of breadmaking or some other such thing.  Since I’m not sure where the month of September will take me, I also have to keep my options open regarding the mediums I’ll use.  I’m going to venture a guess and say there will be mostly analog circuits and supercollider patches, with perhaps a few python things and the occasional loaf of bread.  I’m starting the month off by making an assemblage from the field recordings I took this summer.  Stay tuned for documentation…

a few summer projects

Wednesday, July 29th, 2009

I spent June traveling across the continental USA, visiting friends and making field recordings.  I will cover that month’s activities in a future post. 

In July, I moved into a retired auto-body shop in industrial Greenpoint.  I am helping my flatmate convert it into a recording studio.  In the meantime, I have been fiendishly networking and putting together creative projects.  Starvation and searching for jobs have also taken up some time, as well as taking online TEFL certification classes and reading up on the GRE.  The ideas I have for projects are as follows, in no particular order:

1) I have been playing the piano a lot more regularly.  I want to start incorporating my love of home-brew analogue electronics with my fake (but much lighter) electric piano, in preparation for buying an old fender suitcase once I move out west.  I’ve never stopped loving to play piano, but only recently have I regained faith in it as a significant creative tool.

2) Learn MATLAB.  It’s actually quite simple and well documented since it’s commercial software.  Obviously I stole it, but if I start using it a lot I might get whatever Ph.D. program I end up in to pay for a legit version.  A cursory glance at the signal processing and wavelet libraries suggest some cool and very musical applications.

3) Acousmatic “scenes”.  I am interested in using sound design to create narrative, stylized experiences.  This occurred to me while watching the latest Harry Potter movie (the dialogue for which was ridiculously bad).   I found that many times, sound takes over and carries the experience for the audience when other cues fail.  While there exist conventions for how this sound-language works, they are by no means rigidly defined, and certainly not purely representational.  I often think of musique concrete and acousmatic musics as analogous to computer animated features: the same ‘uncanny valley’ must be avoided.  Successful CGI commonly employs a healthy dose of painterly sensibilities, and de-emphasizes the ultra-photo-realism that plagues the genre.  I have specific scenes in mind that I want to do.  Briefly:

a) The scene in the new Harry Potter movie with the zombies and underwater fireballs.

b) A dream I had about screaming, tearing my clothes off and running into the forrest surrounding the village I lived in.

c) Waiting in a clock-garden.  Birds giggle and turn into distant female archetypes.

4) build a composition using successive passes of impulses and convolution with new impulses.  i’m talking either digital band-limited impulses or analogue logic circuit impulses.

5) take two inputs.  find approximate pitch (using autocorrelation) of input 1.  find n strongest partials of input 2. granulate input 1, retuning grains to each partial, remapping partial amplitude to probability weight.

6) using geometric series for rhythms.  

7) fix and expand Cattri into a new cluster currently missing a working title.

Items 1 and 3 are more like ends to means, while 2, 4, 5, 6, and 7 (and others not listed here) are more like means to ends.

On top of this, I have several projects I am working on for others.  They will also be documented as photo- and recording- ops present themselves.

repel study

Friday, March 20th, 2009

Each ellipse corresponds to a pitch in a constellation, with regular occurrences (events of ‘striking the bell’) determined by position in the window (frequency vs phase). Ellipses have a mass directly proportional to their size and inversely proportional to their pitch. The ellipses are attracted to each other according to gravitational laws, and repel each other according to a ‘force field’, whose magnitude may vary across the arc of the video. When two ellipses repel each other, a transient sound event (grain-like) occurs, whose spectrum is determined by the ratio of the two pitches involved. When more than three ellipses repel each other at once, a squealing bowed metal sound occurs, also related to the ratios between constellation pitches.

I wrote the code in SuperCollider as part of an effort to clean up the sourcecode for other pieces based on dynamic systems, such as Sanction of the Victim‘s flocking algorithm.  Actually, this study uses SoV’s pitch constellation and mapping of frequency and phase to x,y coordinates. SoV’s debut performance at Diapason used classes based on Fredrik Olofsson‘s “Red Universe” class library, which I modified to get a “Boids“-esque behavior. While his class library was useful as a springboard, I found its implementation slightly troublesome. Not that his code was somehow bad or anything, but there were a few things I would do differently. Specifically, the reliance on inheritance made for confusing code, although I assume that his reasons for using that style were didactic. So my project has been to rebuild a class library specific to my needs and coding style. This gravitational forces study contributes to that effort.

Source code for the above movie available here: Class Definition, Implementation Script.

markovSamp.py

Monday, March 16th, 2009

here’s a simple markovian sample munger written in python2.5.1. should be compatible with 2.6. all bets are off for 3.0.

analyzes wave files. don’t be a joker and run mp3′s through it unless you’re willing to accept the consequences.

it takes a really long time to generate transition tables for each sample. this is mostly because i’m new to python and my programs are not optimized. eventually i’d like to have some flag that lets you save transition tables based on samples so you can generate new soundfiles from old transition tables without having to re-analyze the soundfile. on any reasonable machine hovering around 2 ghz, a one second sample takes a few seconds (<30) to analyze. generating the soundfile may take a few seconds depending on how long a file you asked for. run the script without params to get its usage. usage is also covered in the comment block at the top of the script.

usage (assuming python aliases python2.5 / 2.6):

python markovSamp.py <path-to-infile (unix-legal paths only)> <depth (samples per unit)> <length (number of units in output file> <path-to-outfile (will write to new file if filename doesn’t exist at path)>

happy munging!

ps- I used this script to generate the following stereo signal from one of the Unwashed guys’ dark psy kicks.  They called it ‘the monster’, hence the name.

Markov Monster

eee

Saturday, January 31st, 2009

I recently moved my portable work environment to an Asus eeepc 901 running Ubuntu (Easy-Peasy).  I actually did the install while it was still being called “Ubuntu eee,” and made the remark “easy-peasy” after completing the install.  The name is that appropriate.  Not kidding.

Beyond installing and configuring it, the move to ubuntu was likewise fairly easy as well.  My homebrew OSC cluster runs ubuntu server, so I had cut my teeth using linux without a GUI.  I compiled supercollider on the little guy.   I went with gedit instead of emacs for this laptop because I was getting tired of all the wacked-out key commands.  I’m still running emacs on the servers though, because I don’t really code directly in that environment.  Quickly I learned that the IDE in linux is very different than the IDE in OSX.  For one thing, GUI is handled completely differently.  This isn’t too much of a problem as most of my work is GUI-free, but that rule has the notable exception of remote_lang2.3 , the interface Ron Kuivila and I wrote to simplify the process of writing distributed code, as well as to protect me from karpal-tunnel syndrome (which Ron claims is the direct result of too much emacs).  While I can neither confirm nor deny its effect on my numb fingertips and shooting forearm pains, the patch is absolutely essential for me to effectively develop networked code.  I have now altered the source code to work with gedit.  It’s still as simple as I could get away with, because I’m not really interested in flashy UI tricks.  Behold.

You’ll notice it’s not an .rtf file anymore.  This is because both linux implementations of supercollider currently do not support anything but plain text files.  I am way into this.  To reformat all my old sc work into plain text, I wrote a script.  Actually, since sclang is the culprit for adding / managing the formatting anyway, I figured I’d let it sort it out.  So I wrote the script in sclang.  There is a certain type of programmer that might cringe at this, and there is a certain type who will find it funny.  I am the second type.  Behold.

As for my karpal-tunnel, I have started baking bread.  Kneading dough for ten minutes at a time is really good for the tips.  It’s also a great thing to do while code is compiling.

sounds herd

Saturday, December 27th, 2008

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.