yovoice: local text to speech, voice cloning and music on a desktop

The local-first claim is enforced by the model table, not by a setting

yovoice is described as an open-source local-first audio and music creation studio for macOS and Windows, and the central promise is that everything runs 100% locally with zero cloud API calls and zero per-character fees. The privacy claim is stated concretely: it runs entirely on the local GPU or CPU, and manuscripts, reference voices and creations never leave the computer.

What makes that more than marketing is the shipped model list, which is specific about what each model costs in VRAM and disk. The hardware table splits into three tiers. Kokoro-82M is the lightweight option at any CPU with 4 GB or more of RAM, shipping as a 189 MB Q8 file with millisecond latency. VoxCPM2, IndexTTS 2.0 and 2.5 and Qwen3-TTS sit in the high-fidelity cloning tier, needing 4 GB to 6 GB of VRAM or 8 GB or more on Apple Silicon. Full song and music generation with ACE-Step 1.5 Turbo and YuE2 3B is the demanding tier at 12 GB or more of VRAM, or 16 GB or more on Apple Silicon, with ACE-Step alone listed at 10.09 GB in BF16.

So the offline promise is real, and it comes with a hardware invoice attached. The model table lists parameter counts and file sizes per precision, with entries such as IndexTTS 2.0 at 3.63 GB in Q8 and 8.08 GB in the original precision, and OmniVoice at 0.6B parameters with a 1.35 GB Q8 file. The precision choice is a direct trade between disk and fidelity, and the documentation is clear enough that you can size a machine before downloading anything.

One legal detail sits in that table and is easy to skim past. The documentation states that OmniVoice under CC-BY-NC and Breeze TTS 2 under the BreezeBlue Research and Non-Commercial License have weights restricted to non-commercial use, even though the application itself is Apache-2.0. The app licence and the model licences are two separate questions.

audio.cpp is the reason there is no Python environment

The performance story is built on a single dependency. The documentation says yovoice is powered by audio.cpp at version 0.9.1, that it ships with bundled Windows CUDA 12.4 and 13.3 runtimes and native macOS Metal support, and that the point is double-click and create with no Conda and no PyTorch conflicts.

That is a meaningful architectural decision for an application whose whole point is running neural models locally. The mainstream local inference stacks for speech and music are Python, and they come with an environment manager, a CUDA version matrix and a set of package conflicts. By putting the inference engine behind a native C++ library, yovoice ships a binary with the runtime linked in, and the user never sees a virtual environment.

The Go module confirms the shape. The module is named yovoice and requires Go 1.26.0, with a very small direct dependency list: the Model Context Protocol Go SDK at 1.8.0, a pure Go MIDI synthesis library called go-meltysynth, golang.org/x/sys, and modernc.org/sqlite, which is a CGo-free SQLite implementation.

The MIDI library is worth a second look because it explains the score feature. The Score mode writes parts bar by bar, imports MIDI or lets an agent write the score, then renders it with a General MIDI sound font and a role-based mix, with results that are exactly repeatable and export to MIDI and stems. A software General MIDI renderer inside the same binary is what makes a score reproducible, since it does not depend on a platform sound bank. The modernc.org/sqlite dependency points to the local project and history storage, and the go-meltysynth dependency is what turns MIDI notes into audio without a separate synthesizer.

Three ways in: the app, the CLI and the agent

The project has three entry points, and the repository layout separates them cleanly with a cmd directory, a desktop directory, a web directory, a skills directory and a docs directory.

The desktop application is the primary path, published for macOS 14 or later on Apple Silicon and for Windows 10 or 11 on x64, and the documentation says to choose the package for your platform from the repository Releases tab or from the project website. The build scripts in the Makefile confirm the two supported desktop targets, with a macOS packaging script and a PowerShell script for Windows, and the Windows path produces yovoice.exe under an artifacts directory.

The CLI is a separate build that the Makefile describes as needing no front end and no desktop app, and it also builds ffmpeg into a tools directory as part of the process. The documentation points to docs/cli.md for the command line and agent skill, and to docs/api.md for API and MCP deployment, which is where the headless usage is covered.

The third path is the integration story, and it is the most distinctive part of the project. The documentation describes connecting DeepSeek, Qwen, Claude, OpenAI or a local Ollama instance so that an AI writes arrangements and lyrics, and it states that the keys stay on the computer. It also ships a native Model Context Protocol server for Cursor and Claude Code, and an agent skill for asking an agent to set up local speech generation and build voiceovers from text and reference audio.

The MCP server is why the Go SDK is a direct dependency. An agent calling local tools to generate a voiceover is a different use case from a person clicking through a desktop app, and the CLI plus MCP path is what makes yovoice usable from a terminal or a coding session.

The AI service is described as optional, and that is a useful design point. The speech, music and score generation all run locally; only the lyric and arrangement writing needs a language model, and that model can be a local Ollama instance if you want to keep even that on the machine.

The three audio paths are different models with different jobs

The feature list describes more than one product, and it helps to separate them.

The voice and expression path lets you use a reference voice, match a reference performance, adjust emotions, or describe the delivery in words. That last option, describing the delivery in natural language rather than picking a preset, is the part that distinguishes this from a menu of voice styles.

The voice design and cloning path is where VoxCPM2 appears, described as offering text-guided voice design, controllable cloning and transcript-assisted cloning with automatic multilingual handling, at 48 kHz output. Text-guided voice design means you can describe a voice that does not exist yet and get one, which is different from cloning a voice that exists.

The music generation path is described as ACE-Step 1.5, where you describe a style, write lyrics with section markers, and generate full songs or instrumentals. Every take is kept as a version so you can compare them, and the documentation calls out 50 or more vocal languages. Two models in the table are restricted to non-commercial use, and Breeze TTS 2 additionally requires the v0.9.1 engine.

The model table also shows a range of granularity in the same family. Qwen3-TTS appears in four variants: a Base model at 0.6B and one at 1.7B, a CustomVoice variant with 9 built-in voices, and a VoiceDesign variant that needs no reference audio. Kokoro appears in three builds, and the difference is not just size: Kokoro-82M 1.0 Official has 49 built-in voices and excludes Japanese, while the 1.0 build has 54 voices with full multilingual resources including Japanese but is import only, and the 1.1-zh build has 100 Chinese and 3 English voices, marked experimental and import only.

The practical consequence is that model selection is a workflow decision, not just a size decision. Some variants you can only import rather than download through the app, and the documentation points to a model selection page for the input requirements of each.

Building from source needs Go, pnpm and a make target

The build system is a Makefile driving a Go core and a pnpm managed web front end, with the front end living in the web directory and the Go code in cmd and internal.

The front end is installed with a frozen lockfile, so the dependency versions are pinned rather than resolved on the fly:

$(PNPM) --dir web install --frozen-lockfile

The development preview and the production build are two more targets in the same style:

$(PNPM) --dir web run dev

$(PNPM) --dir web run build

The check target is the interesting one, because it separates the two halves. check-web runs the front end static checks, builds the front end and runs the browser tests, while check-core runs the Go side: a gofmt check over cmd and internal, go vet, and the test suite with the race detector enabled. The race detector in a build that mixes a native inference library with Go goroutines and a SQLite store is a sensible choice.

The desktop and CLI targets are separate from the web ones. On Windows the app targets chain to the Windows script and the packaging step invokes the PowerShell build script with a Package flag, while on other systems they chain to the macOS script. The CLI target builds ffmpeg into a tools directory and then compiles the Go entry point to an artifacts path, with a .exe suffix added on Windows.

The top level listing also holds a CHANGELOG.md, an AGENTS.md, a THIRD_PARTY_NOTICES.md, a skills directory and a docs directory, so the project carries the paperwork of a project that expects third-party code and agent instructions to be part of the deal.

Where yovoice is the wrong choice

Three situations rule it out, and the first one is hardware.

If your machine has a modest GPU, the features you care about may simply be unavailable. The documented table puts voice cloning at 4 GB to 6 GB of VRAM and full song generation at 12 GB or more, with ACE-Step 1.5 Turbo alone needing 10.09 GB of model file. On a machine that cannot meet those numbers, the practical outcome is a long download of weights that then fail to run, and the only comfortable option is the lightweight Kokoro path with its 189 MB file, which gives you 49 built-in voices and no cloning. The download sizes are large enough that disk planning matters as much as VRAM planning, since several of the model variants are 3 GB to 8 GB each and the documentation lists them in multiple precisions.

The second is Linux. The platform badges cover macOS 14 or later on Apple Silicon and Windows 10 or 11 on x64, and the build scripts in the Makefile are a macOS shell script and a Windows PowerShell script with no Linux target among them. The backend is Go and would in principle build anywhere, but the packaged application does not cover Linux.

The third is a licensing requirement. The application is Apache-2.0, which is permissive and lets an organisation do almost what it wants with the code, but two of the shipped model weights are restricted to non-commercial use, and a commercial project that plans to clone voices with OmniVoice or Breeze TTS 2 has a separate problem that the application licence does not solve.

There is also a scope limit worth stating plainly. The tool creates speech, cloned voices, songs and MIDI scores. It is not a DAW. There is no multitrack mixing of recorded audio, no audio editing timeline in the professional sense, and the multi-track part of the product is the score renderer rather than a session that combines separately recorded takes.

MCP support and an agent skill are the actual differentiators

If the desktop application is a familiar proposition, the MCP server and the agent skill are not. Most local AI audio tools are applications you operate. This one is designed to be operated by an agent.

The documentation says the MCP and agent ecosystem lets you connect DeepSeek, Qwen, Claude, OpenAI or a local Ollama instance to write scores and lyrics in seconds, and that a native Model Context Protocol server is included for Cursor and Claude Code. Combined with the CLI, this means a coding agent can be told to set up local speech generation and produce a voiceover from a text file and a reference audio clip, and the work happens on the local machine rather than on a vendor's servers.

That is a different procurement conversation from the one you would have with a cloud speech API. The argument is not only the per-character fee, which the documentation describes as zero recurring fees against per-character and per-minute meters. The argument is that the reference audio never leaves. For a voice actor's own voice, for a client recording, for anything under a non-disclosure agreement, the fact that the audio stays on the disk is the reason to use this rather than a hosted service.

The Go module confirms the MCP part is a first-class dependency rather than a plugin bolted on later, with the Model Context Protocol Go SDK at 1.8.0 as a direct requirement, and the repository carries a skills directory alongside the docs.

The release record shows how young this is. The tags are v0.2.0 on 2026-10-12, v0.1.7 on 2026-10-05 and v0.1.6 on 2026-10-01, so three releases in a fortnight and a version number still in the 0.x range, with the last push on 2026-10-18. The engine version is pinned at audio.cpp 0.9.1 in the documentation, and two models in the table require exactly that engine version, which is the kind of coupling that shifts as the project moves.

Editorial conclusion

yovoice fits a creator or a studio that cannot send reference voices and manuscripts to a cloud vendor, and an engineering team that wants an MCP server to drive local voice generation from an agent. It is the wrong choice if you have a small GPU, since the documented hardware table puts full song generation at 12 GB of VRAM and voice cloning at 4 GB, and it is the wrong choice for a Linux user, since the badges and the build scripts cover macOS and Windows only. Before adopting it, check the VRAM and disk headroom against the model you intend to run, read the two weight licence restrictions on OmniVoice and Breeze TTS 2, and note that the version line is still 0.2.0, so expect the interface and the model list to keep moving.

Frequently asked questions

Official sources

1. leemysw/yovoice on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases