Pipeline Mechanism

The run request narrows what the pipeline’s source enumerates. The most specific selector wins: mediaUuids, then pathGlobs, then path.

From the command line these are --dir, --glob and --asset respectively:

A run in progress can be suspended and later resumed, or stopped for good:

A paused run keeps everything it has done. No further work is handed to workers, and the source scan stops as well, so a pause genuinely halts the pipeline rather than merely hiding it. Work already handed to a worker finishes normally. The run’s status becomes PAUSED, and its counters are preserved.

Cancelling is final: a cancelled run cannot be resumed.

A paused run continues to occupy a worker, so it should be resumed or cancelled rather than left indefinitely.

In the pipeline editor, a run that is currently executing offers a Pause control on the run banner and on its row in the run history; a paused run offers Resume in its place. Because a pause is reversible, Cancel stays available in both states. The controls also follow the run itself: if a run is paused from the command line or from another browser window, every open editor updates on its own.

From the command line:

Counters tell you how much a node did, not what it did. For that, open a run from the run history and pick one of the files it processed. The editor then shows, on each node, the values that node emitted for that file — one line per output, labelled with the output’s name.

Above, one video clip has been carried through the graph. The source reports the file it found, the hash node its digest, the thumbnail node the contact sheet it wrote and a DONE flag, and face detection ten faces with the first of them summarised. That is four nodes' worth of "what did you actually do", on the graph, for one specific file.

Results are always tied to one file. "What did the transcription node produce" has no answer until you say for which piece of media, which is why choosing an item is the first step. The chosen file stays named in the toolbar and the results stay on the graph when you close the run panel, so you can study the pipeline with them in place. Clear them with the × on that chip.

Selecting a node opens its Results tab, which adds what the compact view leaves out: how long the node took, how many attempts it needed, whether it was given up on after repeated failures, and the error if it failed. Outputs are kept even for a failed or skipped run of a node — they are usually what explains why it did not finish.

A node that processes several things from one file — one entry per detected face, say — is listed once per entry, so you can tell which one failed rather than only that something did.

Media that a node creates — a thumbnail, a cropped face, a generated image — is written to the machine that produced it, not to Loom. To let you actually look at it, a run started with Debug on asks each worker to send back a small picture of what it made, which then appears inline next to that output.

Previews are small on purpose: at most 512 pixels on the longest edge, and dropped entirely if they would still be too large. When that happens the output says so rather than appearing empty — "too large to preview" and "this output produced nothing" are very different answers, and the editor never confuses them.

They are also generated only for runs you started with Debug on, and are discarded together with the run they belong to. A preview is a debugging aid, not a copy of your media: it is deliberately lossy, and it is not a way to store or serve what a pipeline produces.

Audio and video outputs are still shown as file references — only images are previewed today, which is why the clip itself appears as a path while everything made from it appears as a picture.

Clicking any output on a node opens it full size. What you get depends on what the output actually holds, not on what it is nominally typed as:

The most informative view opens first, so you rarely have to choose. Use Raw when you want to see precisely what a downstream node will receive, with nothing interpreted for you.

The table above is not a generic rendering of the detection list: face detection wrote it, which is why it has a confidence column and a box column rather than a row of unlabelled numbers. Any node can describe its own output this way, and when one does, its description is what opens first.

Pausing stops the whole run. Often what you want is narrower: let everything run normally, but stop here, at this one node, and show me what it produced before anything downstream touches it.

In Debug Mode every node grows a small dot in its left margin. Click it to halt there. The dot is a setting on the run in front of you — it is never saved into the pipeline, so nobody else’s runs are affected and the next person to open the pipeline sees it exactly as you left it.

When a file reaches a halted node, the node still runs. That is the point: stopping before it ran would leave you with nothing to look at. What stops is everything after it. The node is ringed in amber, its results open automatically, and the run waits.

Two controls appear once something is waiting:

Step lets a single file through. Whatever it unblocks runs immediately, and if the next node is also halted, the run stops again there. This is how you walk one file through the graph a node at a time and watch what each one does to it.

Continue releases everything waiting. The halt stays set, so the next file to arrive stops here too — that is what makes it a halt rather than a one-off. To stop halting altogether, click the dot again.

While a run is halted it also stops looking for new files, so a halt on a folder of 100 000 images does not enumerate all of them while you read the first result.

Stopping at a node answers what did it produce. The question that follows is almost always and what would it produce if I changed this — and answering it by editing the pipeline and starting a new run means waiting for everything before that node to happen all over again.

So while a node is waiting, its settings can be changed and the node run again over the same file. Select the halted node and its settings panel says it is waiting, with Re-execute underneath. Change a value, press it, and the node runs a second time over exactly the inputs it had the first time.

The face detector is the clearest example. It ignores faces turned further away from the camera than Max Face Angle, which defaults to 30°. On footage of two people talking to each other, that finds nothing at all — and "no faces here" and "faces I was told to ignore" look identical from the outside. Raise the angle to 90°, press Re-execute, and the same frame comes back with both faces found.

Each attempt is kept. Once a node has been run more than once an Attempt selector appears, and switching between attempts switches what the canvas and the results panel show — which is the whole point, since a value is only good or bad compared with the one before it.

A setting is checked before the node runs, against the range that node declares: asking a thumbnail node for 99 columns is refused immediately rather than becoming a failure to find in a log.

Only a node that is currently waiting can be re-executed. Once you press Step or Continue its result has gone downstream, and re-running it would mean unpicking everything that already used it.

By default a node run records nothing. The result comes back to you and the asset is left exactly as it was, which is what makes it safe to try something. If you want the outcome kept, ask for it — the result is then written to the asset’s processing history, marked as an ad-hoc result so it can never be confused with, or overwrite, what a scheduled pipeline produced.

Nodes that produce files — thumbnails, generated images, rendered audio — are not available as node runs. Those nodes write their output next to themselves on the worker, and Loom cannot yet fetch it, so you would be told the node succeeded and handed nothing. They remain available inside a normal pipeline, where the file is consumed by the next node on the same worker.

Running nodes this way is a separate permission from editing pipelines. An administrator can grant someone — or the assistant — the ability to design pipelines without the ability to spend processing time, or the other way round.