Ad Infinitum³

It’s been a while! I had almost forgotten that I was writing this blog, but I remembered just in time to talk about a project that I worked on a couple months ago called Ad Infinitum³.

Ad Infinitum³ was the brainchild of Andy Muehlhausen, who had worked on a project under the same name a couple of years ago. Both projects took about the same form: they were theater pieces disguised as videogames, in which the audience would interact with the “actors” (in this case, us) by playing the game. The game itself was separated into three stages, each themed after a specific conception of human groups, and they each played differently. The audience used their smartphones connected to a local network that we set up to play the game.

Unfortunately, I was not involved in many of the technical aspects behind the game engine — my coding experience wasn’t sufficient to aid in the building of the game engine itself. I CAN tell you that the game was written using a combination of Java and HTML5 (among other things), and involved a node.js server that we used to parse messages sent from the audience’s phones. We stuck with HTML5 because it allowed us to keep the level of tech low on the clients’ side — rather than downloading and installing a proprietary game controller app distributed by us, we could instead just have them connect to a locally-hosted HTML5 web page and use that as the controller.

As far as the design of each phase went, the first two acts were designed during the first iteration, but the third act was completely re-done. The first act, which concerned the individual, involved two modes: the “join” mode and the “eat” mode. Eat mode would allow players to consume other players, killing them and making the player larger in the process. If two players in eat mode decided to attempt to eat each other, the larger player would win the confrontation. The Join mode is where these interactions got interesting — if two players in Join mode collided, they would form a “family bond”, which prevented either player from being eaten by a solo player. While in the family, either player could switch to eat mode and eat others, which was hugely advantageous because it allowed them to consume without fear of being consumed, as they were invincible to other solo players. In this phase, we introduced the main antagonist of the game, dubbed the “creature.” The creature was extremely powerful and could move around the screen very fast, as it was controlled by a Microsoft Kinect tracking our dancer, Alyson. The creature couldn’t consume players in families, but it could break family ties apart very easily, opening players up to being consumed.

The second phase was the “family” phase, where we divided the players into three teams based on their family bonds. We would then flash a shape on the screen and command the players of each team to attempt to fit into the shape. If they were successful in fitting into the shape by our standards, we would “pass” them and they would receive a point. The performances of each team would dictate their role in the third act.

The third act involved all three teams united against the creature in an attempt to kill it. Each team had a different role: the first team had to gather supplies (crystals) and bring them to the corner of the map, where a weapon would charge. The goal was to charge this weapon to kill the creature, and the suppliers were the most direct path to the audience’s victory. The second team were the harpooners, which involved gathering harpoons scattered around the map and shooting the creature, which would leave a harpoon and a place to attach to. The third team’s objective was to attach to these hooks and “pull” the creature away from the other two teams.

An interesting tactic that we used to make the job easier for us (we had 10 weeks to build the whole game) was to take parts of the game that many would think to script (such as moments of cutscene transitions and determining whether the players were in the shape in act 2) and “perform” them ourselves. We had a MIDI controller that sent messages to Ableton, which was hooked up to Max/MSP through Max for Live, and we hit buttons ourselves to change scenes and start cutscenes. This helped a lot! Rather than having to set a specific time limit for each act to coincide with the music, we could simply count down the last couple of bars for each phrase and start the cutscene when the phrase changed, reducing our scripting task from “script the entire play experience such that it coincides with 30-second loops” to “script a 30-second cutscene”. It also made the game much more performative from our point of view, which raised a couple of cool and interesting questions regarding performances in both videogames and theater — if you take a system that’s typically scripted and “un-script” it without telling the audience, what effect does that have? And vice versa: scripting a performance through code will dictate the audience’s experience in a much different way than scripting a performance and having actors act it out.

The soundtrack itself was a lot of fun to write, and it’s easily the most cohesive piece I’ve worked on. The challenge was to have a piece that would loop easily without getting grating, and also be cohesive in a more global sense — I ended up releasing the soundtrack as a 23-minute continuous mix, so I guess I was pretty satisfied with its cohesion!

As far as my job went, I helped in the design of each act and helped with much of the sound design. I also worked on all of the sound effects and soundtrack. Andy was really great about putting a big emphasis on sound design (he’s a sound design major). We also had Dylan Phan help us with the backend coding, and by help, I mean pretty much write faster than I’ve ever seen anyone write. Eric May was our projection mapper and Primary Kinect Operator (PKO). Alyson Van was our dancer for the creature, and she was great with both improvising and taking directions from us. Rick Thomas was our coordinator and helped us keep on track with deadlines/milestones/etc. So there’s the staff list!

And some photos!



More stuff about Four//Four soon, I promise! Very substantial stuff!

Link to the soundtrack:

Posted in Uncategorized | Leave a comment

Anamanaguchi – Endless Fantasy

Chipmusic is in an identity crisis.

For what it’s worth, this will be simultaneously a review of Anamanguchi’s new full length Endless Fantasy and a look into what they mean to chipmusic as a whole. Maybe I’ll even answer the “what is chipmusic” question (said no one ever). First, I need to set this post up by providing a little context, so:


Here’s the thing: chipmusic is in an identity crisis because we don’t quite know what to do with the various definitions we’ve established for ourselves. Anders Carlsson (Goto80) does a pretty good job of outlining the definitions (, but in the end, we’re no closer to establishing what it is about chipmusic that separates us from other forms, media, and aesthetics. If we use the “medium” approach, then we’re too inclusive (literally anything with a soundchip can make chipmusic). If we use the “form” approach, then we’re still too inclusive (why bother using hardware when we have emulators, etc). Part of the problem is one of context: there aren’t very many reference points for chipmusic other than “old videogames” in our collective conscious. It used to be that chipmusic was referencing old tracker music made by the demoscene, or various other forms of music made on old/vintage hardware/software, but once we got to the old videogames association, that seemed to stick much better than any of the previous definitions we had come up with in the past. In order to understand why this videogames association has come to define what chipmusic is, we need to take a look at videogames themselves.


I’m going to start off with a little quiz. Notice how often I’ve used the word “games” in this article. I’m going to say zero (not counting the one in quotes) and the reason is essential to understanding why the association between old videogames and chipmusic exists. Games, as a form, are dictated by sets of rules interacting with each other. That’s easy enough to understand, right? But videogames are a different beast, because the prefix video- implies a certain context that we can’t really shake. You can call videogames games, but at a certain point the comparison starts getting a little hazy; Tetris is pretty easily seen as a game. Pong is a game. Spacewar is a game. But once we start inserting any kind of narrative elements (Spacewar already has some) into our videogames, it doesn’t seem to convey exactly what the experience is by calling it a “game.” Journey, for example, is both a videogame and a game. But to me, it is so much more a videogame than it is a game, and that’s because of the diegetic elements inserted by the developers. And here’s the thing: computers (remember the video- prefix?) make it REALLY easy for developers to give assets “meaning” outside the explicit area of game rules.

The tale gets more complex when you consider the idea of multimedia that computers make so easy. I consider the “on-a-computer-ness” of a videogame to be essential to the definition, because it really encapsulates what makes videogames as a form so much more dense than games as a form. Because computers can present users with every media at the same time, videogames have ended up being multimedia barrages of information to players. There’s just so MUCH of it. Not to mention that it’s interactive (how could I forget?). And when we start thinking about specific videogame assets, we can’t help but recall other parts of games too, like the mechanics, and the art, and the music (I’m tying it back together here, sorry).


So I’m going to try and bring it back: the videogames association with chipmusic has stuck around because of interactivity and multimedia. Interacting with any medium will always give a person a much more robust memory than non-interaction; or rather, the level of interaction dictates how many senses are joined in the reception of information — if we see a piece, it’s one thing, but to see and hear a piece is much more intense, etc. Videogames encompass almost all the senses (we’ll get the smelling in there soon don’t worry), and because of this, it’s almost impossible to really convey what it was like to actually play a specific videogame, because how are you going to recreate all of the channels of information being processed, much less being processed simultaneously?

That’s not to say that we haven’t tried. We can write about having played a videogame, or we can make a movie featuring the characters in the videogame. We can even play the music that we heard in the game! This is where chipmusic comes in — by using the actual hardware that we play videogames on, we eliminate one of the obstacles in front of that recollection. We don’t even need to hear the specific music coming out of the device; the device itself playing tones that sound like they would belong in a(n) (old) video game is enough to bring up these experiences because they were such all-encompassing experiences! Chipmusic (to the collective mainstream out there) is just another window into the nostalgia-driven desire for recreating the experience of playing an old videogame.


The most interesting thing about chipmusic to me has always been this association. For most people, it’s not so much the music itself as it is the experience of listening to raw, unprocessed soundwaves coming out of an NES/Gameboy/Amiga/etc. For better or worse, chipmusic will have this association for a while. Music in general has always been an associative medium for me — play a Linkin Park song made pre-Meteora and I’ll be able to tell you some story about how I was riding home in a car from my piano teacher’s house looking out the window into the sunset. (You could probably do that with many nu-metal songs made back then, actually.) I think a lot of it is because music is a time-based form, and I listened to a lot of music during periods of time where I literally didn’t have anything better to do than stare out a window — passing time, so to speak. To a lot of people, chipmusic does the same thing, but instead of stories of staring out car windows, those people will tell you about finally beating the last robot master in -INSERT MEGA MAN GAME-, or swimming up and down that coastline to get infinite rare candies so that you could get your Zapados to level 99 for no reason. But because it’s original music composed on old videogame hardware, it doesn’t reference specific videogames; rather, it references videogames. In this regard, one can think of chipmusic as an aesthetic (it’s not as limiting as you think, don’t worry) that reimagines what it’s like to have these experiences playing videogames. Note that I didn’t say it reimagines what it was to actually play the videogames — it’s what it’s like to have these experiences and reminisce upon them.


What Anamanaguchi does in Endless Fantasy is distill this aesthetic into a 22-track, 76-minute-long opera.

I’ve had kind of a problem with most writing about what chipmusic is. A lot of it can be attributed to the fact that none of the writers ever take the time to explore deeper beyond the surface level of videogame association. At this point, we all understand what chipmusic is, but we’ve always had a problem with what chipmusic is (aesthetically speaking). Anamanaguchi seems to answer that question pretty well throughout Endless Fantasy. A common complaint regarding the album is that it’s too long for the sonic palette that they present. I may not be the best person to provide an objective statement regarding album length (hint: I fucking LOVE long albums), but I think that Endless Fantasy‘s length is precisely why I enjoy listening to it so much. It’s not so much about “listening to music” in the traditional sense as it is about immersing yourself in it, exploring every musical nook and cranny, and coming back up for air every once in a while. While you’re down there, you’ll probably be forced to confront your memories regarding videogames/nerd culture/being a KID, damnit, and your enjoyment of the album will depend on how this confrontation goes.

The songs themselves seem perfectly suited to this immersion; only a couple of them have lyrics, and the lyrics are almost meaningless out of context. In context, they’re exclamations of rebellion, declarations of optimism that don’t really matter outside of the album (but who cares because we’re living right fucking NOW, and that’s all that matters). The rest of the album is content to provide you with incredibly dense, rich soundscapes that don’t ask much of you other than your existence while each song plays. This participation is what really grabs me when listening — so much music is inherently selfish, as it’s just artists talking about themselves and their own experiences (which isn’t a bad thing, obviously). Endless Fantasy, through its lack of lyrics, isn’t about Anamanaguchi — it’s about you and what you feel when existing in each soundscape (read: song). It’s an album almost perfectly designed to daydream to.

As overwhelming as Endless Fantasy can sometimes be, a look at the song titles reveals that the subject matter is much less complex than the music itself, and that fits the themes of the album really well — it’s an Endless Fantasy! You wouldn’t be fantasizing about the human condition in an age of post-information, you’d be fantasizing about space. Explosions. Prom nights. Anamanaguchi, on Endless Fantasy, has written perhaps the best song I’ve ever heard that deals with snow, which is a specific example that really pinpoints what Anamanaguchi is good at doing — creating a space for you to think about your own experiences with a specific idea. Snow is the kind of thing that everyone has memories about that are almost too nuanced to explain to anyone else — the only thing we can do is talk about our experiences re: snow, which is again what talking about videogames is like.

It made a lot of sense to me when I heard that Anamanaguchi were doing the soundtrack to the Scott Pilgrim game. In some regards, Scott Pilgrim has aims similar to what I described chipmusic as — it’s not a recollection of being a nerd, but rather a reimagining of what being a nerd is like. Throughout the graphic novels (and subsequent movie), there were all sorts of random visual references and nods to videogames and anime, almost as if each specific reference was but a part of an overall aesthetic that Scott saw only in his mind. Often, I feel like that’s how a lot of people experience their lives; things make SO MUCH SENSE in your head and you want to tell everyone about them SO BADLY but when you try to, you get a raised eyebrow and a change of subject. The reason I enjoyed that franchise is the same reason I enjoy listening to Endless Fantasy; for all the posturing nerd culture sees, and for all supposed unity that we feel under the banner of -INSERT FRANCHISE HERE-, no one else will really get what it’s like to enjoy the things I do. That’s ok. In fact, it’s better than ok — it’s pretty damn great.

Posted in Uncategorized | Leave a comment

Common Time.

It’s been a little bit! I had been on kind of a tear with posting blog entries but this weekend took it out of me, apparently. Well here I am again and ready to talk about the design of Four//Four and why it necessitated the weird code that I wrote for it!

Thinking about the concept of time signatures is really interesting. The idea that we can structure music based on almost arbitrarily-measured units of time (I only say this because a time signature doesn’t actually dictate how long a beat is in explicit terms; it’s a combination of the time signature and the tempo of the song) and have it just make sense to us on a subconscious level is pretty fascinating to me, and it gets even more fascinating when the specific case of 4/4 time is considered. I’m putting myself out on a limb here, but I’m going to go ahead and say that 4/4 time is by far the most popular time signature to write music in — people have gone so far as to call it “common” time, which should tell you something about its frequent use.

Perhaps I haven’t done enough research into it, but I have no idea why 4/4 time seems to be the collective “favorite” time signature. Maybe it’s the idea of being able to split a measure up into two parts, but have them exist in a point/counterpoint relationship? Maybe it’s the symmetry that the time signature gives; the second half of the measure takes the same amount of time as the first half, just as the first fourth of the measure takes the same amount as the last fourth, etc? Maybe we just really like the number four in music? Other time signatures capture our mind in different ways, sure, but none have dominated the musical landscape like 4/4 has.

I wanted to pry into this almost subconscious relationship we have with 4/4 by making this game. Admittedly, I won’t have even cracked the surface of our obsession with common time (I need to switch professions if that was my true goal), but I like to think that I’ll have said something about it.

So: Four//Four. It’s a game about repetition and discovering embedded rhythms. A lot of my inspiration for this game came from my not-so-recent obsession with electronic dance music (EDM, an unfortunate term for a very broad genre).  Many like to deride it for its repetition, but that’s what I really like about dance music — it almost requires you to disengage from thought when listening. In fact, the trance sub-genre is DESIGNED for this disengagement. Coincidentally, almost all of this music is written in 4/4. As such, the music during my game takes the form of 16-bar loops, one of which will endlessly repeat until you have made enough cubes disappear to progress to the next part of the song — until you’ve been “rhythmic” enough.

I’m trying to design each song’s (or in this case, the one song I’ve been working on) cube launch patterns such that a player can progress simply by tapping a side to the beat for the entirety of the song. If you can tap out a 4/4 rhythm, you can progress to the end of the song, or at least that’s what I intend. However, the cubes will be launched in lots of different patterns, some requiring the player to hold their finger on the screen, and some requiring knowledge of the song previously. I don’t really want anyone to be able to get through the entire song perfectly on their first try; otherwise what’s the point of repetition? Ideally, the player will enter a section, spend some time figuring out how the patterns work simply by watching, and then attempt to match the rhythms they’ve seen.

This design may seem a little backwards to people — surely players will be bored by having to repeat the same section over and over again? Normally, I’d concede the point, but when listening to electronic dance music, we have to re-orient how we think about music. Repetition is the REWARD in dance music — the reason live DJing became popular was because audiences wanted the “good” parts of the song to go on forever and ever. The best dance music acknowledges this while trying to subvert it at the same time, gauging listener expectations and throwing them curveballs every once in a while. The best dance music doesn’t give listeners what they think they want — it gives them what they didn’t even know they wanted. I purposely set a higher-than-normal limit for making cubes disappear before progressing to the next part to reinforce this idea that repetition is not a punishment. The reason I wrote the code with all of these arrays is because I didn’t want to script every single instance of cubes launching. Rather, I’d set a rhythm at the beginning of a section or measure, and then the game would play the rhythm back to me repeatedly until I wanted it to change.

At the same time, the cube launch patterns are designed to be complicated when you look at them. I don’t know if I’ve succeeded yet, but ideally the player won’t be able to rely on pure visual feedback to play the game. More and more, music is turning into a multimedia experience, meaning visuals synchronized with audio; the other senses aren’t far off. I wanted my game to piggyback on that idea, mostly because my favorite games have always successfully made their sound design with regards to music an integral part of the experience (hint: SSX3 is one of my favorite games).

I think that’s it! Or at least all I have to say about it right now. Hopefully this gave you at least a little insight as to what Four//Four will be!

Posted in Uncategorized | Leave a comment

Code? Code! (Part 2)

Last time I talked about the tools used to build the game. That shouldn’t really say much, though, because any tool can be used to make something great! I think Hotline Miami was made in Game Maker, if that says anything. Regardless, this is the part where I open myself up to getting judged based on code, so here we go!

Timing —

The entire game is based on whether players can perform actions rhythmically or not. Needless to say, having a solution for making sure that the right rhythms were being represented was pretty important. I decided to have a GameObject in control of both the timing and switching between song sections, for no reason other than it making sense in my mind at the time. Attached to this GameObject is a script that keeps track of the time for 16 measures by using the samples from the song (at 44.1 khz) and doing some calculations to turn samples into units of time. I could have simply used measurements of time, but during my furious Googling period, I discovered that Unity is quite average at keeping track of time in small amounts, and I needed something better than average.

Arrays forever–

In the metronome script, the position of the song is compared to a 16 member integer array, which stores the subdivisions in 16th notes for a measure. I also have a variable that stores which 16th note the song is currently on. If the position of the song has passed, say, the 5th member of the array, then the variable will update to say that it is on the 5th sixteenth note of the song. There’s also a variable that tells me whether I’m actually on a sixteenth note or not. This array pattern actually structured a lot of my game, and pretty much any time I need to script something related to when cubes launch, I use a 16 member array that gets compared with the metronome.

Launching stuff and scripting launching and stuff and stuff–

Stuff. Everything in the game that needs the metronome can then listen to the metronome that’s letting me know what measure and beat I’m on, as well as whether I’m actually on a sixteenth note (there are a lot of public variables in this script). Then it’s just a matter of determining which kind of cube I want to launch and scripting it so that it launches on time. I have a script that handles launching of cubes by doing LOTS of comparisons to the metronome using arrays. The unique thing about this script is that it’s a set-it-and-forget-it system, where once a specific pattern for a 16 measure phrase is set, it will repeat over and over until I change it. I did this to avoid conflicts with scripting cube launch patterns and the position in the song — there are way fewer variables to look out for with this structure. There are arrays for all sorts of timing-related things in my game; checking to see when I should remove a cube from play, or making the cube respond to different rhythms, for instance. After this cube launching script, I just have blank GameObjects with scripts for specific songs (or in this case, one song, because I don’t have more than one) that listen to the metronome and adjust the cube launching script as necessary.

Whew! That felt like a lot! Next time I’ll tie it all together and give some sort of explanation of my code based on design and etc. It’s also the post that I’ll enjoy making the most I think!

Posted in Uncategorized | Leave a comment

Code? Code. (Part 1)

This was supposed to be an obligatory post about coding and how bad I am at it but I’m instead going to use it to talk about how I structured my game in code. I figured I should try and get it out of the way now since most of the back-end stuff is complete, but there is a disclaimer that’s going to be pop up around here.


I am not a programmer. I do not claim to have any skill in proper, efficient, or even rudimentary coding practices, and most of what I’m going to spit out in the next couple of paragraphs is the result of me furiously Googling potential solutions to my problems that don’t quite work. /DISCLAIMER

With that, here’s an overview of the tools I’m using and why I’m using them.



After finishing my previous project Eternities (which I somehow completely forgot to post about on this blog, I think), I ran into the problem of completely forgetting to optimize the code for mobile devices. This was after 4-6 months of getting myself from “no coding experience” to “enough coding experience to finish a Flash game”, and I was tired of working on that particular project. So imagine the feeling you get when you first see your game running on an iOS device after having never completed a game project before, and then realizing that it’s running at literally 5 frames a second, after which you frantically search the internet and come to the conclusion that you either have to revamp your code or learn Objective-C to get it to run. I took the easy way out and just threw it on the internet, but Unity will help me avoid this situation in the future (I hope). I’m not going in with the assumption that I will NEVER need to optimize again, but at least with Unity I will be both learning a real 3D development environment (while making 2D games because I’m an idiot) and I won’t have to worry about super specific cross-platform details anymore.


2D Tookit by Unikron Software:

This is how I’m getting Unity to play nice with 2 dimensions. It’s a pretty easy-to-use toolkit (hence the name) that optimizes a lot of Unity’s workflow for 2D games, and I’ve found it pretty helpful, especially since my previous background involved FlashDevelop only. At $65, it’s not the cheapest solution to 2D inside a 3D environment, but then again, this solution doesn’t involve painstakingly making sure that every asset will play nicely in 2D, so I’m ok with shelling out.


PoolManager 4 by Path-O-Logical Games:

This is a little embarrassing, but again, disclaimer. After switching from Flixel to Unity, I was COMPLETELY stumped as to how to pool game objects for use and reuse, mostly because the way that objects interacted with each other in Unity was so different to me. This tool helped me wrap my brain around how pooling works in Unity, and that’s pretty much it. Not much else to say about it!

So there it is! My tools! But how does the game work, you ask? Well you’ll just have to wait for another post because this post is getting too large! At this point it should be obvious that I don’t really know how to talk about coding in a traditional, academic sense, so you’ll have to excuse me while I figure out how I’m going to approach this.

Posted in Uncategorized | Leave a comment



The above is a screenshot of the game project that I’m working on called Four//Four. It’s a rhythm game designed for mobile where the player will be tapping both sides of the screen to change their color and make cubes disappear. If the side that you tapped switches color to match the color of a square passing through it, that cube will disappear. When you make enough cubes disappear, the section of the song will progress. Needless to say, the cubes will appear based on rhythms in the song!

That’s the straightest description of the game I can give, and that’s probably for the best. It’s actually a really confusing game to describe to someone using words, which I’ve discovered after trying to describe this game to numerous people in person. It’s much easier to understand when watching the game in motion, and that will be accomplished when I actually get a playable section of the level that I’m comfortable with showing off on Youtube. Until then, that domino screenshot and my description will have to do.

I plan on making this game into something that’s at least a little bit marketable on app stores through the music in the game. I will be composing at least a couple tracks for the initial release, and with any luck, I’ll have other musicians (chiptune or otherwise) compose tracks for the game!

The name refers to the time signature 4/4, which is what most dance music is composed in. I like focusing on dance music because I don’t think it should be as guilty of a pleasure as it is for most people. The most common criticism of most dance music is that it is too repetitive to the point of over-indulgence which, while a valid criticism, indicates the wrong approach toward critical thinking about this kind of music. For a long time now, I’ve lamented the lack of good academic writing about dance music and dance music culture, and I’ve always wondered what caused this — the genre doesn’t lack for fans, and enough smart thinkers are interested in the phenomenon.

The answer to this question coincides with one of the reasons I’m making this game. One cannot think about mainstream dance music in the traditional sense; study of the theory behind this music is rather boring, in my opinion — there are only so many places one can put a hi-hat in a measure, after all. Dance music is fundamentally a physical experience, as indicated by the name itself. As such, when one thinks about dance music, it must be through the body as well as the mind. The cognition is distributed, to use a buzzword.

I feel like the same case is present in rhythm games. Most rhythm games are focused on matching visual cues with aural cues, and while such a combination is often very conducive to dance music, I believe that alternative approaches are forgotten. I want to design Four//Four to be a game that can be played without even looking at the screen; a player will simply tap rhythms that he or she believe to be the most interesting rhythms in a particular song section, and the song will respond by progressing. Obviously I’m a long way off. But I’m now at the point where I can start thinking about designing around songs I’m using, rather than thinking about how to implement yet another way to send cubes across the screen.

I’ll go more into the design process in future posts! I just felt that this game deserved an introductory post.

Posted in Uncategorized | Leave a comment


A working prototype of the website can be found here:


This was a project for COGS121 (Studio in Web Design) in which we attempted to create a tool that would allow students to study efficiently using lecture podcasts and lecture slides simultaneously. This was a continuation of our project in COGS102 (Studio in Human Computer Interaction) in which we analyzed user needs and deficiencies with current podcast study implementations.

We found that the use of podcasts was hampered due to the separation of platforms used to study — users would often study with lecture slides hosted in a browser, lecture podcasts hosted in a different tab in the same browser, and written notes in a notebook. The problem with separate platforms reared its head when the user decided to rewind or fast-forward. Because the platforms are separate, changing the timeline of one information stream forced the user to stop studying completely, synchronize all the media, and then begin to study again, greatly disrupting any workflow maintained during listening.

Our 121 project was an attempt to lessen the workflow disruption when adjusting media streams. By keeping all pertinent information on the same screen, the user can fine-tune control much more easily, allowing the user to maintain a workflow while studying with lecture podcasts. Future implementations of this project will involve automatic media synchronization, which allows the user to adjust multiple media streams using a single stream.


Posted in Uncategorized | Leave a comment