Local Auto and optional AI: what actually happens to your track
“Automatic” and “AI” can hide very different processes. In VOID, it is useful to separate the local audio engine from the optional service that suggests a direction.
The local path comes first
Local Auto runs in the browser. It uses measurements and bounded processing rules to create a starting chain, render it and check the result. It does not need a text prompt, an external service or a model listening to your recording. Ordinary local analysis and exports stay on the device.
This path grew out of VOID’s original browser-local design. It gives the studio a usable starting point even when an external recommendation service is unavailable. “Local Auto” describes how that starting point is produced; it is not a promise that every track needs those changes.
What optional AI adds
In the documented development setup, a configured administrator can explicitly consent to a measurement-guided recommendation request. The service receives the disclosed measurements and context, such as a sound direction and supported genre or recording-date fields. The audio recording itself is not sent through that recommendation path.
Measurements can summarize aspects of the signal. They cannot reproduce everything a person hears in a performance. A suggested tonal direction is therefore an interpretation of numbers and intent, not confirmation that a specific instrument has a fault. The model has not listened to the recording.
What happens after a suggestion
The returned settings are validated before they become a processing chain. The browser performs the audio work and checks the result locally. In the listening-first workflow, intensity and tone refinements can reuse the chosen direction. Requesting a fresh AI direction is an explicit Advanced action.
Manual choices remain important. The development workflow protects a user’s later manual edits from an older recommendation arriving late. This is an interaction rule with a clear purpose: if you have already made a new decision, an earlier request should not silently take control back.
When the service cannot help
The studio reports a provider failure and falls back to local Auto without a paid retry. The screenshot shows a development fixture that deliberately exercises that failure path. It is a test of what the interface does when a request fails, not an account of a customer’s service usage.
If you see a fallback notice, read it before assuming that the visible result came from AI. You can continue listening to the local result and editing the chain. A working local path is useful precisely because an external request is not guaranteed to succeed.
Questions to ask before accepting a direction
Was the change actually useful at matched loudness? Does it still suit the quiet section as well as the loud section? Can you explain what you prefer? Those questions matter whether the settings came from a person, a deterministic rule or a model.
Use the comparison method to make that judgement. Then use the final-file checks before sharing the result. The studio remains a place to make and hear decisions; the source of the initial suggestion does not remove that responsibility.