Perception is an artistic reflection on the perception of time. Using the vastness and emptiness of space as a backdrop, the sequencer explores how things closer always seem more urgent, while events farther away (whether emotionally or temporally) are often procrastinated on due to its apparent distance, even though they creep closer the same rate as everything does.

There's always something to do; as soon as I finish a task, the next one pops up. Sometimes it gets to be too overwhelming, but it'll always pass.

“I love deadlines. I love the whooshing noise they make as they go by.” - Douglas Adams. It's a ding here as they are met, but the sentiment is the same.

The sequencer provided a complementary set of challenges compared to those of the visualizer; in the visualizer, I struggled with the implementation more than the idea, while I struggled more with the idea than the implementation in this sequencer. Nonetheless, I think that my deep cogitation of what I was truly trying to express through the sequencer design challenged me in a unique way, and I am pleased with where I ended up. By milestone 2, I had most of the technical details (one could say the mechanics and dynamics) all set, and the only part missing were the aesthetics. I eventually settled on the idea that I had now through reflecting on the mechanics that I had developed: out of all of them, one that constantly stood as unintuitive was the fact that time moved slower the closer it was to the listener. While it made "physical" sense (as if the sequencer already rigidly followed the flimsy rules of our mortal realm re: sound in space, not using inverse square for sound and light attenuation over distance, and no orbiting objects lest everyone gets dizzy), in my mind it just never checked out. Even when I was describing the core interaction loop to others, I would often stumble there and say that time moved faster as it went closer to the listener. When I was confronted with developing the aesthetics more, I reflected on why there was this internal incongruence between what I had calculated and what I intuitively thought. I realized that what I had mapped onto time was not general relativity, as that was something that had little direct impact in my daily life, but rather the more psychological perception of time that I had (which maybe is shared among a more broader population too). My epiphany was that to me, the closer an event seemed, the more urgent it seemed, like how as I am writing this I think I have little time before I have to turn this in, while milestone 1 for the final project might as well be due next year. This notion fit very well with the existing mechanics that I had implemented. The alarm was more than an alarm, but rather as we said during the milestone 2 presentations, a concrete representation of time and things to be done that I considered important. As things start piling up, the sounds get more chaotic and the background pads get more and more layered and dissonant, creating a more agitated mood and environment. Thus, what I want to portray in this sequencer is how our perceptions of time change as things are shifted closer and further in our priorities. As for the setting, I put the clocks free floating because I think the emptiness makes distances feel more visceral, and that a greater emphasis is placed on the relative distances of each object since there is little to compare against. There are also fewer "distractions," setting a perfect setting for the clocks. The background colors gets more intense as it builds, and recedes as layers are removed from the field.

I think this is a very interesting sequencer technically as well. There are two directions in which I think this sequencer is quite novel: the object of its sequence, as well as its execution. In one sense, the sequence is not only the sequence of alarms, but also of the soundscape, and it directly reacts to its programming: adding more stars creates a richer soundscape, and adding more clocks layers the pads as well. Most common sequencers like drum machines and the like are strongly-timed, and very exact in their delivery of the sounds. This makes it so that a lot of sequencer have sounds that more transient (such as drums), which work well to discretize each cell in the sequencing grid. However, by using a less strongly-timed framework for my sequencer (where time is variable), it is able to accommodate longer-lasting sounds. Secondly, most sequencers use time as an independent variable. This makes perfect sense, as the incessant forward marching of time cannot be stopped: the arrow of time only knows one direction, and thus sequencers use this to their advantage, and letting the intesection of toggled buttons and recursing time dictate when the sound should play. The function signature from sequencers would be f(time) -> distance, where time dictates the distance between two sound triggers. For my sequencer, while it is not truly able to be appreciated in a time-agnostic manner, flips that paradigm on its head, and instead makes time the dependent variable in the sequencer. Thus, my sequencer would be more like f(distance) -> time, where the distance indicates whether or not it is time to trigger a sound. The playhead, something that is crucial in sequencers, is then not a global thing, but encapsulated within each time-keeping object, like the stars, the clocks, and the artist using the instrument, as the programming of the sequencer in adding more clocks acts as a playhead to change the underlying sounds. Furthermore, as a scene rendered in 3D, I was able to devote the extra dimension to more than signifying time, but as an actual spatial dimension. Thus, the relative positions of each object to the listener is used as a measure of its sonic properties, like an object far away will be softer than one right in front, or an object to the left will sound like it's actually there on the left side.

Overall, I would say that it was a unique but rewarding challenge work on the sequencer because of the abstract nature of my theme, especially compared to that of the last assignment. Code-wise, it wss much easier to ChuGL now that I'm familiar with it, and I'm definitely able to do a lot more with it. One of my hidden goals for this project was to be able to do a fully 3D scene. My visualizer was like 2.5D, but going into the 3rd dimension would have broken some of the immersion. For this time, I wanted it to be even more immersive in 3D, which I think I was able to accomplish. Thus, I am very pleased with how I was able to persevere through the aesthetic questions it posed me and eventually work towards what I think is a very unique sequencer that is expressive, philophical, visually interesting, and artful.

I have refined my idea a bit since when I first introduced it: instead of being "real-time" as in 1 second is 1 second, the sequencer instead portrays the idea of a clock rather than the clock itself. To this end, each second is very fast, which makes it possible to listen to an alarm go off within a reasonable time frame. I also added a mechanic where the distance of the clock to the camera dictates its speed: the closer it is, the slower it is as if the camera is a massive object that bends spacetime. While I think I have most of the mechanics down, the last question I have is with regards to the performance. I am wondering if I should shift away from pure alarm sounds and use more palatable sounds that might make a better performance but sacrificing the authenticity of an alarm. There's also the question of ease of use. It's not particularly easy to use, especially since the arrow keys add force to the alarm rather than displacement, which gives a more out-of-control feel and sells the idea that the clocks are in space more.