Cycle 3
Posted: May 7, 2026 Filed under: Uncategorized Leave a comment »Resources
- Motion Lab
- ACCAD space
- Wireless audio system
- Guitars, pedals
- Drums
- Orbbec Femto Depth sensor
- RGB Camera
- MacBook Pro (M1)
- Mac Studio (M4)
- PC
- MoLa Network
- NDI
- Cue-able lighting system
- Portable lights
- Circular rug
- Wall-Mounted TV
- TouchDesigner
- MediaPipe & OpenPose
- StreamDiffusion Operator
- GeoZone operator
- iPhone
- Amazon Echo Tap
- Past ACCAD Projects
- Performance recording from castle project
- Interactive fluid simulation
- Interactive particle system
- Mediapipe control system
- Audio responsive coloration
- Shared memories of impactful moments from prior projects this semester
Themes
- Undermining Expectations
- Intentional Performance with Interactive Systems
- Instability
- Surprise
- Disorientation
- Immersion
- Uncertainty
- Friendship
- Challenge
- Hubris
Value Groundings
For this project I wanted to showcase my abilities and pay homage to the journey that brought me here. I saw this as a sort of culmination of an era of my life that has been both exciting and enriching. In each cycle, I integrated elements and systems that I had built for previous classes with new elements that I learned to implement in the current semester. Cycle 3 was envisioned to be a choreographed performance to demonstrate what a practiced and intentional performer could do with the system.
In addition to showcasing my current skillset, I wanted to feature some of the elements that I have loved about my time at ACCAD. The friendships and camaraderie developed with classmates, the supportive environment that artfully enables vulnerability, and the creative confidence cultivated in every class that encourages and enables ambitious pursuits without judgement.
Undermining Expectations
This theme ran through the entirety of the performance from the pre-show through the show as envisioned.
I have typically tried to build systems for other people to interact with. For Cycle 3, I chose to build a system that would allow me to perform for a more passive audience.
I have typically (not always) steered clear of negative emotional valence, opting for friendly and approachable experiences with some emotional dynamics, but almost always ending on a positive note. The score for this cycle featured many abrupt oscillations between positive and negative emotional cues.
I have typically strived to make digestible experiences with a central focal point separate from the audience intended to provide a “wow factor”. I devised this experience to wrap the audience inside the experience with progressively disclosed wow factors.
I have typically tried to implement experiences with clear beginnings, middles, and endings. The experience as devised for cycle 3 had several false stops to keep the audience on the proverbial balls of their feet. For this cycle I didn’t want audience members to feel completely comfortable at any point. I wanted emotional highs and lows. I wanted a little bit of vigilance.
I like surprise. I needed Michael for this project for a number of reasons including as a co-performer in the original score (he could have nailed it, but I wasn’t comfortable with my own performance on the canceled second song). Even knowing that I could not achieve everything I wanted to do without him, I still tried to find ways to keep certain advancements hidden from him so that he could experience a bit of surprise as well. My main goals for the cycle were to introduce points of intrigue, to increase the polish, and to build an experience bigger and more immersive than I have in the past.
I made a major mistake in my score. Early in cycle 3, I considered that audience members would likely assume that this was an audience participation experience. I had initially considered using the Orbbec depth sensor to track movement into the stage space and trigger an audio rebuke and instruct the audience to find a seat and relax. I couldn’t immediately devise a way to trigger this response only when I was out of the room. In retrospect there were several easy ways to achieve this. The easiest way would have been to trigger a voice over immediately upon entry to instruct audience members on how to engage with the experience. This would help to avoid unintentional disclosure of the experience.
Another simple method would be to hide a switch near the entrance to the motion lab that I could trigger on entry to deactivate the security mode. This would be easily achieved using a makey – makey with some conductive tape
The importance of framing cannot be overstated. Especially if you are planning an experience that is going to undermine what people have been conditioned to expect. I tried to do a lot of fancy framing when clear and simple framing would have been a better approach.
Score
The initial score was as follows:
- Audience waits in the holding area listening to muzak while the performance is set up.
- I leave the motion lab through the supply closet while the muzak stops abruptly and the emotional valence of the experience shifts from light to dark as they are instructed to enter.
- The audience enters the motion lab to find the system in a dormant state with designed lighting.
- I enter the waiting room, set up the backing light, and begin playing the song before entering the motion lab
- I enter the motion lab and walk slowly to the robo camera while continuing the song. I use the robo cam to interact with my audio responsive fluid simulation (powered by media pipe) to paint a base on the front screen.
- I would proceed to the center of the rug and perform the song.
- At specific moments during the song where no lyrics were sung, I would step away from the microphone into a zone on the rug, which would trigger a specific prompt weight on the StreamDiffusion operator to rise to 1 and fall to 0 over 10 seconds. I would then step several feet directly behind the microphone, which would cause TouchDesigner to fade between feeds, so the stream diffusion model would fade in behind the point cloud and slowly fade back.
- All lights in the room would shift from the initial cool color setting to bright red over the course of four minutes. Gradually shifting the light shining on the performer’s face from soft blue to dark red.
- If at any point in the song I forgot the lyrics (which happened several times in practice, I would have a cheat sheet projected on the wall TV.
- At the end of the song the lights would fade to black and I would recede from the microphone with only feedback playing over the speakers, lay the guitar down on the table in front of the screen, and wiggle my fingers around the glass globe placed at the center of the table.
- When a motion sensor detected the movement in my fingers, an energy animation would appear using a Pepper’s Ghost effect inside the orb, the screen would flash and I would fall to the floor.
- At the drum set on the opposite side of the room, Michael would begin playing a drum solo with each pad linked to a specific portable light, shifting attention from the right side of the screen to the left side.
- During this performance I would be hidden behind the table changing costumes and emerge with a different instrument to join Michael in a final song, David Bowie’s “I’m Afraid of Americans”. The lights would reactivate with a red, white, and blue theme.
- Stepping into a previously avoided zone would provide a new set of prompts to the AI that are relevant to each verse of the second song. The motion-based same weight adjustments would allow me to shift between each prompt.
- This song would end and the lights would fade to black.
Simplifications
Full disclosure: it would have been better to have simplified this experience more. With a simpler media system I would have had a more predictable performance. At the same time, even more than a flawless performance I valued this final challenge and an honest assessment of the edge of my abilities as a benchmark. I took risks, I suffered consequences, I have no regrets — though I do have lessons learned.
Truncating the show
While I built most of the system to execute the complete score, it became evident that I was not prepared to actually perform the song. While I was not great at the first song, the second was comparatively worse, and I did not want to deliver an unbalanced experience ending on a sour note. I chose to cut the second song. As the Pepper’s ghost transition was intended to have “transformed” the performer character, it no longer served any narrative purpose and became a cheap party trick that was irrelevant to any coherent narrative.
Changing the onboarding experience
Being slow to devise an approach to a verbal warning system to prevent audience members from interacting with the system and uncovering the surprise enhancements from Cycle 2, I elected to simplify the system by introducing a new entry experience. I decided to add a new switch operator with a trigger that would allow me to hide the actual experience until a moment that I specified.
This was wishful thinking and did not serve its primary purpose. The audience’s prior knowledge and experience had strongly reinforced the idea that this would be an interactive audience experience. Luke’s performance also featured a microphone as a mode of interaction, establishing it as a system component that was “in-play”. After starting the song on the guitar I heard audience members speaking or singing the lyrics into the microphone.
Where I probably should have simplified, but chose not to
Some of the elements of complexity were required to achieve the vision. The experience employed three networked computers trading data. This is a big vulnerability that did bite me in the end, but it was necessary if I wanted to have the AI generated content and transitions. I could have potentially eliminated by personal laptop from the experience and run everything on two machines, but I wanted to keep the patch that required the most work on my personal laptop so that I could work remotely and make updates in the motion lab without needing to transfer the files back and forth.
I am not confident that I could have reduced to only the PC to run all components and chose to leave it dedicated to the AI model given its intense processing demands.
This complexity presented a major fault during the performance. On the day of the final I had accidentally opened two versions of my project, which doubled the NDI out feeds and caused the network to dynamically rename my computer. When I set up the AI computer prior to the performance, it did not recognize my NDI feeds as they were coming from a new source. I reconnected the feeds, but made a mistake in feeding the source image into the AI model.
I learned during cycle 3 that feeding the Front Screen NDI into the AI model caused a feedback loop that ruined the content and caused the model to reach a state of stability with striped colors. I resolved this problem by creating a separate feed named fluidsim-precomp (bad choice). I only discovered this mistake while cleaning up in the motion lab after the performance. I should have given the NDI output a name corresponding to its purpose, not its content, and added a comment to my network to remind what feeds are expected.
Lessons Learned
I had practiced this performance extensively in the motion lab and at home. I practiced under pristine conditions and had not practiced playing through unanticipated variables. While I set up the experience and drilled the performance enough that I could execute it with minimal active thought, the unanticipated initial conditions forced me to adapt my performance and it took longer to settle in and get back out of my head. I was fixated on making sure everything was reset to the baseline state while trying to continue the show. In the process I missed several cues (e.g. entry, delay pedal timing) and failed to notice several important factors (e.g. lowered microphone lowered, guitar fx pedals set incorrectly) that caused distractions for me early in the show.
I have to work on simplification. I love a challenge. I love devising big, elaborate experiences. I love to stretch the boundaries of what I know how to do. Sometimes it’s worth adding complexity to a system when the risk is justified by the extended capabilities, but there is a penalty to pay. By nature I’m a shy person, but designing experiences allows me an outlet to be bold. I like to take risks. I think it’s okay to do things like this when it’s for my own benefit, but when devising experiences for others (especially where clients are involved) simplification is non-negotiable. I should strive to re-frame simplification as the challenge to exercise that muscle.
I also learned how much I prefer to build experiences for others rather than perform for others. It’s a much more gratifying experience for me as a creator to watch other people play and discover even if the work is less polished. Even if I’m panicked during an experience that others are interacting with it’s not necessarily evident to the participants. I don’t particularly like being
Special thank you to Alex, Michael, Lou, Rufus, Zarmeen, and Luke for everything this semester, it was a great joy to work with all of you.
Final Practice before new elements introduced
The GeoZone based prompt switching and updated floor visuals were not yet implemented during this rehearsal.
Final Performance
Note* I have cut this video down to remove the initial audience and performer entry to protect the identities of the classmates who did exactly what I had conditioned them to expect through previous cycles and began interacting with the set. They did nothing wrong, I simply didn’t provide the necessary framing to contextualize the performance and I fear that sharing that portion of the video publicly might cause undue embarrassment. I have deep respect for the entire cohort loved working with each member.
Cycle 2
Posted: May 7, 2026 Filed under: Uncategorized Leave a comment »Themes
- Chaos
- Collaboration
- Cowardice
Resources
- TouchDesigner
- MacBook Pro (M1)
- Mac Studio
- PC
- MoLab Network
- StreamDiffusion Operator
- Guitar
- Drums
- Sticks
- Cameras
- Orbbec Femto
I made several improvements to the system between Cycles 1 and 2. I first increased the size of the Orbbec feed to give it more prominence on the front screen. I also solved the issue with the fluid system failing to change colors in response to the audio.
I also added new components, primarily a StreamDiffusion model, which required an extra PC to be carted in.
My original idea for cycle 2 was to do a live performance. In the weeks leading up to it, it became clear that I was too far out of practice to give a decent performance. I practiced a bit and tried to get back up to speed. While I hadn’t played in a year or two, I was playing pretty consistently for decades prior to that. Even when I would take an extended break from music I can generally get back up to speed pretty quickly… Of course I’m never actually doing this against a deadline and time is a flat circle, so who knows how long it actually takes. So I brought in the instruments.
I was especially interested in what I might be able to accomplish with the electronic drums, since they are capable of sending midi signals out to a computer.
Score
The score for Cycle 2 was all out on the floor. A guitar here, a drum set there… sticks in the middle to let you drum on anything you wanted (please not the bare floor, Michael would never forgive me). The framing was completely permissive – Do whatever you want. Go Play. All stations were open for business. The AI PC sat conspicuously on the floor, but did not get much attention aside from Alex, who knows how to work the system. The interface was intimidating and I suspect that nobody wanted to mess anything up.
I decided to abandon all hopes of doing a performance in cycle 2. I didn’t expect it would go particularly well given my current state of play (I’m not a great musical performer on my best days), and I like to do slow reveals. If I rushed forward with a lackluster performance, it would really take the wind out of my Cycle 3. Instead I thought we’d do a jam along. A sort of musical playground (that would come back to haunt me). David Bowie playing in the background with corresponding visuals to showcase the new AI component. I hoped to derive value from this in several ways.
Valuation
Cycle 2 was chaotic, more chaotic than any other immersive media project I’ve done. It was not beautiful. It didn’t sound good. But it was fun. The energy was high and the excitement was palpable.
Performance
The system drew comparisons to petting zoos, sensory rooms, musical playgrounds, exploratoriums, and mothers who want a moment of peace. People were curious to learn what everything did and how you could.
It made me more comfortable with the prospect of a performance for Cycle 3. But it also reinforced expectations that would make Cycle 3 more difficult to execute the way I had envisioned it.
I missed a core piece of feedback from Cycle 2 – “The placement of the drumsticks in the center of the rug made it feel like I have to do something with these”
Kaiju Hero K.O.! – Cycle 3
Posted: May 7, 2026 Filed under: Uncategorized Leave a comment »
Armed with valuable feedback from my cohorts and mentors, I decided it was time to level up the gameplay experience this time around, and that would involve puppets – battle puppets, to be precise. I wanted to free the players from poking static cut-outs and provide space for mobility. I also wanted to freshen up the visuals, including adding a retro gamer cityscape for the projected stats. The bar graph I decided needed to go down, not up, showing a decrease in vitality as hit points accrued.
The puppets were wired to the Makey Makey with zones of aluminum either glued or taped on the figure, specifically foam core pieces (handcrafted to fit over the body and support the wires). For the bulk of the body I used my balloon twisting skills. I really felt it was important to incorporate an inflatable element (especially since the kaiju suit/puppet will be made of inflatable materials for the thesis). Furthermore, the balloons were easier to repair/replace.
Much testing of different designs went into the process of bulding each puppet, the balloon designs needed to be styled for easier maintenance, so I refrained from excessive details or complexity. For the heads of the hero and kaiju I knew they would be taking a good amount of punishment during each round, so I employed a balloon art technique called “deforming” – inserting a balloon inside of another balloon – which insulated key balloon components with two to four layers of latex. Wiring the aluminum zones into the kaiju claws, hero sword, and hit zones took some considerable time but once in place proved reliable for dynamic contact.
Available resources were not only physical materials/equipment but also expertise from within the cohort of students. One such classmate, Chad (an avid Touchdesigner fan), assisted in my patch for the background music to speed up after one of the bars reached halfway down (ten of the twenty hit points). More logic components were involved. I also was able to add a boom noise when the kaiju got K.O.ed (I couldn’t figure out how to apply it to both in time, so I kept things as is for this cycle). Considerable noodling ensued as Chad prepared specific component/settings for me to integrate into the patch. Such is the way of Touchdesigner, a series of tweaks and threads in the process, oftentimes retracing steps to work out better solutions/outcomes.
Other items from the wish list couldn’t fit into the experience, such as additional onomatopoeia appearing on the projection in connection to specific sound effects. Though it would have been cool to include, the most essential elements of the game play required my full attention. Additional connecting wires were added to the puppets to facilitate mobility across the tabletop. Much of the look of this setup screamed “prototype in progress” – making things pretty and polished would have come later, first we needed to ensure this jerry-rigged operation would consistently work each round. I made fresh balloon bodies for both characters the morning of the presentation of Cycle 3 to afford all the balloons’ stamina possible for the battles ahead.
It didn’t take long before one of the kaiju’s biceps popped mid-fight, but that did little to deter the players from gouging, swatting and striking each other through their puppet proxy. All those hours of fabrication and prep work paid off within five minutes of intense game play, delight and laughter. The feedback afterwards poured in during circle time, along with more ideas for subsequent cycles. The puppetry combined with the colorful balloons added to the playful nature of the gaming experience for players who felt sufficient safe distance from the action. The group also observed how each character had their own respective advantages to exploit; the offset of hit zones and size forced the players to employ more strategy during the battle round. Alex observed that this cycle wasn’t far off from becoming a polished product to offer audiences, I agree this could be a great spin-off, mini version of the immersive experience. The projected media was largely ignored by the players engrossed in the ring but served more enjoyment for the surrounding audience. What did cue the players during game play was the sped-up music as one or both fighters racked up 50%+ damage. Suggestions included providing some way for the players to see their health bar diminish during play, perhaps adding pixel strips on the back of each puppet that corresponded with Touchdesigner’s data. All in all, this cycle provided valuable insight towards the next iterations of Kaiju Hero K.O.! which could very well diverge into other applications for different audiences/age groups. One big takeaway was to explore more potential with puppetry and perhaps other materials. One element I was not able to fit into this cycle was the use of piezo sensors/transmitters, introduced to me by Alex in between Cycles 2 and 3; hopefully I will implement those for Cycle 4. Wires did prove reliable for transmitting signals, though I wonder as we scale the size how that may change.
And here are some additional clips taken with my super fancy phone, just for fun…
Kaiju Hero K.O.! – Cycle 2
Posted: May 7, 2026 Filed under: Uncategorized Leave a comment »
One of my main aims for this latest version of the score was to incorporate desired sound effects and audio clips to enhance the experience with my rudimentary setup from Cycle 1. I received assistance from Michael on the necessary components for not only playing the sound but also at specific times. I also wanted to update the “boop” sound of contact by swapping it out with combat-esque sound effects. Using the keyboard from Garage Band on my iPad I chopsticked up a composition for the background music. It became more and more clear this needed to have the feel of a video game, so I kept certain motifs in mind as I prepared my media files. Logic components were added to cue audio clips announcing the victory of the hero or kaiju characters once one of the bars reached all the way up to its threshold. Unfortunately I had yet to devise a way for the game to reset automatically (I had to assign the “R” key to manually tap before another round wiped the slate clean), and there were other visual cues I wanted to add to correspond with the audio (ie: “VICTORY”, “KO!”, etc.). I kept the same figurines, because the focus on this cycle was more on honing in on the audio element of this experience. Updating the sounds and adding background music seemed to help the testers to feel more of the video game vibe, even though the rest of the setup had remained unchanged from Cycle 1, participants noted a significant improvement to the overall experience. I noticed a more competitive nature emerge from the players in response to the updated combat sounds and victory announcements, certainly a good sign we were heading in the right direction.
This experience needed, above all else, a fun gaming interphase, but safety also came up as an important factor. My original idea for the thesis concept involved LARP (Live Action Role Play) foam armor and weapons – equipped with sensors – for the hero while an operator donned an inflatable suit (with sensors sewn into the ripstop fabric) for the kaiju. Alex and others voiced this could present various complications to implement safely, the risk may outweigh the payoff. Talks of perhaps making the kaiju more like an inflatable puppet that could be operated from a safe distance offered interesting potential I really hadn’t considered seriously before, but the more I pondered over it, the more appealing a puppeteering operation became.
Other great suggestions from the class provided valuable insights into what piqued their interest. One suggestion included to pit the characters with their respective players from across the table rather than side by side. Another was to involve some kind of shield/blocking feature to enhance combat strategy. The endearing background music also could potentially intensify the experience if it sped up over the course of the battle round.
Kaiju Hero K.O.! – Cycle 1…
Posted: May 7, 2026 Filed under: Uncategorized Leave a comment »
This cycle and its subsequent iterations stem from my concept for my thesis. Unlike my fellow theatre MFAs, my thesis will not be a design for one of the staged productions. As an MFA in Media Design I would’ve arranged the projections and other media for a show; however, with the approval of my advisor Alex and the department I’ve got a very different concept in mind: an immersive experience built from the ground up. Working title is Kaiju Hero K.O.! with a simple premise: save the city from a raging monster. When I had first pitched the idea of an immersive experience for my thesis to Alex (months before I officially started my program) – Alex encouraged me to “simplify to achieve balance,” and subsequently the original idea evolved into something that I feel would still be ambitious – but also more manageable with the resources and time available. This DEMS class offered a perfect opportunity to better understand those resources, draft up a basic score, then apply it under the scrutiny of valuaction. More elaborate means would be utilized in subsequent cycles, each one with specific questions to answer which would culminate into a body of research to inform my actual thesis, slated for fall 2028.
Encouraged by mentors Alex Oliszewski and Michael Hesmond to start small, I decided to focus on devising an interphase that responded to physical contact in a very noticeable way. I determined to create two rudimentary stand-ins for the main characters, the Kaiju and the Hero, which would be engineered to receive focused, physical contact and translate the input of that interaction into some sort of audiovisual format.
Resources offered included the Makey Makey circuit board, with alligator wires. I found some aluminum foil and collected materials for building a mock-up of the kaiju and hero, respectively. The Touchdesigner node-based software seemed to offer potential for receiving and interpreting the Makey Makey’s input. As an expert in Touchdesigner, Michael’s guidance proved invaluable as I started to wrap my head around the various components and how they worked to curate an interactive experience. I settled on repurposed milk carton plastic for the figurine stand-ins, carving out zones inside each silhouette to allow contact with the layer of aluminum foil underneath. A cardboard backing proved necessary for stability and durability for the demo.
Connecting the figures with the alligator wires seemed straightforward enough, specific keys designated to “boop” when the respective zone was touched, once Michael showed me how to assign keys from the Makey Makey into the proper component in Touchdesigner. I also wanted to show the result of that contact as a bar graph, one bar for the Hero alongside one for the Kaiju, counting up with each contact on their foil zones. This, like many things in Touchdesigner, was easier said than done. By and by, thanks to help from mentors and a healthy stack of tutorials, I was ready to showcase this first version of Kaiju Hero K.O.! to the world of our tiny but mighty class.
I struggled to get the audio clips I prerecorded integrated into the patch, so I picked my battles and tabled that item from my wish list to be addressed in a following cycle. We (and by “we” I mean Michael and I…OK, mostly Michael) managed a solid “BOOP” sound for any successful contact with the figuring and the wired, aluminum swords I molded. One of the takeaways was learning how to communicate with the robust nature of Touchdesigner, along with keeping my focus narrow enough to fulfill successful milestones within a given timeframe.
Cycle 1
Posted: May 7, 2026 Filed under: Uncategorized Leave a comment »Themes
- Exploration
- Resource exploitation
- Free play
Resources
- TouchDesigner
- MacBook Pro (M1)
- Mac Studio
- Motion lab
- Circular rug
- Orbbec femto
- Robo cam
- MediaPipe
Score
Audience members walk into the space to see a white rug with a psychedelic animation.
Stepping onto the rug alters variables on the noise CHOPs. There are 8 zones that change the values of different parameters.
When a participant steps onto the rug, they are captured by the depth sensor. A point cloud generated from this feed runs through a composite TOP set to ‘over’ blend mode. The point cloud is composited with the motion-tracking fluid simulation and projected onto the front screen. The point cloud spins around the y-axis using an ‘absTime.seconds’ expression.
Valuation
For Cycle 1 my goal was to incorporate some new elements from the motion lab that I had never previously used with some reclaimed elements from prior projects and see how people engaged with it.
Performance
While waiting for people to return from the bio-break before my performance, Michael asked if he could play some Pink Floyd. I agreed and as the music began to swell I realized how much of a void the silence would leave when we cut the music. I tried to signal to Michael that I wanted to him to keep it rolling. The soundtrack made the experience feel much more full and ethereal.
The entire experience was heavily improvised, and I attempted to demonstrate the system affordances silently by modeling the interactions. I was also able to manually manipulate the patch to make synchronized transitions between songs on the fly. I actually really enjoyed this aspect though it was not planned from the beginning. This was a seed that I would nurture in future iterations.
The interaction with the rug was not obvious. Mainly because I was using spatial positioning to change random parameters in the noise on a video heavily driven by noise. The changes were too subtle and disconnected from the precipitating action to feel meaningful or intentional. However, there’s something to be said for that. It’s not necessarily something that I would do again, but it was just noticeable enough that people spent time trying to figure out exactly what was happening and whether they had any impact on it.
I failed to account for the low light when incorporating the MediaPipe-based fluid simulation. During the performance I tried to use several lights to illuminate my hands for the camera. I was able to get some outputs, and enough to intrigue participants and encourage them to attempt to replicate the behavior.
I also failed to account for MediaPipe’s default tracking behavior. The first target the operator locks onto has their hands labeled h1 and h2, and the party uses these to draw the fluid onto the screen. This made it frustrating because it was impossible to determine who was in control of the fluid simulation at any given time.
Overall the reception of this cycle was positive. People enjoyed trying to figure out what was responsive and how the controls operated.
The rotating particle clouds were also well received, though went unnoticed for most of the performance. With people in the room and amidst all the commotion, it became obvious that they were far too small, which was an easy fix.
These were good lessons that I could incorporate into future builds.
Pressure Project 3
Posted: May 7, 2026 Filed under: Uncategorized Leave a comment »Storytelling through sound
Themes
- Decisions
- False Dichotomies
- Search for meaning
- Pretense
I wanted to explore the idea that we spend a tremendous amount of time seeking meaning out in the world, when what matters most often happens closest to home. This value in combination with the shared context of the assignment provided the initial framework for the experience. With this in place I worked out my score fairly quickly. The experience would present two options where audience members could try to pick apart the meaning of the story being told (which would be devoid of any direct meaning).
My experience began in the ACCAD Hallway. My introduction to the experience was tightly scripted and carefully crafted to avoid any explicit imperative instructions:
“Welcome home. You may choose to go through the door to the motion lab. You may choose to go through the door to the classroom. Each space contains a different experience.”
During the performance, one classmate asked if they could go between rooms. I hadn’t anticipated this question, which was a fairly obvious one in hindsight. I replied that they were free to make their own decisions.
Each room had a non-sensical musical composition that I had created. I like to run through a process with music where I start with a dumb idea and pour effort into it. Aside from being a fun exercise, it allows me to compose music without the stress of trying to make meaning. I developed this practice after becoming disenchanted with trying to make meaningful music or music with a message. I make music for fun, but I would cringe years later when I’d listen to a younger iteration of myself trying to be profound or expressive or whatever it was that I was trying to accomplish. The author had died and I was making up my own meaning when listening to it anyway, so I reasoned that this approach was just as good as any other I was trying out. And oddly – because my effort shifted to the construction and away from being self-conscious or self-involved, I enjoyed listening to the songs more. How could I not, when it gave us such tracks as the pandemic era Appletini with my Homeboys? (I actually would have preferred to use this song over the second song below, but there is an actual story to be derived from it, and I wanted to use tracks that were completely devoid of meaning to capture the spirit of this project).
Fue is a song that I recorded on my iPhone years ago as a joke for a close friend I met years ago in a college French Class. The lyrics are:
Du beur, du beur
Le voyaguer
Du beur, du beur
Le voyaguer
Du beur, du beur
Ma petite ami
Du beur, du beur
Avec moi aujourd’hui
(X2)
Du bœuf
Du bœuf
Du bœuf
Vous ne voulez pas ce bœuf
Which translates more or less (with what is probably very poor grammar, I’m not that good at French)
Some butter, some butter
The voyager
Some butter, some butter
The voyager
Some butter, some butter
My girlfriend
Some butter, some butter
With me today
(X2)
Some beef
Some beef
Some beef
You don’t want this beef (formal pronoun)
It’s stupid. I love it.
Here, listen.
The second song was called Pareidolia (A Confession 4/4). It was originally constructed using vocal samples in 2021. I spent several hours editing this one for Pressure Project 3 just to change the song’s structure a bit. There’s nothing particularly interesting in this song. When I made it I was trying to evoke the idea of someone trying really hard to make something overly artistic, deep, and meaningful (basically taking a jab at myself as a teenager). It’s not a particularly good listen.
The main point of this story is that while you’re out trying to milk meaning from the world you’re missing the real story. As soon as I had given the instructions I began to pull up a video of my daughter and I doing bedtime stories. It was important to me that I didn’t “cheat” and wait for people to leave before pulling it up. If someone had stuck around long enough they might have heard the sound and stuck around.
During the reflection period I refused to replay the story time file because that’s the point – you missed it. Nobody in the class actually heard the story, however several people walking through the halls did. This actually made me more uncomfortable than expected. I had considered the high probability that people without the context of the class would walk by during the performance and saw this as a major plus… as reinforcing the point that I was trying to make. While you are missing the story other people to whom the story means nothing are likely catching glimpses. While I had anticipated this and liked the prospect in theory, the actual experience of letting this play out while other students walked by was intensely uncomfortable for me. I don’t like to let my phone play audio where others can hear it and potentially be disturbed by it. I had made a commitment to let the story run for its full length without interruption.
I also recognized during the reflection discussion that while the idea behind this project was to kind of deride my own self-indulgent and pretentious pursuits over more meaningful even if more mundane experiences, this conceit itself was very self-indulgent and pretentious. It also felt a little preachy. I did not like the experience of denying people the opportunity to listen to the bedtime story (opportunity feels like a strong word here), but it felt conceptually important for the point I was attempting to make.
For the first time I will reveal that the story in question was in fact The Little Engine that Could, for what it’s worth.
Pressure Project 2
Posted: May 7, 2026 Filed under: Uncategorized Leave a comment »The Networked patch: Everything is Cher
- TouchDesigner
- Cher Believe Midi File
- Dial CRT TV image
- Network
I wanted to play with nostalgia for this project. I chose to use a retro television as the backdrop for my patch. The TOP in would take a video feed and apply a noise overlay and a lens distort to apply it to the CRT screen.
I also created a switch to change channels, selecting from NDI-in TOPs.
The audio portion would take any audio NDI input and play it through a Logic Pro file that would use the audio as a carrier channel for a vocoder to reshape every sound to match pitch with Cher’s Believe.
Finally for my control portion, The OSC-In feed would run through a rename CHOP and a reorder chop to switch between several filters applied to the video content and change the channel on the TV.
On the output NDI I provided the a video of the patch running and the processed audio (i.e. the audio-in feed being shared having been Cher’d). I also provided the current TV Channel parameter as a number between 0 and 5 over OSC-out.
I used the IN CHOPs and TOPs in my patch with default values to ensure that the patch ran on its own and interacted with others.
I tried to include things that reminded me of my youth. Things that I haven’t heard or seen in years, but when I did they took me right back to a nostalgic past. I didn’t get too crazy with complexity, and tried to keep it simple, self-contained, and cohesive.
In my initial imagining of this project, external users would be able to feed their content through my patch and see their content displayed on the screen, but that’s not the way it worked. They could take my screen with whatever content it was playing and incorporate it into their own patches. Likewise they could incorporate whatever audio I was taking in and hear how it sounded as Cher’s Believe.
There were a number of interesting and unexpected interactions. I especially liked the way that the effects stacked. In preparation for this pressure project, I was mainly considering how two patches might interact, but I didn’t consider what might happen when long chains of patches interacted. I was surprised by how at some point it became impossible to trace the chain of patch interactions and all that was left was just to enjoy what was there to be observed.
While each patch was interesting on its own, the combination of multiple patches was where the real magic happened.
Pressure Project 1
Posted: May 7, 2026 Filed under: Uncategorized Leave a comment »Required Resources
- Isadora
- Shapes Actor
- Projector Actor
- User Actor
- Pulse Generator
- Wave Generator
- Random Number Generator
- Jump ++ Actor
- Scene Functionality
- 5 hours
My goal for pressure project 1 was to build a self generating patch that enabled users to play the original Mario Bros. with their body. I thought that I would be able to accomplish this using a version of Mario instantiated in Python for machine learning. This was an ambitious goal but I thought it would be possible to do it within the five hour window. If it proved to be impossible I knew that I could simplify it to achieve a reasonable outcome. I spent one hour setting up the patch, a total I spent 3 hours trying to get Mario running: Two hours trying to get a basic Python script to run in Isadora and one hour running it directly on my laptop with Isadora sending keystrokes to control the game running in python. Neither of these approaches was successful.
I spent the final hour crafting a new experience that borrowed from my initial concept.
Score
The user stands facing a camera. A message on screen informs them that a vitals scan is in progress and instructs them to move their body.
Blue shapes moves up and down the screen while a TT Edge Detect actor outlines their body, simulating a poor man’s retro body scan. When a blob decoder reports object velocity between 0.1 and 2, the Inside range actor fires a trigger. The trigger travels through a simultaneity actor and if a wave generator connected to an inside range actor is less than 10 or greater than 90, it will fire a trigger to activate a text actor, informing the user of success. It will also fire a trigger (delayed 5 seconds) to activate a jump++ actor and move on to the introduction screen.
The user is informed that the vitals check was successful. and they will now betrayed.
The screen goes black and you hear the iconic:
I then added a video of the first level of Mario. After a few seconds, before the player has a chance to recognize that they’re not actually controlling the game, the system begins to warp and distort the game video by sending the stage image through a feedback loop (this was going to make a very ironic re-emergence later in the semester). A message onscreen onscreen progressively unfolds to inform the user “Oh no. You broke it. Shame on you” the line “shame all over you” appears on screen and its position is periodically moved by random number generators hooked up to the position.
In total the experience contains five scenes that progress automatically upon fulfilled success criteria.
It contains three user actors. Two are nested in the control scene and define how the system is supposed to track user movement and convert them into controls for playing the Mario game.
The other defines how text is drawn up on the screen.
Valuation
I was unable to give the user control over Mario Bros. Instead I simplified the experience and fell back on an old favorite theme of mine, playing with the idea of technology failures as part of an immersive experience. I’m prone to stress when I can’t make a project do what I want it to do. In my first time taking DEMS, my first pressure project broke down and the experience was embarrassing. It was in my second project that I started working with simulated failures as an emotional trigger point.
Performance
The patch worked as expected and it was fine. Obviously a bit gimmicky. It was an important step though, because it had been a year and a half since I’d used Isadora and several months since I’d worked with TouchDesigner. The first pressure project was a nice reacquaintance with the software.
Cycle Three: A Collective Sound Explorer
Posted: May 6, 2026 Filed under: Uncategorized Leave a comment »As I alluded to in the previous cycle, I wanted to really focus on creating an experience for multiple people in this cycle, as part of my original goal was to do something for a group of people. As the ideas I was exploring in cycle two didn’t work out so great, I pivoted to creating an experience with several different kinds of sound manipulation, as opposed to one “instrument” that everyone could interact with at once. The different systems I picked to include in this cycle were: the 2D movement-based sound explorer from my first cycle, a patch that resynthesizes from a mic input using the Data Knot package, a FM theremin also using motion tracking, and an iPad connected to parameters of the different instruments using Max’s MiraWeb package.
Since the 3D version had some large issues, I chose to go back to the 2D version, since it was much easier to interact with. While the the code didn’t change much in regard to how it was working, I expanded the control capabilities for more “natural” input. In both cycles one and two, people found it unintuitive that only one hand had any effect on the sound, so for this time, I wanted to get two handed control working. I did this by just duplicating the original FluCoMa code, basically creating two “voices” for the instrument. I then mapped the coordinates of each wrist (received from MediaPipe in TouchDesigner over OSC) to a voice. By analyzing the sample folders with different thresholds for detection, I was able to create two different corpuses for the wrists to move through.
As I mentioned earlier, the mic input resynthesis was done using the package DataKnot for MaxMSP, which is used for real time audio analysis and processing, based in FluCoMa’s tools. The patch I used takes the signal from the microphone, looks for the onset of a sound (determined by a dB threshold) and triggers waves resynthesized from the most present pitches in the original. The signal onset detection also randomly triggers some strumming and “shaking” noise. While this instrument isn’t controlled with a camera, I did put a camera in front of the microphone, so that the user could still create visuals.
The theremin portion of the patch was done with a simple FM synth patch I have (fmcore~.maxpat). The y-values of the left wrist controlled the volume of the wave being played, while the y-values of the right wrist controlled the pitch. I had to smooth out the pitch values with zl.stream and zl.sum, taking the average of the most recent 5 values in order to prevent the pitch from wobbling around from unstable data.
The little grey box with the “FM THEREMIN” header in those pictures is where I connected the patch on my computer to an external iPad for parameter control. I did this with Max’s built-in package Mira, which allows you to connect a device on the same network to a Max patch. In addition to the pitch, FM ratio and depth of the theremin, I also gave the iPad user seven parameters for the Data Knot processing, as well as a mixer for all of the instruments
In addition to this, I also expanded upon my original TouchDesigner patch–which was handling the motion capture via Google MediaPipe–to create some particle visuals based on the landmark skeleton from MediaPipe. First, I went copied the code for one video stream into three, to capture data for all three instrument users. I mostly followed this tutorial to create them, as I’m not the best at TouchDesigner, but I took a couple of my own liberties. The two largest of those were that I used the skeleton video feed out of MediaPipe as input for the particles, and I also used noise to generate colors instead of the input video, as the skeleton is only white. Lastly, I placed the three skeletons in different spots on the screen in relation to where each station would be set up in the motion lab. Code is posted below.
Results
While there were some oversights I made when creating my patches, as well as when I presented this cycle, I overall feel that this was a very successful experience. People seemed really interested in the sounds the experience made, as well as in making them themselves. With the two camera-controlled parts, people seemed to understand their movement was controlling something right away, which was another goal of mine. I think that the sounds that the system made were quite interesting as well once every station had someone providing input. People also enjoyed the visuals, and seeing the particles flow with their movements.
While my mistakes in this cycle weren’t too numerous, they definitely detracted from the experience a considerable amount. In terms of presentation, I didn’t explain much about how to use each station. Part of this was deliberate, as I wanted to see how first-time users could pick up on the controls. However, there were still a few basic instructions that I should’ve given, such as how far to stand from the cameras, as well as that the camera by the microphone was not controlling any sound, just the mic. I also made a mistake by making the volume sliders on the iPad full range, as it just resulted in the instruments getting turned down too quiet. I think people also had a hard time understanding what the iPad was controlling in the first place, as some of the terms used for the knobs were jargon-y.
I think if I were to continue this into a cycle 4, I’d focus much more on making things more easily understood by the user. This class has taught me that the most effective interactive systems are made to create potential for experiences, not designing the experience itself. My ultimate goal with things like this is to create something that anyone can walk up to, interact with, and make something cool sounding regardless if they know every detail of how it works or if they haven’t even played an instrument before. While I think that these three cycles have shown a lot of progression towards that goal, I still have a lot of work to do.
Longer video from Michael pending