edytlab
Audio Tools Reference

Recipes and Batch

Save an edit chain as a recipe, replay it on another recording, and run it over every file in a folder.

On this page3 tools
export_recipe

Write the session's edit chain — every tool and its parameters, in order — to a JSON file with no audio in it. Reviewable by eye before anyone runs it, and replayable against the same source or a different one.

Example prompt: export this edit chain so I can reuse it

Returns: path, steps, blockers

Steps that cannot be replayed (ML models) are marked in the file rather than silently dropped.

apply_recipe

Replay an exported edit chain. Every step is checked before any of them runs, so a recipe that cannot keep its promise is refused whole — naming the step — rather than half-applied. Takes an optional different source, and a dry run that reports the plan without touching the session.

Example prompt: run my podcast chain on this recording

Returns: steps_applied, head, notes

Replaying against the same audio reproduces the same bytes; the derived files are named by their own sample rate, channel count and samples, so a drifted rebuild is detected rather than substituted. Names from projects saved by earlier builds are still recognised when a project's history is rebuilt.

batch_apply

Run an exported edit chain across every audio file in a folder. Each file becomes its own project with its own history — a batch is not one giant session. Every file is attempted even if an earlier one fails, and the report says what succeeded, what refused, and why.

Example prompt: run my podcast chain over every file in this folder

Returns: files, succeeded, refused, per-file results

A chain that cannot be replayed is refused once, up front — that is a property of the chain, not of the twelve files. So is an output folder that would put a file's project where a project is open right now: each file's project goes in <output_dir>/<file name without its extension>, and a batch never writes into a project you have open, so choose another output_dir. So is a render that would land on one of the input files: output_dir defaults to the input folder, so with render_format set to the inputs' own format (wav for .wav files) each render would be written over its input. Your originals are never written over; choose another output_dir. Nothing is started in either case.