The time between posts is definitely not a sign of Processing inactivity, rather the exact opposite! Been so busy with several experiments that I just haven’t found the time to post vids and/or write about my code adventures. But here is a little write-up for my latest animation called Subliminal Glitch. I’ve been interested in glitch art for a while now. A discussion in the forum finally gave me the right push to start experimenting with glitch art in Processing. Aesthetically my final animation is probably closer to datamoshing and compression artifacts, than to glitch art resulting from replaced bytes in an image. Of course, technically it’s not pure malfunction glitching, but rather a re-creation or mimicking of the aesthetics of the glitch using different techniques and functions in Processing. There are many existing Processing functions that can be useful for this purpose, for example get(), set(), filter(), blend(), tint() and the pixels array in combination with bitshifting.
My animation has two main layers. First, the ‘normal’ image. This is mainly made up of the typography and a particle system that has color-based collision. Simply stated, the particles stay either inside or outside the letters and they bounce of ‘em when they get to close. The second part, is the glitch system. I used object-oriented programming to write it, which means a glitchObject can easily be added to and run on top of another (read: any other) sketch to create these effects. 🙂
The glitchObject consists of a series of glitch-functions, which are sequentially (and thus cumulatively) applied to the image. I just started writing the first glitch and gradually added more and more. Slowly increasing the complexity and unpredictability of the result. Funnily enough, things started to get interesting fairly quickly. Of course, you could add as many glitches as you want. In this preliminary experiment, eleven glitches are applied. Of these, seven are getSetGlitches (randomly copying parts of the image to somewhere else), two are elementGlitches (adding horizontal and diagonal lines) and two are colorGlitches (filters for inverting and dilating the image). So the bulk is in the get() and set() functions right now. I know these functions are not ideal. But it was just the easiest and fastest way to write it for me in an experimental phase. Therefore the program is completely unoptimized and in fact very inefficient. To improve the speed, you’d probably want to replace all the get-sets and color effects by pixel arrays and bitshifting. However these can be a little less intuitive. At least for me they’re still quite enigmatic, so that would need some investigating on my part before I can really use them.
I’m running the application at a full HD resolution of 1920×1080. Right now framerate isn’t optimal, but this really results in an interesting side effect when recording to a movie. Because when the movie is played, it blasts through at an enormous pace! For the video I wanted something energetic anyway, so I coupled the visuals with a mixtape. I then increased the pitch and speed up to 160%! Of course this video absolutely kills Vimeo compression. But luckily this suits the subject perfectly.
Links related to this post: