Hydra: feedback with an exit

Begin with a source you can recognise

Hydra is Olivia Jack’s browser-based video synthesizer, with a JavaScript interface that compiles visual operations to WebGL. Its official documentation presents feedback as one of the practices the system supports. Start with the current learning material and a simple generated source before introducing cameras, network feeds or several output buffers.

Choose a shape or pattern with a clearly recognisable edge. Watch it without feedback first. Establish what its scale, movement and colour are doing so you can distinguish those properties from changes introduced by recirculation. Save this minimal patch as a reference you can return to during performance.

Think of feedback as an agreement about what survives from an earlier image. A transformation applied inside that return path can accumulate, so a small adjustment may become significant over time. The useful control is not only how dramatic the first frame looks, but how the image evolves after you stop touching anything.

Change one part of the memory

Add a feedback route using the official examples for your Hydra version. Begin with a restrained return and only one transformation. Choose scale or rotation, not both. Let the image run long enough to expose its tendency. Does detail settle, grow, blur or disappear? Record the observation before changing another value.

Create three labelled versions: a clear source, a slowly accumulating state and a clearing state. Keep their code nearby rather than relying on memory during a live session. The clearing state should have an obvious result. An exit that depends on locating an obscure number in a dense chain is not yet a performance control.

Now add a small contribution from fresh source material while the feedback continues. Watch the balance between renewal and persistence. Too much new information can conceal the memory; too little can let the image settle into an uninteresting state. Neither balance is universally correct. Choose it according to the duration and density of the accompanying music.

Try a short phrase of changes rather than continuous improvisation: introduce the source, let it accumulate, briefly disturb it, then clear it. Repeat the phrase with the same values. If the result differs, consider what initial state or timing was different. Feedback is easier to play when its state is part of the score.

Make live coding readable to yourself

Keep the active patch compact enough that you can identify the source, transformation and return path quickly. Save complete working versions instead of only isolated fragments. A line that looks useful out of context may rely on a buffer or variable established earlier in the session.

If you connect sound analysis, add it to one bounded parameter first. Let a quiet passage and a dense passage both pass through the mapping. Avoid assigning every fluctuation to a large visual change. A slowly evolving feedback image may need occasional musical steering rather than a literal response to every transient.

Rehearse on the intended browser and output resolution. A patch that looks responsive in a small preview can behave differently on a large display. Keep a simple source-only version available as a fallback and make the transition to it part of the rehearsal.

Finish by watching a recording without editing the code. Identify one moment when the image remembers too much and one when it forgets too quickly. Those are precise compositional observations. Adjust the feedback relationship to address them. The aim is a visual instrument whose memory you can phrase, including the moment when you deliberately let it go.