Chain, Phrase, Grid
Notes on Live Coding
For an assignment during my Decoding tendencies in Live coding workshop we were asked to pick a live coding environment and analyze it using the Cognitive Dimensions of Notations framework, or CDs. Developed by Thomas Green and Marian Petre, CDs is a tool for evaluating how well a notational system supports the activities it is designed for. Rather than ranking systems as good or bad, it gives you a shared vocabulary to describe specific tradeoffs. Dimensions like viscosity (resistance to change), role-expressiveness (how easily you can infer the purpose of something), provisionality (how freely you can sketch or experiment without committing), and visibility (how accessible information is at a glance) each describe a different axis along which a notation can succeed or struggle. No dimension is inherently good or bad on its own; the evaluation always depends on what you are trying to do.
I ended up going beyond the single-environment requirement because I wanted to compare a few tools I had been spending time with. The three are Hydra, Mercury, and ORCA, which cover visual synthesis, algorithmic music, and grid-based sequencing respectively. Mercury ended up being more of a quick detour than a serious commitment; Hydra and ORCA are the ones I kept coming back to, but the comparison across all three turned out to be useful.
Hydra
System Overview
Hydra is a browser-based live coding environment for real-time video synthesis, created by Olivia Jack. It runs entirely in the browser with no installation required and compiles to WebGL under the hood. The syntax is modeled on analog modular synthesis: you build visuals by chaining or patching transformations together, which means the notation maps closely to the way signal chains work in hardware.
Notational System Components
Interaction Language / Notation
The notation is JavaScript-based and chain-oriented. Functions are called in sequence on a source, each one transforming the output of the last, which gives the language strong closeness of mapping to its domain. If you understand signal flow in a modular context, the structure of a Hydra patch reads almost intuitively. Role-expressiveness is reasonably high; the function names (osc, noise, kaleid, modulateScale, etc.) describe what they do clearly enough that even an unfamiliar patch is navigable. Because the underlying language is JavaScript, the abstraction ceiling is very high: you can introduce variables, functions, arrays, and arrow functions to generate complex behaviors, but this also means the error surface is wide and mistakes can be subtle.
Editing Environment
The editor sits directly on top of the output, which creates an interesting visibility tradeoff: the code is always visible alongside the visual result, but the output is also always active, meaning there is no clean separation between editing state and running state. Provisionality is limited since changes evaluate immediately and there is no staging or preview mode. Viscosity is relatively low for iterative tweaking but can become high when restructuring a long chain, since the entire line needs to be rewritten rather than individual nodes adjusted.
Medium
Purely visual, with optional audio reactivity via the built-in FFT analysis tools that let audio input modulate visual parameters.
Subdevices
The browser-based editor includes a toolbar with example sketches and a reference panel, both functioning as helper devices. The ability to pull in external JavaScript libraries (P5.js, Tone.js, Three.js) acts as an extension mechanism and functions similarly to a redefinition device, allowing the notation itself to be expanded. My own Hydra-to-TouchDesigner integration project was essentially an attempt to graft Hydra’s notation onto a different environment, treating its syntax as a portable abstraction layer.
Worth noting is that Hydra supports a performance-oriented workflow where the code is hidden from the output entirely. You can do this two ways: using Flok (a collaborative browser-based editor) where you open two tabs of the same session and hide the code on one while coding on the other, or by running Hydra directly in the browser’s dev tools console so the editor never appears over the visuals at all. In CDs terms this is a secondary notation use case, where the performer has chosen to suppress part of the visible notation for audience-facing reasons rather than functional ones.
Mercury
System Overview
Mercury is a free, open source, browser-based live coding environment designed for algorithmic music performance. Like Hydra, it requires no installation and runs directly in the browser. Its syntax is intentionally human-readable, prioritizing accessibility for both the performer and the audience.
Notational System Components
Interaction Language / Notation
The notation is human-readable, which I find immediately appealing. At a glance I can parse what is happening without needing to decode cryptic syntax. Functions use clear descriptive names and a consistent sentence-like structure, which gives the language high role-expressiveness. The intent behind each line is easy to infer, even mid-performance.
Editing Environment
The environment offers on-screen controls to help you get oriented, which can be hidden once you no longer need them. One thing I discovered through the Mercury Discord is that there are actually two ways to trigger Hydra code within Mercury: you can fire snippets based on instrument triggers, in addition to writing in the main code block at the bottom. One significant caveat is that stopping the playhead clears all Hydra code in that block, which is a real limitation. In CDs terms this is a high-viscosity situation: a single action (stopping playback) causes a cascade of loss that requires substantial work to restore.
Medium
Primarily auditory with visual display support.
Subdevices
Tutorials load quickly from within the environment and function as helper devices, giving you working examples to learn from without leaving the interface. The sample pre-listen feature is also a helper device since it lets you audition sounds before committing them to your code. Error handling is worth noting as well: errors display below the editor and execution continues rather than stopping, which lowers the cost of mistakes and keeps performance viable even when something breaks.
ORCA
System Overview
ORCA is a two-dimensional esoteric programming language and live coding environment where every letter of the alphabet functions as an operator. It does not generate sound itself but sends MIDI, OSC, and UDP to external audio tools like Ableton, VCV Rack, or SuperCollider. The grid is both the notation and the execution environment simultaneously.
Notational System Components
Interaction Language / Notation
The notation is a 2D character grid where uppercase letters execute every frame and lowercase letters execute only on a bang. Every operator is a single character, which makes the notation extremely dense but also surprisingly readable once you internalize the alphabet. This is a very different legibility from Mercury. Where Mercury reads more like natural language, ORCA reads like a schematic or a circuit diagram. Role-expressiveness is lower initially but increases fast with familiarity. The base 36 system (0-9 then A-Z) extends numeric logic into letters, which is elegant but adds a layer of mental translation.
Editing Environment
The environment is a plain grid with no syntax highlighting or visual scaffolding. Viscosity is interestingly low for spatial rearrangement (you can move operators anywhere on the grid freely) but can be high for certain changes where a chain of dependent operators needs to be restructured, which maps to knock-on viscosity from the readings. There is no undo buffer in most versions, which is a significant constraint on provisionality.
Medium
Primarily visual (the grid) with auditory output routed through an external synth or DAW via MIDI. Because ORCA itself is silent, there is a gap between where you work and where you hear results. You are looking at a grid of operators but the sound is coming from a completely separate application. This affects closeness of mapping in a way the other two environments do not have to contend with: in Mercury and Hydra, cause and effect are in the same place. In ORCA they are not.
Subdevices
The operator reference itself functions as a helper device, essentially a lookup table you internalize over time. The zine that Hundred Rabbits distributes at workshops is a physical helper device, which is interesting to note in the CDs framework context. For platform-specific versions (Norns, browser, terminal, VCVrack), each version has slightly different special operators, meaning the notation is not fully stable across environments. The MIDI and OSC output layer is effectively a redefinition device since it translates ORCA’s internal state into commands for external systems.
Analyzing them side by side through the CDs framework helped me understand why Hydra and ORCA feel so different to work in. Hydra keeps everything in one place: you write, you see, you adjust. The loop is tight. ORCA demands that you build a whole separate context around it before it makes any sound at all, which is either a feature or a barrier depending on what you are trying to do.
What the course pushed me to think about more carefully is how much of a live coding performance is shaped by the notation itself, not just the performer’s decisions. The constraints are already there before you start.
Further Reading and Artists to Watch
If any of these tools caught your attention, here are some artists worth looking up and resources worth bookmarking.
Hydra is where to start for browser-based visual synthesis. Data_V is doing interesting work in the space and is worth following. If you want to go deeper on running Hydra inside TouchDesigner, I wrote about my own integration project here.
Mercury was built by Timo Hoogland, who posts regularly about the project at @tmhglnd and is a good person to follow if algorithmic music performance is your thing.
ORCA has a small but dedicated community. Femi Shonuga-Fleming (@sadnoise_) is a Brooklyn-based sound artist who has performed with ORCA live and is worth watching. The YouTube demo linked here is also a good entry point if you want to see it in action before committing to installing anything.
In a way there are many different flavors of livecoding now (Tidal, Strudel, Mondo, Mercury, Sonic Pi) that all can achieve very similar goals with very different syntatical sugar.
Mercury feels a lot like Mondo (which is a DSL-like Strudel) that allows for space-delimited declarations, including implicit callbacks without needing to specify callback params.