Steve’s Stuff

Allow me to preface this entry by saying that this is an assignment for class and of no interest to anyone not enrolled.

——————————————

For my part, finishing my project was nothing more than ‘time to stop composing and play what you have’. I came up with new material until the night before the opening. If I had another week, I’d probably have another two or three tunes to play. Sometimes a deadline is good because it lets you know when to stop. John Zorn theorizes that Schoenberg used poetry settings in so much of his music because his 12-tone system didn’t provide a clear way to know when the piece is finished and so he wrote until he ran out of words. Interesting. I guess I did that by writing until the show. I ended up with eight tunes, but even when stretched to ten minutes each, it’s still less than an hour and a half. The other thing is that since I was writing all in a short time period, a lot of the songs have a similar feel. Normally I’d spend this much time on one composition, but it would be a lot more complex. I don’t think it mattered ultimately because anyone seeing the show is probably going to hear one or two tunes tops.

The assignment was to be installed and ready by class on Wednesday, so Team USA made our way to 414 on Tuesday to set stuff up. Of course nobody was there yet, and strangely, many people didn’t show up at all. We started by covering the large windows in our back area. Keith was apparently fine with climbing the ladder a whole lot, so he did the nailing. We got our side finished pretty quickly.

After that, Tyler and Keith began installing the “disco” lights. Since we weren’t able to put nails in the wood, the engineers had to get creative. Luckily there were some wiring conduits and fixtures to hang out stuff. We experimented with strobe light placement and found that it worked best pointed at the back wall.

Keith N. was generous to let me borrow his PA system. He brought it that evening and we tested it with my laptop listening to some quasi-Arabic dance music and good ol’ Joe Satriani.

I didn’t go in on Thursday because Keith just needed to install the sensors. He ended up staying from 1:00-7:30pm. I think there were some setbacks or something because he described the installation processes and frustrating.

On Friday, I packed up my gear and went down town to get the music ready. I ended up getting it all to fit in three bags, plus a large midi keyboard, the CPU, and a monitor. Not bad. I unloaded and the made another trip to WSU to load up a table for my gear. Keith N. brought his awesome van to help me get the table down town.

It sure is easy to write when the topic isn’t thesis driven. I could crank out the descriptive crap all day long. I could crap out the descriptive crank all day long. I crank descriptive could all the crap long. Crap, I crank the descriptive day could all long. Could I crank out the long crap all day descriptive. Long crap descriptive crank I could long all day.

Installation of my sound gear was uneventful. I plugged everything in and it worked as intended. Keith’s sensors worked more-or-less as intended. In the end, they were tripped pretty frequently. We eventually decided to keep the spinning ball going the whole time to add some ambience.

The scales we backed (things we scaled back), were the number of sensors and the sound baffle. That looks like “sound waffle” - I wonder what that would look like. We didn’t construct the sound waffle for a few reasons. The walls from shift space were in bad shape. They were in such bad shape that I would have had to cut a 4-5 inches off each side and repaint. Plus, once I did that, I’d have to build a brace to keep them erect. If they could at least stand on their own, I’d have put them up. As it turned out, I played the music at a satisfying volume and didn’t get any complaints. It was nice to be able to see the whole gallery during my performances.

As I said before, our installation was uneventful. Keith’s sensors were simply a matter of plugging them into the wall - the logochip that is - he ran it off a cell phone charger so we avoided the battery issue.

As hoped, I’m starting to get a lot better making music with a lot of gear. I think the trick is having one or two elements that are unobtrusive, but can hold everything together. This gives a sense of continuity as well as providing some musical content that I don’t have to constantly worry about.

Another trick is focusing on one thing and not trying to micromanage. It’s like the first drum set situation - the little drummer has his/her first drum set with all sorts of drums and cymbals and they want to get around to all the different sounds at every opportunity. As expected, this isn’t very musical. For some reason I had to relearn this lesson over the course of a few hours.

Playing two midi keyboards at once is not actually all that difficult as long as you’re not trying to play two radically different things at once. I have it set up so one is usually a bass sound and the other is some sort of pad* or lead sound. The second midi keyboard is significantly more limited because it controls the Roland synth module. The Roland synth module is very very lame. The only usable sounds are a biting square wave, a nasty saw tooth patch, and a mellow pad-like patch. Most of the variety is going to come from Reaktor.

I’m not using the drum machine all that much right now, but Lauren plans to join me at times during the show, so I imagine she’ll put it to good use. The cool things that I’ve found to do with it include running it through the Alesis FX unit and totally overloading the Alesis until it starts freaking out and making “bad” sounds.

The Alesis is a bit tricky to control. It’s old and I’m not 100% sure that it’s functioning properly. It really only has the three controls that one would expect (In, Out, and Mix). I’m getting some interesting results by running a totally wet (meaning totally processed, as opposed to partially processed) signal at extreme output levels. I can manage the overall volume with the mixer so nobody is going to go deaf. When you overload the Alesis it does weird things in addition to the normal feedback and infinite delay effects. Random squelches and squeals are always fun. Always.

This is a sample of my short hand that helps me get things set for a particular piece. From here, I have all the settings that I need to remember. You’ll probably wonder where the notes themselves are. That’s the easy part. I don’t need to write it down.

Song 4
R:SongD.ens
MID1:Equi4
MID2:082Saw
K:PR1
AFX:84
IN:6
MIX:6
OUT:6

*a pad sound is something full and rich in texture that can go on underneath a more active melodic line. They’re typically used for chords and such.

First the music -

As I previously posted, I’ve switched from Pd to Reaktor for the majority of my sound design. This is because it offered a lot of power and flexibility in a short amount of time. Had I had maybe an extra three weeks, I would have probably been able to use Pd instead. See my previous post on Reaktor for more info and for some screen shots of the Reaktor code.

I’ve spent hours composing frameworks for improvised electronic music. The frameworks have a number of components: first comes the musical idea (what I want it to sound like and communicate), second is the tools to produce these sounds, and third is practicing using the tools so that I can adequately realize my ideas.

Reaktor has on average 30-50 controls per instrument. I don’t need to use all of them all the time, but it’s nice to control functions like filter cutoff and resonance, amplitude envelope, formant center, and usually two or three other parameters specific to the instrument. This is the classic electronic music conundrum - the interface presents many options, but they require virtuosic manipulation if real-time sound synthesis is desired.

I’ve mapped a number of important controls to midi instruments to solve some of these problems. I’m controlling Reaktor with an M-Audio Radium 61 keyboard that comes with 8 knobs and 8 sliders. I’m also using an M-Audio Oxygen 8 v2 to control a different synth module (more on that later).

Regardless, control over five+ software instruments plus mixing both within Reaktor and externally for live sound is no small task. Reaktor sounds are fed through a virtual mixer with the resulting submix sent to an external FireWire mixer. At this stage, I’m adding some hardware including an old Kawai R-50 drum machine, an Alesis MIDIVERB II effects unit, and a Roland synth module. I’ve connected the Alesis FX unit through the mixer as an auxiliary send, which enables me to apply it to any track (e.g. the Reaktor feed, the drum machine, the synth module).

I’ve posted a number of experiments on the wiki. I have one week to practice, so hopefully it will keep getting easier with more interesting results. I may hit up a few musical friends if they’re in attendance just to keep things interesting.

Now onto the other parts of the project -

Keith has six light sensors working with his logochip. He’s planning to install a black light in the middle of our area with his light sensors all around. The audience will walk between the light and the sensors and this will trigger his lighting effects. I’m not sure how they’re programmed, but he will probably have more to say on his blog.

Tyler is taking care of the construction of the walls. Our presentation needs to be dark so that our light sensing works and it needs to be closed off so that our lighting effects don’t interfere with other installations. Tyler is also still working on his infinity table.

We’ve already scaled back a couple things. I was hoping to use ultrasonic sensors instead of light sensors so that we wouldn’t have to place a light in the middle of the floor. Keith made some attempts at using an ultrasonic sensor, but opted to go with light because it was much easier. I’ve made a few adjustments as well such as the switch from Pd to Reaktor. I would also have liked to have Keith and Tyler do more with artistic lighting design. As it looks right now, the lights are simply triggered on and off by the sensors. This is a partial victory, but it’s a very simplistic type of interaction (one that almost isn’t work doing). But, it’s what they had time for. I feel like with an extra week, Keith, Tyler, and I could get together on the creative elements of the show. With the time available though, we’ve had to make sacrifices.

Overall our show won’t be a total failure, although it will be more difficult for the audience to see what we’re trying to say (hi/low art). Worst case, people think I’m the DJ for the event - a horrible, experimental DJ playing his own music that nobody wants to hear. Heck - they my not even realize that I’m making the sounds on the spot. I’ll do my best to explain that or have my team mates explain it.

Sorry that there aren’t any pictures. There’s really not much to see. It is, afterall, music . . .

Success! After trying so hard to get Pd to play long samples, I finally decided to learn some Reaktor programming. Reaktor is a modular synthesis environment from Native Instruments. It’s a lot like Pd, but it’s a lot easier to make interesting software instruments. For instance, if you want an array of wave forms to choose from, you just create an oscillator bank whereas in Pd you would need to calculate all of the different waves you want to use, leaving a lot of room for error and such. It’s particularly useful for things like filters and reverb. In Pd you have to design your own filters (lots of math involved), but in Reaktor, you can just drop in what you want.

Yeah, this makes it a lot easier, but that doesn’t make the results invalid - just efficient. I’ve used Pd plenty. I know I can build most of the things in Reaktor, but it takes so long and I don’t see the point when I have a better tool available. Pd is a great learning tool and using it allowed me to jump right into Reaktor without much trouble.

Anyway, the point is, Reaktor has a multi channel “tape player” that stores audio files of any size in memory and can play them back efficiently. Pd just never offered any good way to do this easily, so I’m switching mostly to Reaktor. When I say “easily” I mean, a way that I could figure out in three weeks. I’m sure plenty of people have done similar things in Pd, but they probably have double my programming experience or more. In the end, all that matters is that it works. No extra points for doing it the hard way.

This shows Reaktor’s Tape Player

This is the top-level Reaktor code

This is some lower level code. As you can see, it’s basically connecting modules like in Pd. At its most basic, it has all the same low-level objects as Pd, but it also has a great library of ready-made stuff.

I’m doing a bit of video work for J.C. Combs’ final percussion ensemble concert. He’s created a tribute to Harry Partch, one of the most prominent microtonal composers. Partch was a renegade free-thinker who broke the bonds of Western tonality and equal temperament (the common tuning practice of the West) by creating a unique 43-note scale and an array of original instruments. My task is to play some video clips from a Harry Partch documentary along with editing and a few other tasks. All the clips were preprocessed so by the time Pd is involved, it doesn’t have to do any stressful video work.

I’m used to using PDP and PiDiP, two Pd externals that are fairly decent at image-based processing of live video. They’re not so great with pre-recorded video. I may have just mentioned this in a previous blog post, but allow me to repeat how annoying it is that the software designers decided to only support some obscure Quicktime codec that is now long gone. PDP supports .avi, if I remember correctly. Huh. That’s funny. .avi is a Windows format, but PDP isn’t even ported to Windows. Who came up with that great idea?

Fortunately, GEM (Graphics Environment for Multimedia) is a much better Pd external complete with a little documentation and some tutorials. Building a video player was mostly a matter of looking through the help files, reading a couple tutorials, and putting it all together.

The first step is to download Pd-Extended. It’s got all the major Pd externals included. I’ve included my patch below, although you might as well just go through some of the help files to make your own.

As you can see from the Pd code below, everything is straightforward. The [gemwin] object creates the window and accepts a number of messages including dimensions, border on/off, cursor on/off, and rendering on/off. Make sure you send dimension and border messages before creating the window. It’s easiest to stop rendering while you’re not actively watching a video. I didn’t run into CPU problems, but you never know.

The [pix_film] object played my QT files without and problems. Just send it a message with the file name and path. You can go frame-by-frame, auto-play, and see the total number of frames in the movie. I added a gain control [pix_gain] so that I can do nice smooth fades. Finally, you supply the dimensions of the video output. It’s a little confusing because you create the GEM window, but then you also have to specify the size of the video output within the GEM window. It would be nice if GEM automatically scaled the window so that you could use an object like [rectangle 4 3] and it would keep the same aspect ratio without you having to figure out a size that’s close.

There are a few objects left over, so just ignore those. I should have just deleted them. I found GEM video playback to be very high quality, but easy on the processor. I recommend it for anyone wanting to play video in Pd.

This is not pretty, but it works. Here are the steps . . .

1 - a band opens file.aif
2 - after a 10ms second delay, readsf~ receives the bang
3 - file.aif plays
4 - after the initial bang, a 100ms delay is triggered and opens the same file.aif
5 - after the initial bang, a 56 second delay is triggered and begins playing the second instance of readsf~
6 - after the first instance of readsf~ finishes, it outputs a bang
7 - that bang is sent to a 100ms and 56 second delay and begins the cycle again

*UPDATE*

okay, so this doesn’t work with multiple audio files. Pd is unstable and crashes after a few cycles.

At Professor Harrison’s suggestion, I looked at Zexy (a Pd external) to see if it’s multi-track recorder object would be useful. I still run into the problem of having to rewind the object once it plays through the sample. The object looks interesting for multi-track recording and playback, but it’s not really any better than readsf~ for my purposes. It would be faster to simply rewind a file as opposed to re-opening it as readsf~ requires, but it’s not significant enough to forgive the following hassle . . .

The Zexy object uses the .RAW format, whatever the heck that is. I’ve never seen it before. It’s always frustrating to me that Pd always wants a screwy file format in order to work properly. Sure, it’s got a wave and aif player, but some of the objects need bizarre codecs that are long sense gone. How hard would it be to figure out something standard and stick with it?

I’m going to go with the dueling readsf~ files tomorrow. Hopefully that will behave as I intend. More on this later.

I started doing serious work on the Pd programming for my project. The goal was to build a software sample player and live performance patch to tie everything together. As it happens, Pd is not exactly built for this.

There are two objects to read audio files: readsf~ and soundfiler~. The former streams the audio from disk while the latter writes the audio file to a table that you can then scrub through. The idea is that there are some rumbling, drone sounds that occur while the installation is at rest. As people enter the installation space, the patch begins to react and the calm, peaceful samples give way to more activity.

Anytime you’re working with audio files, you’re pretty much streaming them from, if you’ve broken your HD into volumes, the fastest part of the disk. This is crucial for uninterrupted playback. Unfortunately, readsf~ doesn’t work well with looping. Pd requires you to re-open the file each time you want to play it and then send the object a “start” message. This introduces unacceptable delay on the order of seconds (!) - may not sound like a lot, but your ear will easily pick up on millisecond delays. Mine will anyway. It’s not even that I’m getting a little zipper noise - it’s flat out dropping out for a second or two.

I experimented running two instances of readsf~ so that the second gets cued up seconds before the first finishes in hopes of moving seamlessly between the two. This works a little, but not great. It reduces the delay to a few milliseconds, but there’s still the issue of zipper noise.

One possibility is to tweak this configuration, but it’s horrible programming and needlessly complex. As a last resort, I will try sizable fade-ins and fade-outs to give me some breathing room with the overlap. It’s not a huge deal because I’m not working musically in the temporal sense. There are no beats or pulses - just atmospheric ambience. If I DID want to add beats, this will not work at all.

Soundfiler~, as I said before, writes the audio files to a table. This is great for short loops. You connect a sawtooth wave to a tabread~ (table reading) object and it continually cycles through it. You can even go backwards or scrub through the waveform. The problem with this approach is that all the sound files eventually get stored in the patch. My 60-second samples that I want to loop each need a 2.5 meg graph to hold them. Once more than two of these are present, Pd starts behaving erratically. It becomes unstable to the point that it’s unusable.

A possibility for this method is to cut my samples - maybe to one 8th the size. Then they will loop fine, but they’ll also be fairly short and anyone who stands just beyond the installation will be able to notice the same sounds repeating over and over again. I could work with randomly alternating samples so that periodically, something changes, just infrequently enough to not be easily detectable.

So, I’ve got one object that’s good for streaming, but bad for looping; and one object that’s great for looping, but bad for reading. As the guy trying to remove soap scum from his shower with a tooth brush always says, “there’s got to be a better way!”

I’m disappointed that I’ve used the term “deconstruction” in the title of my TASD project (see below) and *nobody* has attempted to call me on it! It’s one of the most controversial moves I could possibly make. The term is thrown around with such ease and misunderstanding that surely someone is skeptical enough to at least question that I know what I’m talking about.

It’s actually a bit scary because perhaps nobody has questioned my usage because they (shudder) feel that have a sufficient understanding of what deconstruction is. Yikes. I’m not saying that I’m the only person who actually understands it, but I can be fairly confident that after a few years of study and hundreds of pages of reading, I have a good handle on it. I am also in a position to observe countless misuses, misunderstandings, and misrepresentations of Derrida’s ideas.

I hope if someone is reading this, they’ll speak up to find out if I’m full of it or not. I welcome debate as I’m sure we each have our own view of postmodernism even if they’re essentially the same.

I’m risking pedantry here, but I feel strongly that we have an amazing amount of great words in the English language and we either a) use the same ones over and over as if the words “cool” and “sucks were the only words we ever learned; or b) use words with very specific meanings casually and generally without necessary understanding. Lets put an end to this sloppy practice and hold each other accountable for our language.

The central idea at work is the mixture of “high” art and “low” art. Where a traditional modernist position focuses exclusively on high art, a postmodern position is open to the use of so-called low art techniques. The term “disco” is being used to refer to a dance club environment and should not be confused with 70s disco music such as “YMCA” and other classics. A dance club is certainly out of place in an art gallery as it is a form of popular entertainment. By contrast, experimental sound design is right at home in a gallery setting. What happens when we combine them?

The dialectical tension between high and low art often achieves explosive results as is the case with the music of John Zorn or the cinema of Tarantino. While the issue is not unique to the postmodern era [William Grant Still’s “Afro-American Symphony” (1930) predates postmodernism by at least 30 years], postmodern philosophy takes a keen interest in the topic. The elitist high art community is a hegemony in need of examination with a very critical eye. Although Still used “blue notes” borrowed from the low art of jazz to great effect more than seventy years ago, this remains a highly controversial technique.

Deconstruction comes into play as we question the binary opposition of high art and low art. The institution of high art obviously defines itself in opposition to low art, while keeping it in a subordinate, inferior position. We are questioning this hierarchical value system as it doesn’t necessarily represent the authoritative position that it would have us believe it represents. Prior to the postmodern era, the ancient standard of quality, as determined by a select group of individuals, maintained a separation that, while effective in filtering commercial and other non-artistic products, also kept certain legitimate art forms from receiving recognition.

Electronic music is one such art form. Though it has roots in the popular dance club traditions of the late 20th century, this says nothing about the artistic validity of contemporary electronic composers working today. With this project, we are showing that although there may be superficial differences between what is commonly accepted as electronic art music and what is widely considered commercial electronic music, they are, in essence, very similar and thus both deserving of artistic recognition and criticism.

The plan for our project breaks down into three sections: music, lighting and sensing.

Music

Steve is composing original music. Some will be in a definite electronic dance music style similar to Techno, IDM (Intelligent Dance Music), and Drum ‘n Bass; some will be of an experimental sound design nature consistent with what is typically considered electronic art music; and finally, some will be a synthesis of these two styles freely combining elements from each.

Steve is using a variety of software tools for this composition including commercial software (Native Instruments Reaktor, Pro-53, and Absynth 4), and Pd. Most of the sound generation will come from Reaktor. Pd will be used to create a custom sampler and effects processor for both the live performance and the automated performance. The Pd patch will tie all the musical elements together and will translate sensor input to control various parameters.

Lighting

Since lighting and music is already an established tradition, we will not explain it further at this time. The lighting design will follow concepts explored by the music with the lighting consisting of a conventional dance club light show; a more experimental, artistic use of light; and an synthesis of the two techniques.

The lighting, as with the music, will be controlled by sensors placed around the performance space.

Sensing

We are exploring the use of light, infrared, and ultrasound sensors. The performance space will be divided into a number of segments and as spectators walk through the space, changes in audio and light will follow. The spectator will not be aware of the effect their presence has on the installation other than the fact that it is changing as their position changes. Sensors will not be continually receiving input and will thus be unpredictable to spectators. For instance, walking to the rear left corner will not always have the same effect.

Spatial sensing is difficult with a high volume of people present and will be more effective with a limited number of spectators present at any given time. Because of this, and because we are interested in live performance, the Final Friday show will be a live performance rather than an automated experience and thus will not use the sensor input. This doesn’t change our message and concept in any way. It is simply a different delivery method. Live performance only might even be preferable, but since the exhibit will remain up for some time, it isn’t practical to have an artist doing constant performances.

Five days until the due date and Team 5 is looking good. Here’s what has been going on.

Muhammad got the car driving around and programmed it for random movement. Instead of using some sort of infra-red “thing” to keep the car within the canvas, it’s programmed to back up automatically if it bumps into something. From what I can tell, Muhammad spent a LOT of time on this. His part works and is essentially done (although he’s got a few improvements).

Kendra and I have been talking about the artist’s statement a lot. She’s got a lot of great ideas and good things to say - it’s been fun to work together. She’s scheduled to fabricate the car’s body as soon as Muhammad is finished with it. This sounds difficult, but apparently, she’s cool with it. Kendra is also providing the canvas and the boundary. We discussed the use of a boundary and decided that we would like to let the artist wander off of the canvas, but since we’re performing in a public space that may not wish to have paint on the floor, we’re keeping it reigned in. It’s purely for practical reasons.

Aaron is doing work with sensors. I’m not sure exactly how that’s coming along. I haven’t seen them working yet, so I don’t know if there are any problems or if they’re in good shape. Aaron was in favor of scaling our original goal of 12-16 sensors back to 6, so that’s what I think we’ll end up with.

Lauren was in charge of researching abstract expressionism and working with Prof. Harrison to get the logochip to interface with Pd. She found some info on wikipedia and a couple other sources and is now recording herself reading them aloud. Kendra and I had a few suggestions, so she may be redoing some of them. We’ll hopefully have them by Thursday night. I ended up taking over the Pd interface because I needed to see it working before I continued with my own work.

I’ve spent hours with Pd creating some odd sounds to accompany our artist. I settled on classic synthesis techniques that were used roughly during the time of abstract expressionism including additive and subtractive synthesis as well as ring modulation. I’m also forgoing the sophisticated sounds common today in favor of the sine, square, and pulse waves used when sound synthesis was in its inchoate stage.

I’m creating an approximation of a square wave using a wave table in Pd. Although it’s possible to create a perfect square wave, analog techniques in the late 50s did not have this option. I’m also using the wave table to generate pulse waves and one other “original” creation. At this point, most values that will change are connected to random number generators, but I hope to replace them with sensor inputs as soon as the sensors are finished.

The other part of my Pd work involves the sampling of Lauren’s voice as she reads statements on abstract expressionism. For this, I’m feeding the samples through a strange comb filter. This consists of four short (less than 1ms) delay lines. The output of each delay line is ring-modulated by an oscillator set at 3000, 1500, 1000, and 500, respectively. This creates a metalic, crunchy sound that I can mix with the pure, unfiltered voice. The filtered output is slightly delayed further to give the voice an ambience. The oscillator values can be changed to produce varying degrees of distortion, but the ratios remain the same regardless of the oscillator value.

The audio samples are not triggered by sensors (because we don’t want to hear the same thing twenty times), but various parameters in the sampler may be controlled by sensor input. I’m also experimenting with reading the sound files to a table and then programming Pd to let me scrub through the audio selecting various starting and stopping points as well as different speeds of playback. I have this working, but I’m not sure that it fits with the project, so I may not include it on this particular piece. The effect is similar to granular synthesis, only on a larger scale, but since this is a recent technique, I can’t really justify its usage.

Things are looking good. I’m excited to see it all come together. I’m also looking forward to what the other teams come up with as well.

My team met again today (March 2nd) to discuss the project status. Muhammad is confident that he’ll have the car moving by Monday - Kendra is going to spend some time getting the canvas ready and fabricating the car’s body - Lauren has researched abstract expressionism and is going to record some vocal samples - Aaron is working with the sensors some more - I’m writing some Pd code and generating a lot of strange sounds. Overall, it looks like we’re in great shape for March 12th (the due date).

Team 5 met for the first time today to discuss plans for the mini project. Our project consists of a motorized toy car that drives around a canvas making marks with mounted paint pens. The canvas is covered by motion sensors in a random configuration set to interface with Pd. The Pd patch monitors the car via the sensors and changes the audio parameters. Meanwhile, infrared sensors control the direction of the car, redirecting it when it reaches the end of the canvas.

Our project is mainly conceptual, looking at the act of painting itself, rather than being concerned with the finished product. I doing so, we’re questioning the role of the human artist in the 21st century. Although the question itself isn’t new, it also doesn’t have an answer and so we are exploring it for ourselves. Where many artists such as Brian Eno develop generative algorithms to create works of art on a computer (see Eno’s “77 Million Paintings” project - link below), we’re doing it mechanically thus replacing the predictability and precision of a computer program with the unpredictability of a moving, mechanical device. Even though Eno’s project likely incorporates random elements, and even though certain aspects of our project are ultimately controlled by a computer, there are still many opportunities of aberrant behavior on the part of the motorized car and various other environmental factors.

We are expecting the result of the automated/automotive painting to have an abstract expressionist quality, thus we are referencing that particular aesthetic in our artistic concept. We are drawing further parallels with abstraction expressionism with the use of audible statements (triggered by Pd) describing certain aspects of abstract expressionism. This also serves to distance the spectator from the subsequent painting and to force them to concentrate on the act of creation.

http://www.apple.com/pro/profiles/eno/

For thing #4 I worked with Tyler and Nick. We did most of the work on my board so that we could get to the programming sooner, but Tyler is planning to finish his board this weekend and Nick already had it done. The soldering was a little too intricate for me, so Tyler helped a lot with that.

During the switch portion of the assignment, we found that port A5 didn’t work for the LED. We changed the program to port A3 and everything worked perfectly. By the end of lab time, we had the potentiometer sending values. We got the speaker wired, but didn’t get it sounding yet. Since Tyler helped do the difficult soldering, I spent my time soldering wires to the switch, potentiometer, and speaker.

Nick and Tyler are getting together on Sunday to finish the assignment. I’ll be communicating via email because I’m flying to California to visit some schools for next year. Check out the links below.

http://crca.ucsd.edu/ - Center for Research in Computing Arts - UCSD
http://www.create.ucsb.edu/ - Center for Research in Electronic Art Technology - UCSB

The Technology: Art and Sound by Design class (and many like it) pose a novel dilemma for the idea of a “work” (i.e. the expressive product of an artist or artists). The goal of the class at hand is a unification of two seemingly unrelated disciplines: science with its positivist empiricism and art in its current state of postmodern incredulity toward the meta-narrative of empirical thought. The dialectical energy of science (hereafter technology) and art has the power to produce an explosion of creativity, if we can find a true synthesis.

We must ultimately classify the course itself as an “art” class because, after all, the end result (or goal) is to produce a work of art that utilizes technology. This is not, however, to suggest that the artist is dominating force, as the engineer, in this unique situation, is called upon to engage in the process of artistic production. Ideally, the artist and engineer contribute equally working together as two artists: one familiar with aesthetics, the other familiar with technology.

The goal is a gestalt—a unified whole, irreducible into an aesthetic portion and a technological portion. The technological component must not intrude on the aesthetic component and the aesthetic component must not resist the introduction of the technological component. The spectator must be unaware of the synthesis and experience the work as a gestalt.

This is well and good in theory, but very difficult in praxis. That is why the two artists with their respective backgrounds must develop a means of communication—a common ground. This will be, I suspect, one of the more difficult aspects of the class, but also one of the more useful. The common ground must be the creative act itself. Both artists and engineers engage in creativity on a daily basis, but for different means where the former creates objects of art while the latter uses the creativity for more practical purposes. These two approaches to creativity can only benefit each other and they are the key to successful interdisciplinary communication.

It will be up to the artist and engineer to find this common ground and to exploit their complimentary skill sets. The potential is nearly limitless.

This week’s project is a program that manipulates five LEDs. It has three sequenced patterns. There are four red LEDs and one Yellow LED in the center. The outer LEDs use different resistors to make the outer LEDs dimmer. Programming was simply a matter of modifying Keith’s code and renaming some stuff. You can find the program below.

zip1.txt

I have this wonderful image in my head. People are learning to play instruments, not for a teacher, not because their mother made them, and not necessarily even for public performance: they’re learning the instruments for themselves. They’re home alone making music for themselves only. There are no teachers, no critics, no others to judge them - just themselves and the music. I can’t take credit for the idea - it came from concert percussionist, publisher, and contemporary music advocate, Sylvia Smith. In an interview, she described how she tries to play a little xylophone everyday because she enjoys it. It’s music that no one hears (other than her husband, Stuart Saunders Smith - one of the most important contemporary composers today). It’s not practicing, there’s no goal, there’s no frustration, only the pleasure of creation.

Why don’t we have more people learning to play instruments for themselves? The closest thing we have are amateur guitarists. You’ll find an average of 1.4 guitars in every college dorm room*. Many of these guitarists have the right idea. You find them all over the place, playing songs that they write for themselves, not for anyone in particular - just for them, or a few close friends. They don’t need to be great and they don’t even need to be “good”. As long as they are happy with the sounds they make, that’s good enough.

Unfortunately, todays society tells us that if we’re going to do something, we’d better be amazing at it, or it’s not worth doing. Maybe we’re to blame. The guitar playing college kid is a stereotype that gets a lot of heat because “they suck”. By what standards do they “suck”? If you’re comparing them to Buckethead or D’jango Reinhardt, yeah - they do suck. But who are they hurting? They aren’t posing as professionals, they aren’t asking you to pay them, and they aren’t really hurting anybody.

With today’s overabundance of available media, there’s a constant flow of entertainment . Thus, there’s no need for us as individuals to create - we just let other people do it for us. After all, they come up with better stuff than we would, right? We’ve lost the sense of personal creation and the joy that comes with it. Muhammad from the TASD class understands this. On his blog he writes, “I simply make some noise, but it’s my noise and I love it.” This is exactly what we need more of. Now, lets see about something other than guitar because, seriously guys . . . :-)

*statistics made up on the spot by me.