Over the past decade, I’ve had the privilege of being involved in several projects that explore the limits of the World Wide Web as a support for live multi-sited performances as well as the potential for network latencies to become expressive features of such real-time performances. Instead of being understood simply as the enemy to be overcome in order to achieve a “live-like effect,” network latencies become a necessary, even desirable feature to be interpreted as a contributing element of each performance.
The question of the expressive potential of network latencies has been on my mind with respect to Ghost and Mallarmovie: two recent experiments with the Zeega platform. Each is a tightly constructed sequence of slide animations deliberately designed both to expressively use network latencies and to push the limits of the medium of the database documentary, layering gifs and stills with such a high degree of density that the play time of individual slides as well as the animations that compose them becomes only loosely programmable. Visual rhythms, playtimes and sequencings come into being as a function of a labile set of factors: the interplay between user inputs, the bandwidth available on the client side, dataflows at the Zeega server, and the highly variable transmission speeds of servers feeding up the source files that are being stitched together in real time.
So how different is the experience of a given piece each time it is played? Just how variable are the pace, sequence of actuation, and couplings between components? I knew from experience that, under differing network conditions in differing locations, the variations could be considerable, especially if the end user either slowed down or forced the pace. But I wondered about another sort of limit case: how significant might the variations be if a given piece, in this case MALLARMOVIE, were played five times at roughly the same pace on two devices in the same location at different times during a single day?
Here are five takes. You can have some fun trying to run them simultaneously (i.e. synchronizing play times) even if the durations aren’t identical.
First take:
Second take:
Third take:
Fourth take:
Fifth take:
Though I haven’t timed anything with precision, here are some of the more self-evident variables:
–the opening spiral sometimes loads with the railway track and rolling dice gifs, but does so for only several cycles before stopping; in other cases it remains static or rotates uninterruptedly (as it was intended to do); sometimes it’s the transition to full-screen mode that is associated with it freezing
–the pace of paging gifs (slides 3, 5 and 10) varies slightly from one performance to another; in some cases the gif actuates belatedly, rather than at the moment of the loading of the slide; paging speeds are highly variable, particularly in the case of slides 5 and 10 (this was the effect that I was after)
–as with the case of paging gifs, the play or rotation speeds of various other gifs can be seen to vary from one take to the next; this seems to be the case with the loading icons on slide four, the flickering words (“jamais”) and phrases (“au fond d’un naufrage”) of slide seven, and the weather fronts in slide 15
–the blinking red light in slide 10 rarely repeats itself and emerges as the most sensitive indicator of the real-time stitching process; the advances and lags seems particularly variable in this case, whereas a number of other “heavier” gifs load and play far more predictably. Some of these effects are the results of deliberately manipulated loading sequences, built into the design of individual slides.