LOOM: When the Sound Does Not Match

LOOM built. It made sound. One patch still behaved differently.

That is an awkward kind of failure. The application is alive, the controls work, and the output is recognisably musical. Somewhere inside the system, a small behavioural difference is changing the result. Rewriting everything would destroy the clues. Guessing at a parameter might make one patch sound closer while making another worse.

LOOM began as a modular browser instrument: sound sources, granular processing, effects and sequencing connected into a playable patch. The later LOOM Works rack brought this family of instruments into a native C++ application. Its browser implementation supplied the reference; the native audio engine had to reproduce that behaviour within defined tolerances.

Give each uncertainty a useful question

The first investigation divided the problem into defaults, note routing, random seeds, timing and the tests themselves. Those were separate questions with different evidence to inspect. Workers could pursue them independently, while a combined experiment waited for the repairs it required. A final review had to bring the branches together.

That dependency matters. Asking several agents to look at a problem can produce several plausible stories. A work graph gives those stories somewhere to meet. It says which result is an input to another task, which component each worker can change, and where the explanation has to survive a combined test.

After the first repairs, the Glass patch remained outside tolerance. The investigation narrowed to the chorus, where a slow oscillator moves a delay time. One branch read the browser implementation. Another measured its behaviour with small probes. Controlled changes removed the chorus's influence and repeated the comparison.

The detail was a pause

In the recorded Chromium reference, disconnecting an upstream source could eventually disable the delay output after the remaining audio tail. The oscillator was consumed through the delay-time connection. Once that path stopped pulling it, its phase stopped advancing.

The native oscillator kept moving.

When processing resumed, the two versions occupied different points in the cycle. The effect could therefore sound different even when its visible settings matched. Ordinary silence did not explain the result: the relevant condition was the disabled output and the resulting interruption of processing.

This is why the source reading, the probes and the controls all mattered. The implementation suggested a mechanism. Measurement located the behaviour. Removing the chorus influence tested whether that mechanism was relevant to the failing patch.

A scratch native build then reproduced the browser rule. Glass passed the existing comparisons, while the other 66 host fixtures retained byte-identical native output in that experiment. That gave the repair a direction without changing the test thresholds to accommodate it.

An explanation has to become a repair

The successful experiment crossed several implementation boundaries. Connection state lived in the core engine; tail and disable behaviour involved the audio primitives; the modules had to respect the resulting processing state. The work reopened around those owners and returned through integration.

Further checks found a separate capture-width defect. That became another investigation. A result from one controlled experiment could settle its question without settling the entire application.

Loki's next feedback returned to playing the instrument: hide wires when they obstruct the view, move and organise modules, and keep the interface stable during playback. Those requests belonged in the same development run. Moving a module should change the arrangement on screen while preserving the musical patch.

Missing reference audio also had to be rebuilt from the preserved browser sources. The candidate implementation could not become the source of its own expected answers.

What the graph carried

The final recorded check reported 323 of 323 audio fixtures within the existing tolerances. Physical hardware and some delivery conditions remained to be exercised. This is an account of the native development work; the browser instrument remains separately available.

The useful unit of orchestration here was a question someone could answer. Each branch reduced a particular uncertainty. Their dependencies made the answer usable by the next worker. Review connected the findings, and the operator kept bringing the work back to the instrument people would actually play.

Explore LOOM on Those Dark Arts.

---

Author: Loki. Research and drafting support: Moiré, under Loki’s direction.