The session ends. The revision notes still need sorting.
OGAD (Off Grid AI Desktop) can turn supplied recording-session notes into a draft revision checklist using a local model. Put the notes in a Project, ask for one change per row and check each item against its source. This workflow organises written feedback; it does not listen to a mix, edit audio or decide what the artist meant.
| Download OGAD | Desktop releases |
What would you like to do with Off Grid AI?
Have a feature or use case you would like us to support? Tell us what you want to do and which device you use.
Write to support@offgridmobileai.co, join our Slack community, or talk to us on Reddit.
What should a revision checklist contain?
A useful checklist tells you what to change, where the note applies and what still needs clarification. It should preserve the difference between an agreed change and an idea someone suggested during the session.
For a small studio, that can reduce the work of rereading scattered notes before opening the project in your audio software. You still perform and review the actual audio work yourself.
| Checklist field | Why it helps |
|---|---|
| Track and version | Prevents applying a note to the wrong mix |
| Section or timestamp | Locates the part mentioned in the source |
| Requested change | Keeps each task specific |
| Speaker or requester | Shows who supplied the feedback |
| Status | Distinguishes agreed, proposed and unclear |
| Source | Lets you check the original wording |
A blank field is acceptable when the notes do not supply it. Filling it with a guess makes the checklist look more complete while making the work less reliable.
How should you prepare the notes?
Collect the written feedback you are authorised to use. Include the session date, track title and version name where you know them. Preserve timestamps exactly as written, including any uncertainty about the reference version.
If feedback comes from several sources, keep each source identifiable. A session note, a later artist message and an engineer’s own reminder can disagree. Putting them in one unlabelled paragraph makes that disagreement harder to see.
This guide uses text and supported documents that you supply. If you have only an audio recording, first create and review a transcript through an appropriate transcription workflow. A speech transcript is not a technical analysis of the music or proof that the model understood a mixing instruction.
How do you create the first checklist?
Use this setup for the recording project:
- Open Models > Text. Download and load a compatible local text model.
- Open Projects > New project, enter a clear name and press Enter.
- Open Knowledge & settings > Knowledge base > Add files. Select the supported notes and documents for this project.
- Wait for indexing to finish. Check the Knowledge base list and keep the intended files enabled for retrieval.
- If Include captured memory is available, turn it OFF and select Save. This keeps broader captured work out of this supplied-document workflow.
- Open Chats > New chat within the project and ask the first question.
The captured-memory control appears with Pro. In the core project workflow, that additional source option is not offered.
Try a small example before using a long set of notes:
Track: Night Bus, mix v3. Artist: make the lead vocal clearer in the second verse. Producer: try a shorter intro, but compare before deciding. Engineer: check the click near 01:42 in v3. Artist: keep the ending as it is.
Ask:
Turn these notes into a revision checklist. Use one row per item. Preserve the track, version, requester and exact location when supplied. Separate confirmed requests, experiments and checks. Include a source for each row. Do not invent audio settings.
The resulting list should treat the shorter intro as an experiment, the click as a check and the unchanged ending as a constraint. It should not convert every sentence into an instruction to alter the mix.
Why does the wording of the request matter?
A phrase such as “make the vocal clearer” does not specify the engineering method. The model should preserve that outcome rather than add a made-up EQ setting, compressor ratio or gain change.
Use the checklist to organise what needs attention, then apply your own judgement in the audio session. If the note is ambiguous, make the question explicit:
Does “clearer” refer to the vocal level, intelligibility or masking in the second verse?
You can ask that question before doing work that the artist did not request. The useful AI contribution is recognising that information is missing, not pretending it has heard the track.
How do you keep versions straight?
Include the reference version in both source notes and the checklist. If a later file changes the song structure, a timestamp from v3 may not point to the same event in v4.
Ask the model to flag notes whose version is missing. Do not ask it to remap timestamps across audio versions unless you have independently verified that mapping.
For example, a later message may say, “The click is gone, but keep the original intro.” Add that message as a dated source and ask which earlier items it updates. The answer should mark the click note as reported resolved and the intro experiment as rejected or superseded according to the wording.
“Reported resolved” still needs a listening check. A message about a fix is different from your own confirmation that the exported file contains it.
What should you check before starting revisions?
Read the original source for every item that affects the next export. Check whether the artist approved the change, asked for a comparison or simply raised a question.
| Possible mistake | How to catch it |
|---|---|
| A suggestion becomes a firm request | Compare the status with the exact wording |
| A note applies to the wrong version | Check the file name and session date |
| A timestamp appears without a source | Remove it or ask which reference it came from |
| A technical setting appears from nowhere | Keep the desired outcome; choose settings yourself |
| An unchanged section disappears from the list | Include “keep as is” constraints in the brief |
Give the final checklist a short manual edit. Combine true duplicates, but keep separate sources when they add conditions. A short, checked list is easier to use than a long list of loosely related suggestions.
Can you do this privately and offline?
Use a downloaded local model and locally prepared documents. Once those resources are ready, this text-organisation workflow can run without internet. It does not require a web search or uploading a mix to a model provider.
Projects is a core desktop capability. Background capture and meeting recording have separate Pro and platform requirements; they are not prerequisites for organising notes you already have. Desktop core and downloads.
If you add remote tools or sync the project to another device, review those data paths separately. Keep the source files within the setup you intend to use.
How do you carry the checklist into delivery?
Use the checked list alongside your audio project. As you work, note what you changed and which export contains it. Keep unresolved questions visible rather than quietly treating them as completed.
After the artist responds, save the feedback with the reviewed version name. The next session can then start from the current decision record instead of the entire message history.
Try OGAD with one session’s written notes. Generate the checklist, inspect its sources and take only the verified items into your next revision.