Developing a critical technical audiovisual performance practice engaging with 'the web' as both medium and subject matter.

Overview

I’ve worked this project on and off throughout the research period. Unlike the others, it hasn’t been made with any specific artistic goal in mind, or, as with Improv Tool, I haven’t built it to explore any one technique or type of performance. Sandbox tool is my holding space for features or functions from other projects that I want to continue to use and experiment with.

Project

Development

I have made the conscious decision with other projects (all but this and TAB) to adopt a fairly simple approach to web development; using static HTML, plain CSS and vanilla JavaScript, rather than utilising modern JavaScript frameworks that serve to reduce some of the more rote or laborious tasks involved with static website development. This has been in pursuit of celebrating and championing a ‘DIY’ or ‘Handmade’ web, an aspect of my practice that I would consider important to communicating one of my key ‘critical technical’ positions, namely that the web feels less interesting now because it is over professionalised (see Context: The Web), and keeping the arguably ‘craft’ skill of static website development alive serves to resist this.

However, just on a practical level, finding myself wanting to reuse bits of code from certain projects, and then going through the process of searching through fairly tangled .js and .html files to find them, and then stripping them of the particular styling and parameters unique to the conceptual context they were developed for, was unnecessarily time consuming.

I used Vue.js, a frontend JavaScript framework with which I was already fairly experienced, which allowed me to organise sound sources and effects into self-contained ‘component’ files. I opted to use TypeScript over plain JavaScript, as I find this forces me to write neater and more effectively ‘self-commenting’ functions. In general, I’ve made the effort to organise the code in the most logical, neat, and documented way I could. Beyond just a tool, this codebase acts as the technical library for my practice, and as such I want to keep it as understandable as possible for my future self.

How It Works

Each containing just the HTML and JavaScript needed to implement that functionality, with minimal, plain, styling. When the tool runs, it serves a blank user interface through which ‘instances’ of each sound source can be added as many times as the user chooses, and to those instances, further instances of effect components can be added and applied. This UI allows me to quickly prototype and test combinations of functionality, making it helpful to figure out musical ideas before committing to the more ‘finished’ kind of tool design needed for a performance project.

Reflections

This project has served to remind me to not be dogmatic about the positions my critical technical practice puts forth. There are obvious drawbacks to writing static sites with repetitive tasks and complicated and text-heavy html files, in general a slower and more labour intensive process. To have the position, ‘professionalisation has made the web less interesting’ is not to fall into a nostalgia trap and advocate some kind of ‘return’ to old style web development practices for all applications. For the purposes of maintaining an organised codebase, one that I expect to grow indefinitely in complexity and size, a modern, component based framework makes sense. For the purposes of art, and of communicating a DIY approach, static web development makes sense because its drawbacks become aesthetic features.

In terms of this project's role in the practice I have developed, it serves as an interactive record of the kinds of sounds and musical gestures I want to explore further. The process of deciding what to ‘keep’ in Sandbox Tool has been one of reflecting on what my sound is and is not, and the process of using the UI has been very effective in prompting me to consider what could be missing from that sound.