Kaiju Hero K.O.! – Cycle 3

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

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…

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

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

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

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

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

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.

Inside fmcore~.maxpat

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

The other two Mira windows as they appear in my patch.

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.

Overview of code, as well as example of what the visuals look like. Only my webcam is routed through the patch in this image.
More detailed look at my visual chain.

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


Independent Study with Makey Makey

Building on my skills and experiences from the DEMS class I took last semester, I wanted to use some independent study time to continue experimenting with Makey Makey to keep developing ideas for my MFA thesis project in dance. At the end of last semester, with the tools I had been experimenting with in DEMS such as Makey Makey, OSC, Live Video, NDI camera, Isadora, I combined my interests in movement and technology in my 2nd year showing performance and presented my work to my dance colleagues and professors. In that showing, I had used Makey Makey as a bridge between touch and memory/answer/response. After receiving feedback and progressing my ideas, I steered toward another trajectory in my approach where I started experimenting with absurdity and humor to reach the depth. This was also a progression I was able to mentally achieve this semester after the experience I devised with honey in DEMS last semester. Letting myself include objects in my artistic works with curated associations allowed me to keep asking and answering the question “What is the experience?” with each trial.

This semester, I also took a composition course called Rebel Innovations with Abby Zbikowski, where I had the chance to work on a new solo piece. In that piece titled “Am I too much pink?” I used several objects. Some of them are pink sunglasses that make you see the world in pink when you put them on, another pair of sunglasses with pink flowers all around the frame, tiny sunglasses that is too small for a human head, an ornament shaped like a unicorn, and a pink spatula shaped like a guitar.

Using objects, humor, and silliness, the piece implicitly explores themes of queerness, childlike disinhibition, neurodivergence, and ways of seeing/perceiving, through my and the audience’s interaction with the objects.

For my Independent Study, I decided to pursue my intended scores within this new context. My work for that class didn’t have the deep media systems component engrained other than using my phone to play music/sound and someone else’s phone to use the flashlight as a “spotlight”. But I remained interested in incorporating media systems because I am still interested in composing my final MFA thesis project with technology incorporation. So I worked with Isadora and Makey Makey to discover what the possibilities were. My main question was “How can Makey Makey and Isadora help me with building a bridge between object and meaning through a technology interface?” I remained interested in pursuing touch as a trigger for a response. My objects were mostly plastic and weren’t gonna conduct electricity the way I would need them to. So once again, I used the help of the conductive pencil to complete the Makey Makey connection. I programmed an Isadora patch with 9 scenes.

Using the keyboard watcher, text draw, trigger delay, jump, wave generator that’s set to random, colorizer, spinner, dots, and enter scene trigger, I designed/devised an experience where seeing the image of an object would prompt the interactor to touch the object, the object being touched would trigger a text or video to show up and those objects, texts and videos would accumulate in more questions for the interactors for them to reflect on internally.

Even though my initial Independent Study score also included exploring the relationship between camera, movement, and OSC, in this new context, I built a new relationship between movement and technology through pre-recorded videos and specific timestamps in the videos where that specific action would occur, asking the interactor to trigger the next scene through touch via Makey Makey when they encounter a specific movement.

As I have one more year left to develop my final piece, I am still in the building, questioning, asking, and responding phase. My explorations are finding micro shifts and deepening through experiments. With this Independent Study, I managed to accomplish my own scores and create a more solid foundation for my future creations involving objects, movement, Isadora, and Makey Makey.


Cycle 3 – Solo 2: Electric Boogaloo

Hello! Welcome to the official successor of Solo: Paper Plate DJ.

I won’t go into much detail on the pre-production and programming for this iteration, as not much has changed on that end; refer to the first post for that. The most important update to the project is in the controller; we are no longer using a paper plate (woohoo). We used a bucket (2 of them to be exact).

There were 9 inputs wired into the two buckets: 3 based on taps and 5 on holds. Originally, the player was to wear my watch with the conductive alligator clip attached, which worked pretty well for me, but stressfully, during the presentation, it was not working for Zarmeen. Michael came in with a save by lending me a bracelet designed to do exactly what my jimmy-rigged watch was meant to do (be a bracelet that makes the user conductive). The user finger-tapped their way through the visuals, each labeled with a lyric from the song (what the visuals were connected to).

While this controller was a big upgrade over a plate and closer to my vision of evoking a sense of musicality and rhythm in the user, it had its flaws:

Flaw #1. Nobody could remember the lyrical labels, nor did they look at them during their performance.

SO yeah, turns out it’s hard to read and hit buttons that make visuals appear at the same time. I was not shocked at this feedback, as I found myself not reading them as I played, but I also know the song, so I wanted to test it anyway. I’ve decided to incorporate the lyrics in another way that will hopefully be more effective (check my final post for that reveal).

Flaw #2. The buckets are janky

The buckets are janky. They are a bit ugly and easily disconnect from their inputs (the Makey Makey)… I will try my best to make this less the case in the next cycle.

Flaw #3. The meaning of the song did not matter to the users/was not clear.

Because no one remembered the lyrics and felt they were mostly preoccupied with making the coolest visual combos possible. I hope that by incorporating the lyrics into the visuals, the user will take heed of them.

Okay, time to be more positive.

My classmates reported feeling immersed in the process and as if they were performing or learning an instrument; some even expressed nervousness when in the “spotlight”. This accomplished one of my goals: to simulate the feeling of, well, performing a solo. I really enjoyed watching the unique interactions as people took turns. My classmates were oohing and aahing, and trying out different techniques to garner different visual combinations. I am lucky there are so many actual musicians in the bunch. Now I just need to accomplish some sort of meaning-making process in this experience.