Author: Jonathon Haley

To make this video, I synchronized the video and audio taken from two different phones, added cuts between the two camera angles, and applied a bunch of effects for fun. I kept the audio from both phones to ensure that both videos were in sync, but then muted one of the audio tracks to get a cleaner sound.

This project will make you hungry.

We’re making a cooking video. You, the user and viewer, make choices in creating your dish – how it’s cooked, selecting which ingredients go into it, which toppings will cover it in the end. Depending on the choices you make, each step in the food preparation process will happen differently, and the product you’ll see at each point in the process as well as at the very end will change accordingly. Each step of the way, you’re presented with a video showing what you did and the outcome of it, and the option to go to the next step.

In the end, you get your dish. You’ll have the option to download or share a screenshot (or different screenshots from each part of the process) or, if possible, video of your creation. This could turn out to be the most technically demanding part of the project (and we might not do it if it’s too complicated), but it’d be a nice feature to be able to concatenate all the short video clips together into one longer video that the user can view together and download. We might even give your dish a name, based on what processes and ingredients went into it – if you chose to do some wild stuff, then expect a suitably strange name.

In terms of technique, we’ll probably present this in a cooking-show format – not as a show per se, but having a clean, clear presentation style. For the host website, we’ll want to use a style and layout that is visually pleasing as well as intuitive to use (this should go without saying, as hopefully all websites follow a similar standard). To code the website, we’ll obviously need to learn how to display videos embedded in a webpage. Overall, the most difficult part, aside from video file concatenation, will be creating different video clips that flow together when played in sequence.

The line that struck me the most from Chimamanda Ngozi Adichie’s 2009 TED talk was this: “The tradition of telling African stories in the West [is] of Sub-Saharan Africa as a place of negatives, of difference.” It’s really true. When we look at people whom we perceive as different from us, whom we cannot identify at first glance, we see all the ways in which they’re not like us, rather than all the ways they are like us. Where there should be the promise of friendship, there is instead only pity, aversion, or some other emotion which comes from seeing the other person as being on a different level from oneself, rather than as an equal. It’s because we see people only in the way we expect them to be – we think there is only, well, a single story behind them. As Adichie said, “To insist on only [the] negative stories [from my past] is to flatten my experience, and to overlook the many other stories that formed me….The danger of stereotypes is not that they are untrue, but that they are incomplete.” When looking at another person, while it’s certainly easier to think you know everything there is to know about someone, to put it simply, you don’t. To treat another person as a human being is to accept that they, same as yourself, are made up of a myriad of experiences, influences, and countless other factors, and that you can’t really know them until you understand more about who they are, and the unique factors that have shaped them. Anyway, I think that seeing other people in this light opens up whole new worlds of possibilities – despite what you may think you see at first, each person is as complex as you are. Whether or not you get along with each other, or can see eye-to-eye, depends on the individual – it won’t always be the case, but it’s better to try and give them a chance, than to assume you already know who they are, because you don’t. So perhaps the only reliable single story is: Everyone’s similar, and everyone’s different. Beyond that, you’ll have to see for yourself.

Link to Fireworks

For this project, Ruby and I decided to make a fireworks simulator. Click anywhere on the screen, and fireworks will shoot up and explode. When the fireworks explodes, not only do you see vivid colors and glittering trails, but you also hear one of the fireworks sound samples that we created.

Ruby was in charge of creating and downloading the various sounds we used to create our fireworks sounds. She recorded a number of strange things, such as hitting a whiteboard and crumpling paper bags. Since there were some sounds, such as large explosions, that we could not replicate ourselves, as well as various other noises we decided to include (listen to the sounds closely…), Ruby (and to a lesser extent, myself) also found some sounds online at freesound.org which would serve our purposes.

We combined the recorded and downloaded sounds in Audacity, using a combination of trimming, amplification (volume adjustments for individual tracks), and reverb, to create four very different-sounding fireworks samples.

I was in charge of creating the code and scripts for the fireworks website. My initial idea was to have a black screen (like the night sky at real fireworks shows), and when you click an area on the screen, a GIF of a real fireworks will play where you clicked, and at the same time one of our recorded sound samples will play. However, after some Google searching I found a better solution. I found some Javascript code online at https://codepen.io/whqet/pen/Auzch which served our exact needs – creating fireworks on the screen whenever/wherever the mouse is clicked. I added this code to our script.js file. There’s a line I made in the code using comment /// slashes – everything above it is script and functions that I wrote, and everything below it (besides calls to the above functions, and also tweaks to a few numbers) is from the above link. Per the original script writer’s implementation, I also added a <canvas> element into our index.html page, as well as a bit of CSS for the mouse crosshair style.

A big challenge I faced here was making audio play in the background – not only would a random audio sample (from among the four we recorded) have to play every time a firework is created by the user, but it would also need to be at the same panning (x-axis position) as the place the user clicked. After a bunch of messing and trying different approaches, with help from IMA fellow Tristan, I found the solution to be to create an AudioContext object and StereoPannerNode, and connect the two together. Ruby and I also decided to add a progress bar, which increments every time the user launches a firework. When the progress bar is filled, a bunch of fireworks launch to random parts of the screen and explode, triggering a bunch of different audio samples at once. To make this work, I had to partition much of my code into smaller functions, which could be called multiple times for each firework.

Side note to the user: every time you fill up the progress bar, the fireworks becomes slightly thicker – with more particles exploding out of it. It’s not super noticeable (which is why we don’t point it out on the page), but if you fill it up enough times the fireworks become quite large.

The final problem I dealt with (although it came up pretty early in the process) was making the sound play in Chrome – although the visuals worked fine, you wouldn’t hear anything. This, I learned, was due to restrictions on autoplaying audio set in Chrome, as well as restrictions on running audio locally (possibly also having to do with autoplay restrictions). To circumvent the first issue, I made the audio only load after the first time a user clicks somewhere on the screen, as Chrome allows you to play audio after some sort of user interaction. With IMA fellow Dave’s help, I set up a local host (localhost:8000), and was able to run the website there with no problems. This was a perfect workaround, as it simulated how the website would run after being uploaded to the NAS server, and allowed the audio to play as desired.

In the end, the audio (and the rest of the website) works in both Firefox and Chrome (Firefox didn’t even require running a local host!), but not in Safari. In Safari, when I try to instantiate a new AudioContext with the line “let context = new AudioContext();”, I get the error “Can’t find variable: AudioContext”. Apparently the AudioContext class isn’t accessible in Safari, so as a result the audio for the website doesn’t work in Safari (though the visuals work fine). I’m not sure what the reasons or workarounds for this might be, but it’s not super surprising as different browsers do seem to treat audio a bit differently (hence how Chrome required a local host to play audio, but Firefox didn’t).

In conclusion, while our project may have been simple in concept, it actually took a great deal of work to imagine, create, and execute the various details – especially recording, finding, and combining different sounds to create the fireworks samples, and creating full audio functionality with panning, multiple simultaneous audio tracks, and cross-browser compatibility. I consider this project a success, and look forward to the next one.

We had two readings for today, “On the Rights of Molotov Man” by Joy Garnett and Susan Meiselas, and “Ecstasy of Influence: A Plagiarism” by Jonathan Lethem.

“Molotov Man” featured a photograph of a young man, later revealed to be a Nicaraguan rebel, winding up to throw a Molotov cocktail, with a rifle clenched in his other outstretched arm. Garnett took this and other photos of human anguish and made them the subject of paintings. Meiselas, the original Molotov photographer, eventually came calling, asking for the payment of a hefty licensing fee to represent her photographs in other media. But greater than the legal issues posed here, was the question raised by an online blogger, “Who owns the rights to this man’s struggle?” The answer, especially in today’s world of near-unlimited sharing of knowledge and experiences, seems increasingly to be: anyone to whom it speaks.

“Ecstasy of Influence” dives into the concept of plagiarism, and the notion that copying someone else’s work or ideas is inherently bad, and should avoided. Lethem argues that copying not only is perfectly fine, it is ubiquitous and unavoidable. All of our thoughts, our speech, and our actions are in some way influenced by the other people, media, and society we’ve been exposed to. If that seems too general and vague, then we can just look at the arts: particularly in writing and music, artists constantly copy, reference, and expand upon other artists’ ideas. This is how we get cultural narratives and concepts that survive the trials of time and society. While few (if any) of the ideas we see can claim to be completely original, this doesn’t take away from their artistic quality. To drive his point home, at the end of the article the author goes through his entire work section by sentence, phrase by phrase almost, and notes specifically where each concept or word came from. And that’s just the direct influences one can easily point out, not even mentioning the subtle, subliminal influences and biases we acquire over time, to the point where we don’t even notice them. Anyway, it’s an interesting inquiry into what copying is, and why it’s laughable to pretend not to be doing it all the time.