It is my thesis that Joyce relied heavily on the use of a Database Aesthetic in creating Finnegans Wake, and in a time before computers or the technical notion of database (1922-1939).

Joyce's use of the Database Aesthetic for Finnegans Wake can be said about both in its final product, the book, but also in its production. "According to the evidence of Joyce's numerous surviving notebooks and manuscript drafts ... the book began inauspiciously enough, as Joyce began jotting down and
compiling, in English, discrete phrases and sketches without fully knowing where they would lead him." [1] It is said the book draws from over a dozen languages, perhaps even upwards of 60 languages, and flows in a dream-like state. It is definitely a non-linear experience reading this book.

Database Aesthetic puts a dichotomy between Database and Narrative--however, I prefer the notion of a spectrum between these two endpoints. In Finnegans Wake the narrative, the story line, is very weak, which I think is why many people are turned off by the book. For me, reading Finnegans Wake is much rather like being bathed in words--really, in their sounds--with my head in a cloud, and every so often an image would appear, or a humorous construct or odd combination of thoughts, sometimes even within a single word. Joyce uses the word 'funferal' to describe the book itself, a funeral or a wake. Modified from its original, 'funeral' (it is about a wake), there's a dramatic shift from the morbid to fun-for-all. Also, fun-feral comes to mind, so there's at least three ways of looking at this single word.

In my project, FinnegansWork, I intend to explore the database quality of this text. At present, I see this manifesting in some sort of web-based project concomitant with some other thoughts of mine regarding processing of literary text in general, including using Google Suggest as a "lens" to attribute popularity rankings to words and phrases.

NOTE: as of (c. May 2008) references to the website don't do very much!

----------
[1] Introduction to Finnegans Wake by James Joyce, John Bishop,
Pub. Penguin Classics, 1999, ISBN 0141181265.

Full entry below the fold:

There weren’t as many people at this performance, but about 15 made the effort to come see “Play�. This was a much more intimate show for my friends and family, as many of them were not able to attend the opening a few weeks earlier. Nearly everyone that visited that afternoon had heard me explain the piece to them at an earlier date, so most people knew what to expect and how to interact with it. Even so, I still was able to see some very interesting experiences and gather feedback from people close to me.

Two of my close friends made the trek down from Bethel University had a very worthwhile experience, some of which is presented in the video below. They were very hesitant at first, but were soon enjoying themselves thoroughly. Much like the 18 month old the performance before, they attempted to keep all the balls moving at all times, and even got in a small dodge ball game for a few minutes. My 80-something grandmother also came by to see the piece, but the whole concept of interactive art was completely foreign to her. I had to provide more direct instructions for her, and I think the experience may have been a little too much for her to grasp. I’m sure she enjoyed it, but probably more for the fact that I made it than any other reason.

There were some interesting parallels that I was able to draw after seeing two separate groups of people come and see “Play�. The viewers that seemed to enjoy themselves the most came in with a group, so that one person could participate. Also, allowing themselves to enjoy the piece was important, as those viewers who approached the piece with a playful attitude had the most fun. Single participants had slight difficulty experiencing the entire scope of the piece, as it was difficult to interact with all four balls at once. Overall, there were a wide variety of interactions from a very diverse group of people over the two showings. It was an extremely valuable experience to show my work publicly, and I hope to again in the future.

Full post below the fold.

People did eventually start to come in, probably 25 to 30 on this evening alone. The crowd was very diverse, which provided a wide range of experiences. The first couple that came in was probably in their late 20s or early 30s, and their experience was unfortunately brief. I gently reminded them that this was interactive art and they were supposed to touch it, but it seemed to do no good. Each person picked up a ball and looked confused for a minute, shook them like a maraca (a motion difficult for the system to detect), quickly got bored and left. I surmised that the audio portion may have been too quiet, so I upped the volume and waited for more viewers to show.

In contrast to the most disappointing experience that night, a 18 month old with a gaggle of about 8 late 20 somethings provided the best of the evening. The parents were a little hesitant to let their child go crazy with the exhibit, but after reassuring them that he couldn’t possibly break something important, he went at it. He kicked the balls around the room, threw them, rolled them around and tossed them to his parents. If one ever stopped moving, he made a beeline to get it going again. He was enjoying himself immensely, and after only a brief period he discovered the connection between the balls and the audio playing in the room. After he made the connection, his interest shifted to include the changes he was making the auditory environment, even occasionally chasing the sound as it moved around the surround sound system. Unfortunately during his enthusiastic interactions with my piece, the wiimotes started to lose connection to my computer and cut his time short. Probably for the best however, as he’d been in there for nearly 10 minutes and his group of chaperones was looking to head on. Even so it was enlightening to see such a young mind approach the piece without any inhibitions, as I hoped more adults would do.

Overall, most viewers on the 4th seemed to enjoy the piece, and thought the execution was very good. A few viewers approached me and commented that they thought it was a ‘very neat idea’ or that it was ‘very fun to play with and explore’. Many viewers were very interested to learn how it all worked, and I wasn’t hesitant to share the details. Overall, I consider it a very successful show. It was my first ever public showing of work, and the wide array of responses that I saw helped me tune and refine what I can realistically expect from viewers and how I could best present my piece. It was a highly educational (and nerve-wracking) experience.

**Video documentation exists in a review of the second performance**

It's long, packed with pictures and video, and serves as the body of my documentation for the piece. It covers changes made from the prototype, improvements, hardware, software, signal pathing, programming and presentation. It's a long read, but worthwhile if you want to know how it all works. Included are links to download the patch and associated files.

Full post below the fold:

The conceptual development and basic presentation for Play was completed at the end of last semester, when I presented a prototype version of the exhibit for the Fall 2007 Interactive Art studio class. Unfortunately it was a very early prototype, as some of the vital components were not delivered in time for the presentation. The software was not very refined as well, eating up all of my processor (and needing more), there were connection issues, and the sound wasn’t very pleasant. All of these issues (and a few more) I would address during construction and programming throughout spring semester.

Presentation:

The first issue I tackled was the actual beach balls themselves. These beach balls are slightly different than the standard ball, as they have a cylindrical central core that is open to the outside air pressure. As the ball inflates and the pressure inside the ball exceeds the ambient atmospheric pressure, anything contained in this central chamber gets gripped tightly and can no longer be removed. The first batch of these special balls that I ordered last semester not only didn’t come in on time for the prototype presentation, the Wii Remotes (wiimotes) wouldn’t fit in the central chamber. The wiimote was too big and the inlet hole was too small on the 12 inch ball. I needed to find these highly specialized in a larger size.

After a solid four weeks of calling shady clubbing and rave outfitters (through whom these balls are typically marketed), I finally found a corporate branding company that had a ball of similar design that was 4 inches larger than anyone else. Considering Branders.com didn’t typically work with individuals – let alone art students – they were highly accommodating to my needs. They cut the minimum order drastically, dropped the per-unit price and expedited shipping to accommodate my needs. Ordering 25 still seemed like overkill, but the ample extras came in handy very often.

The balls were perfect, except in one small detail. The wiimotes and glowsticks I needed to place in the central chamber fit perfectly in these larger, 16 inch balls, but the balls were clear.

The contents were perfectly visible, so I decided to paint the vinyl balls with spray paint and hoped that the light from the glowsticks would still shine through. Just after spring break, I applied a thin layer of white Rust-oleum spray paint for plastic to a test ball and evaluated the diffusive properties of the paint. It went very well, transforming a clear ball into a lightweight glowing sphere.

The paint itself posed problems, however. Uneven coating was readily apparent, as thicker sections of paint were darker than more lightly covered areas. The paint itself took a very long time to dry, and even when completely set the surface of the ball was slightly sticky. While drying, the balls had an unfortunate tendency to stick together, ruining fully 6 balls with paint transfer. A few generous coats of Krylon low odor clear gloss finsher handled the tackiness and paint transfer problems easily; it even imparted a nice sheen to the surface and a comfortable tactile experience.

The glowsticks I used changed from performance to performance. I had a large stock of cheap gowsticks I bought years ago in a Japanese 100 Yen shop (dollar store) in varying colors. While I thought I had enough, testing and a mis-estimation of my remaining supply made it necessary to buy suitable replacements from an American dealer. I attempted to use LED based reusable lightsticks, but fragility and weight posed to big a problem for them to be used.

Electronics and Software:

Interfacing with the hardware was very straightforward; as the hacking community at large is engrossed in pulling all the functionality they can out of the wiimote. I used the same wiimote interface as last semester, OSCulator. The software translates all the sensor data on the wiimote into MIDI control information, which is easy to import and work with inside Max/MSP. There were a few bugs in my configuration that I fixed by changing a few settings, but in the end each accelerometer has its own MIDI channel and is addressed separately by Max. Using OSCulator to do the MIDI ‘heavy lifting’ and handle wiimote connections allowed me to greatly simplify my Max patch and decrease the load on my processor, a big problem I had in the prototype.

OSC Configuration:

I constructed the final Max patch after writing numerous test patches to sandbox various ideas. Though writing these test patches (and referring to my book) I was able to scale input data, process incoming values and translate them to MIDI note data instead of control data, and even select specified values at times variable by a secondary input. What happens is the sensor detecting attitude changes is scaled from its initial 0-127 range to about 60 -85, and the accepted values are limited by the MIDI note definitions of the C major scale. How often the input is sampled is controlled by the sensor detecting roll, who’s data is scaled to 50-300 (representing milliseconds between samples). The completed note data is fed to the mtof object, which relates MIDI note data to frequency information. That data manipulates the base frequency of a standard cycle object that creates the tones that are heard. A volume slider allows direct control of the output from each ball before it hits the ambipan object.

Final Max Patch:

The ambipan object is a Max object that handles panning in a multichannel environment. It was written by engineers at CICM in Paris, and was a godsend. It simplified placing a mono source in a multichannel field, allowing me to alter the sound’s position based upon an external input. Since the object is French and the documentation is in French, it was a real challenge to actually figure out how to handle the inputs and outputs. After sandboxing the object for about a week, I was able to decipher the schemes and parameter data I’d need to feed ambipan first before it would process my sound information correctly. Ambipan required that I define my speakers using a polar coordinate system before it could output mulitchannel sound. After the speaker’s position and relative distance to a central observer is defined, the data from the yaw sensor in the wiimote is scaled and places the sound in the speaker array. An individual instance of ambipan is used for each ball, so that the four sounds can be moved separately from one another. All the outputs from each ambipan instance are fed into the same dac object, outputting sound to the multichannel interface.

Ambipan Sandbox Patch:

In the reprogram of my Max patch, I was able to drastically cut CPU usage and eliminate the sound dropouts and skips that plagued my prototype. I was able to also create a much more harmonious sonic environment, as the input limiting eliminated dissonance and hash tones. There remains some difficulty with wiimote connections, as wiimotes turn themselves off after a period of inactivity. I can’t really fix this because it’s on the wiimote firmware, but I can just make sure the periods of inactivity don’t happen by jostling the balls infrequently. In each performance I did have wiimote dropouts, but they weren’t detrimental to the experience.

The physical hardware for the piece is quite easy to set up, although it is highly specific to W131 due to the need for a multichannel environment. The wiimotes and glowsticks are connected and then embedded into the painted balls, Max begins to process the incoming MIDI data into outgoing digital multichannel sound that’s piped out over firewire. A Mark Of The Unicorn 828mkII unpacks the digital multichannel sound data into four discreet analogue outputs that are mapped to four speakers via the Marantz amplifer: front left, front right, rear left and rear right. Below is a video of me talking through the entire signal path:

Below is a picture of the presentation during each performance. The picture is significantly brighter than the actual presentation space. I provided only a gentle that this was interactive art for those unfamiliar with the concept, and generally stood back while people were engaged.

Closing:

I really enjoyed flushing this project out to nearly my full original vision for it. The only thing that’s missing is proximity sensing via capacitance, but that would have been nearly impossible using the materials I chose. While the piece isn’t necessarily as emotive as my previous work, the interaction method is cloaked behind natural interactions with familiar objects like other projects. I like working with disguised interactive methods because the familiarity of the objects involved gently cue the viewer’s interaction with the piece. I don’t have to make the interactive method obvious with switches, buttons or directions; I just let people naturally explore the piece. For “Play�, there was a small barrier for some people, as ‘playing’ isn’t really a daily habit of most adults. Usually a small comment about how you’re ‘supposed to touch it’ got most adults involved, but some were still self-conscious and confused. A small number of people missed the connection between their interactions and the sonic environment, but thankfully there were not many. I built the balls to be quite rugged so they could withstand some vigorous play, but the only attendee that really tested their limits was a 3 year old during performance 1. Unfortunately it seems that some adults have forgotten how to “Play�.

Downloads:
Max Patch - Download file
OSC Routing Config - Download file
Ambipan Sandbox Patch - Download file

Briefly: it's a little old and the information is very dated. Was missing discussion of important Max/MSP capabilities that would have been helpful for my project. The book wasn't completely unhelpful, just not as helpful as I would've liked.

Full write-up below the fold:

This book was first published in 1998, but my edition is from the 2001 paperback issue, and the information was really showing its age. Since the book was written so long ago, some of the functionalities that now exist in Max are not discussed, specifically in the realm of signal processing and generation. While not expressly necessary for my project, understanding signal processing in Max/MSP would have allowed me to significantly enrich my project in the areas of tone generation and effects processing. The book seemed specifically interested in processing MIDI data generated by a standard keyboard controller, but hinted at how alternative input devices could also be utilized. These hints were quite helpful.

The book wasn’t a total bust, however. Since basic MIDI processing inside of Max/MSP hasn’t really changed much in the last few years (and the MIDI protocol has also remained unchanged), so the sections on midi handling, translating and implementation were quite helpful. Basic programming practices and processing syntax was also covered in great depth, making structuring my program efficiently a lot easier to accomplish, This was specifically helpful, as in my initial prototype I struggled with processor over-utilization and memory leaks that occasionally let to crashes. In the rewrite, I was able to reduce processor utilization by nearly tenfold and eliminate memory leaks to create a much more stable and higher performing patch.

The book also contained conceptual development sections, discussing interaction methods, performance theory and basic approaches to computer composition. Since I had my interaction method designed and my output defined before I read the book, reading these sections wasn’t directly applicable to my project but it was enlightening for my understanding of interactive music composition in general.

Overall, the book was a solid read and provided great Max/MSP programming fundamentals. I was hoping it would provide more specific advice, but the book is nearly 10 years old. Maybe the interactive art and music community can convince Todd Winkler to write an update covering the upcoming Max/MSP 5 and fill in some information about signal processing. I know I’d appreciate it.

View "the (re)beginnings" brainstorm post >

My original vision was a piece which I began to call The Wind, which can be summarized like this: waves of grass as if blowing in the wind, in reaction to the presence of a Bluetooth wireless signal. This of course is the project I started to implement last semester.

So it is in this larger context (creating more of these pieces of technologies to make this vision happen) that I want to embark on a project which will focus on Bluetooth Triangulation. But this is only the sensing piece of what would be a larger work, so I will be thinking also about how to employ this bit of technology into something a little bit more fun, yet simple - since my focus would be to figure out how to further along this type of technology. I have a handful of (research) papers about Bluetooth regarding signal strength, triangulation, etc., which I hope to post somewhere, here perhaps, but I need to ask if there are any legal ramifications of doing so. Diane?

Any collaboration would be most welcome.

I have also researched several Bluetooth devices, the WT11 included (the device on the Arduino BT) and not all Bluetooth devices make it easy to get at the signal strength (ie, the RSSI command). The WT11 does, however I find working with the Arduino BT's WT11 very difficult because the bluetooth signal doubles at the sole serial line in and out of the board - so it's got to keep on running in order to reprogram the board. Meaning, if you're tweaking the Bluetooth device, you're changing your (only) means of communications with the board. I have read on forums and such about others' opinion on this design, the extreme position taken states this is a design flaw in the Arduino BT, and I tend to agree. If there were an alternate serial way in/out of this board, keeping the Bluetooth part of it for experimentation, then that would be perfect. However, this does not seem possible to do.

There is something called the two-wire interface which looks like a possible way in/out of the board like a serial line, however, it does not appear you can reprogram the board with this method--at least not without some significant changes in its bootloader software. Since I'm trying to focus on the problem of triangulation, I am reluctant to attempt anything like this (yet).

Ideally, I think, I would like to find an RSSI-capable Bluetooth device, such as the WT11 which I could connect to whatever board/computer I might need to accomplish this semester's goal. This could be an Arduino NG/Diecimilla or something else. I am still researching this, but I will need to obtain some solid equipment soon if I'm to make any progress on these plans this semester.