Hydra: Livecoding Networked Visuals in the Browser

What Hydra Actually Solves for Livecoders

The problem Hydra addresses is routing and mixing video in realtime while you are writing the code that produces it. A VJ working with a conventional node-graph tool manipulates patches with a mouse; a programmer working with a shader framework gets speed but has to rebuild the pipeline for every change. Hydra splits the difference by making the patch itself a JavaScript expression chain. You type osc(20, 0.1, 0.8).out(), and the oscillator appears.

The audience is narrow and specific. This is for people who already think in functions and are willing to accept a browser as their runtime. The README is explicit that the project is "experimental/in development" and that it "only works on Chrome or Chromium, on machines with WebGL." That is not a marketing hedge, it is a deployment constraint: your performance machine has to be a Chromium browser with hardware acceleration enabled.

The repository is the online editor, not the engine. The README lists hydra-synth as the synth engine published separately as an npm module, atom-hydra for use inside Atom, and rtc-patch-bay as the standalone networking logic. If you want Hydra's rendering without its editor, those are the pieces to look at, and the package.json confirms the editor depends on hydra-synth at version ^1.3.27.

The Framebuffer and Function-Chain Model

Hydra's architecture is a set of named buffers plus a chain of transformations applied to whatever texture you feed in. The README states that the environment contains four output buffers, accessed as o0, o1, o2, and o3, and that out() with no argument renders to o0. A call to render() with no argument shows all buffers at once; render(o1) shows one.

Sources are separate from outputs. The s0 source buffer holds an external texture: a webcam via s0.initCam(), a video file via s0.initVideo(url), an image via s0.initImage(url), or a screen tab via s0.initScreen(). src(s0) then converts that buffer into something chainable.

Compositing is arithmetic. The README describes blend(), diff(), mult(), and add() as operations that combine the input texture color with the base texture color, and compares them to Photoshop blend modes. A separate function, modulate(texture, amount), uses the red and green channels of the input texture to displace the x and y coordinates of the base texture. That is the mechanism behind most of the feedback-looking visuals people associate with Hydra: one buffer's color channels are steering another buffer's sampling coordinates.

Every parameter can be a function rather than a constant. The README gives osc(function(){return 100 * Math.sin(time * 0.1)}).out() as the example, with time defined as milliseconds since page load. This is what makes the environment feel like an instrument rather than a renderer.

Installing and Running Hydra Locally

The README's own getting-started instruction is to go to https://hydra.ojack.xyz, and for most users that is the whole install. The repository is the source of that site, and package.json shows a Vite dev server for running it locally.

Clone the repository, then install dependencies and start the dev server:

npm install
npm run dev

The dev script is "vite . --host", so the server binds to your network interfaces as well as localhost. The production build is separate:

npm run build

That runs vite build and emits into dist/, which the repository already tracks as a top-level directory. The publish script pushes that directory to a gh-pages branch via git subtree, which tells you how the hosted site is deployed.

Once the page is loaded, the README documents the keyboard bindings: CTRL-Enter runs a line of code, CTRL-Shift-Enter runs everything on screen, ALT-Enter runs a block, CTRL-Shift-H toggles the code panel, and CTRL-Shift-F formats with Prettier. A first real use is the webcam kaleidoscope the README gives:

s0.initCam() // initialize a webcam in source buffer s0
src(s0).kaleid(4).out() // render the webcam to a kaleidoscope

The browser will ask for camera permission; if more than one camera is attached, s0.initCam(1) selects by index. The same code can be typed into the browser console instead of the editor, which the README notes as an option.

Sharing Streams Between Windows with WebRTC

Hydra's networking is peer-to-peer video between browser windows, not a server-side compositor. The README states that any Hydra instance can use other instances as input sources as long as they are connected to the internet and not blocked by a firewall, and that the underlying transport is WebRTC, with rtc-patch-bay managing connections.

The handshake is two lines. In the window that will act as the source, you name the patch bay:

pb.setName("myGraphics")

The README says the window title changes to the name you set, which is your only visual confirmation that the naming worked. In the second window you pull that name in as a source:

s0.initStream("myGraphics")
src(s0).out()

The README warns that connections sometimes take a few seconds to establish and that progress is visible only in the browser console. It also documents pb.list() for enumerating available sources from the console. That console-only feedback is a real usability gap: there is no on-screen connection indicator described in the README, so a performer troubleshooting a dropped peer has to have devtools open, which is not something you want to be doing mid-set.

Where Hydra Is the Wrong Tool

The browser-only constraint is the first and largest limitation. The README says Hydra works only on Chrome or Chromium on machines with WebGL. There is no documented headless mode, no offline renderer, and no way to export a deterministic frame sequence from the editor. If your workflow requires rendering the same output twice, or rendering faster than realtime for a video file, Hydra as described does not do it.

The second limitation is API stability. The README calls the project experimental and in development. The package.json version is 1.5.3 for the editor, but the package has no test suite: the test script is literally echo "Error: no test specified" && exit 1. That means there is no automated check that a code snippet from a tutorial still runs after a release. If you build a performance around a specific chain of functions, you are relying on the maintainers not changing behavior, and nothing in the repository enforces that.

The third is the network dependency. Remote streams require internet connectivity and an unblocked path between peers. On a venue network with client isolation or an aggressive firewall, the WebRTC connection will not form, and the README does not document a fallback or a relay. For a solo performance using only local sources, this does not matter; for a collaboration across two machines on venue wifi, it is the thing most likely to fail.

Hydra Against p5.js in the Same Editor

The most useful comparison is the one the README itself makes, because Hydra hosts p5.js inside its own environment. The README shows instantiating a p5 instance with p5 = new P5(), then calling p5.rect(300, 100, 100, 100), and notes that p5 runs in instance mode so every function must be prefixed with the variable.

The difference in approach is what each one asks you to write. p5.js is an immediate-mode drawing API: you describe shapes, positions, and colors, and you manage the draw loop. Hydra is a texture pipeline: you describe sources and transformations, and the framebuffer graph does the compositing. If your visual is a composition of geometric primitives, p5 is the shorter path. If your visual is feedback, displacement, and layered video, Hydra's modulate and the blend functions get you there in one line where p5 would need you to write the pixel manipulation yourself.

Running p5 inside Hydra means you can mix both: draw a rectangle with p5 and route it through Hydra's chain. The cost is that you now depend on two systems' quirks in one sketch, and the README's p5 section is short enough that the interaction between the two is not documented in detail.

Licence and Maintenance Cost

Hydra is AGPL-3.0. The repository LICENSE file and the package.json license field (listed simply as "AGPL") both point that way. For a livecoder running sketches at a show, this is unlikely to matter. For anyone embedding Hydra's engine into a product or a hosted service, the AGPL's network-copyleft terms are the thing to read before you build, and that is a question for a lawyer rather than for this article.

The maintenance picture is mixed. The repository is not archived, and the last push was on 2026-04-25, which is recent enough that the project is not dormant. But the README still describes the project as experimental and in development, and the package.json test script is a placeholder that exits with an error. There is a CHANGELOG.md at the top level, so release history is tracked.

Upgrade cost is low in one direction and high in another. Because the editor is deployed as static files to gh-pages and loads hydra-synth as a dependency, updating is a matter of pulling and rebuilding. But because there are no tests, an upgrade that changes a function's behavior will not be caught until a sketch breaks on stage. Pinning your hydra-synth version and keeping a known-good build of dist/ is the practical hedge.

Editorial conclusion

Adopt Hydra if you perform or teach live visuals and are comfortable typing JavaScript into an editor that re-evaluates on CTRL-Enter, and if your audience machines can be assumed to run Chrome or Chromium with WebGL. Do not adopt it if you need a headless renderer, a stable API surface, or support for browsers outside the Chromium family, since the README states it is experimental and currently limited to Chrome or Chromium on machines with WebGL. Before committing to it for a performance, verify two things in your own environment: that the WebGL context survives the length of your set, and that pb.setName and s0.initStream connect between your two windows, because the README notes the connection sometimes takes a few seconds and progress is only visible in the browser console.

Frequently asked questions

Official sources

1. hydra-synth/hydra on GitHub
2. Issues
3. License: AGPL-3.0
4. Project website
5. README