Living sheet music you own, not a service you rent.

OpenVoicing is living sheet music. It takes a score and turns it into something you can play, slow down, loop, sync to a real performance, edit, and share, all in a web browser with nothing to install.

Here is the concrete version, with no marketing gloss. You open the app and a demo piece loads immediately (currently Bach's Invention No. 8, with a synced audio recording, so you can hear the notation follow a real performance the moment the page loads). You press play, or the spacebar, and the notation highlights the note that is sounding and scrolls to keep up. You drop the speed to half and the music slows down while every pitch stays exactly where it should be. You drag across a hard passage and loop it. If you have a recording of the piece, you line it up to the score so playback follows the notation bar by bar. When you want to change the music itself, you switch to Edit mode and it behaves like a real notation editor, not a viewer with a few knobs.

There are three things you do with any piece, and the app is organized around exactly these three:

1. Listen. A clean player for viewing and playing a piece, with the notation cursor following along.
2. Practice. The tools you reach for when you are learning something: slow it down without changing pitch, loop a section, add a count-in and a metronome, and sync a real recording or a YouTube video to the score.
3. Edit. A full notation editor: enter and change notes, voices, ornaments, dynamics, ties, and lyrics, with autosave and undo.

Everything you do autosaves to your browser as you work; the header simply reads "All changes saved." There is no Save button to hunt for and no account to create before you can start. When you want a permanent, portable copy, you export the whole piece as a single .ovb file that you can host anywhere, email to a student, or embed in your own website.

That is the product. The rest of this page explains the idea underneath it, which is the part that makes OpenVoicing different from the practice apps you may already know: it is built on an open file format that you own, not a hosted service you rent.

A PDF of a score is a picture of music. It does not know what note is playing, it cannot slow down, and it cannot follow a recording. "Living sheet music" is the opposite: the notation is connected to sound and to time, so the page can respond to you.

In practice that means a piece in OpenVoicing knows several things a static score never can:

• What is sounding right now. As playback moves, the exact note being played is highlighted and the page scrolls to it. Turn on Follow and the score stays pinned to the spot that is playing.
• How to change speed without changing pitch. Slowing a passage to 50 percent lowers the tempo but keeps every note at its correct pitch, both for the built-in notation playback and for a real recording you have synced. This is genuine time-stretching, not a pitch-dropping tape effect.
• How a real performance lines up with the page. A sync map ties positions in a recording (in seconds) to positions in the score (in musical time), so the notation can follow an actual audio take or a YouTube video, and you can loop and slow the real thing while watching the page keep pace.
• Its own structure. Because the underlying document is real notation and not an image, the app can transpose a note, respell an enharmonic, insert a beat, or export clean MusicXML for another program.

The payoff is that the same file serves three jobs that normally need three separate tools: it is a readable score, a practice companion that plays and loops and slows down, and an editable document you can revise. It is "living" because the notation and the sound are the same object, kept in step by the sync map.

This is the core of what makes OpenVoicing different, so it is worth being precise about it.

Most interactive-notation and practice products are services. Your pieces live on the company's servers. You reach them through the company's app, under the company's account, on the company's terms, usually for a recurring fee. That arrangement is convenient right up until it is not: if the subscription lapses, the company pivots, the servers shut down, or the terms change, your library can become unreachable or unusable, and there is often no clean way to take a piece somewhere else.

OpenVoicing is built the other way around. The canonical thing is not an account on a server; it is a file. Every piece is a self-contained .ovb bundle that holds the score, any recordings, and the sync map that aligns them. The app is a client that reads and writes those files. The embeddable player is just static files that load a bundle. There is no server that has to stay online for your music to keep working, because there is no server in the loop at all: the app runs entirely in your browser, and your work autosaves locally to that browser, not to somebody's cloud.

What this buys you, concretely:

• No account, no sign-up, no subscription. Open the app and start playing. Nothing gates the first note behind a login or a trial.
• You hold the artifact. Export a bundle and you have a single file on your own disk. Copy it, back it up, put it on a USB stick, host it on your own site. It is yours the way a document is yours.
• Host it anywhere static. A bundle plus the player is a set of static files. Any plain web host, a personal site, a GitHub Pages repo, an S3 bucket, will serve it. There is no special backend to run.
• It keeps working offline. An audio-backed bundle is fully self-contained: the recording is packed inside the file, so it plays without a network connection. (The one exception is a bundle that references a YouTube video, which is covered honestly below.)

"Not a service you rent" is not a slogan here; it is the architecture. The format is the product, and the code is how you create, read, and play the format.

An .ovb bundle is a single portable file that packages one interactive piece. Technically it is a standard ZIP archive with a manifest.json at its root, which is deliberately boring: a ZIP is a format that will still open in fifty years, and the manifest is plain, readable JSON.

Inside a bundle you will find:

• The score, as a real notation document (imported from MusicXML, Guitar Pro, or AlphaTex).
• Zero or more recordings. A recording is either an audio take packed right inside the file, or a reference to a YouTube video. Audio recordings should use widely decodable formats; MP3 is the recommended choice because it plays across Safari, Chrome, and Firefox without fuss.
• The sync maps that anchor each recording to the score. A sync map is a short list of points, each tying a position in the recording (in seconds) to a position in the score (in musical ticks). Playback between anchors is interpolated, so the notation can follow the recording smoothly, and "jump to bar 20" can move both the page and the audio playhead together.
• A manifest listing the title, optional attribution (composer, artist, copyright, license, source), and whether the bundle is self-contained or references external media.

Because everything a piece needs travels inside the one file, sharing is trivial and durable. Hand someone the .ovb and they see exactly the interactive piece you made: same score, same recording, same sync, no account required. Point the embeddable player at the file's URL and it plays on any page. The format is specified in a public, normative spec (the bundle-format document), and the spec itself is licensed CC-BY 4.0, so anyone is free to build a tool that reads or writes .ovb files. That is what "open format" means in practice: the file is documented, the documentation is freely licensed, and OpenVoicing is not the only program that is allowed to understand it.

OpenVoicing is built for a few overlapping groups. You do not need to be technical to use it, and you do not need to be a musician to host it.

Musicians and learners

If you are practicing a piece, this is a tool you actually reach for: slow a hard bar to half speed without the pitch dropping, loop it until it is clean, turn on a count-in and metronome, and follow a real recording or a lesson video as it plays so you can hear how a passage should sound while watching the page. Open the app and start; there is no sign-up and the demo piece is already loaded.

Teachers

You can prepare a piece with a synced reference recording, mark it up, and hand a student a single .ovb file or an embedded player on your own studio page. The student needs no account and no purchase to open it. Because you can sync to a YouTube lesson or performance, you can build study materials around videos your students already watch, with the notation following along bar by bar.

Self-hosters and publishers

If you run a website, a method book, a blog, or a digital score catalog, you can publish interactive pieces on infrastructure you already control. A bundle plus the player is static files: drop them on any host, add a one-line script tag, and point a div at the bundle. No backend, no database, no per-play fees. The deployment guide and the static-hosting cookbook cover MIME types, CORS, caching, and sub-path deploys.

Developers

OpenVoicing ships an embeddable player and a JavaScript SDK (OpenVoicing.create) with data attributes, methods, and events, so you can put a piece on a page declaratively or drive it from code. The reusable libraries (the score model, the player, the audio engine, and the bundle tooling) are separate packages under a permissive copyleft license, so you can build your own tools on the format. There is also an ovb command-line tool to create, validate, and inspect bundles.

People who care about ownership and longevity

If you have been burned by a service shutting down, a subscription you resent, or a library you could not export, the pitch is simple: here your pieces are files you hold, in a documented open format, played by open-source code you can run yourself. Nothing has to stay online for your music to keep working.

It is only fair to be specific about the differences, including where a closed platform might suit you better. This is not a claim that OpenVoicing wins on every axis.

Where a closed platform may still fit you better, said plainly

• Huge managed catalogs. Commercial services often license and host enormous libraries of arrangements. OpenVoicing gives you tools and a format, not a pre-stocked store of copyrighted sheet music.
• Cross-device cloud sync out of the box. Because OpenVoicing keeps your work in your browser rather than a cloud account, moving a work-in-progress between devices means exporting and reopening a bundle, not automatic sync. That is the tradeoff for having no server hold your data.
• Turnkey collaboration and social features. A hosted platform can offer accounts, sharing dashboards, and comment threads. OpenVoicing's sharing model is a portable file and an embeddable player, which is simpler and more durable but less feature-rich as a social product.
• A vendor's support desk. With an open-source project you rely on the docs, the source, and the community rather than a paid support contract.

The honest summary: if you want a managed catalog and cloud convenience and you are comfortable renting, a closed platform may serve you well. If you want to own your files, keep your work private, host it yourself, and not depend on any company staying in business, OpenVoicing is built for exactly that.

OpenVoicing is released under the MIT license, one of the most permissive open-source licenses there is. This is the plain-language version; the authoritative details live in the LICENSING document.

MIT, in one paragraph

You can use, modify, host, embed, and redistribute OpenVoicing freely, including inside commercial and closed-source products. The only condition is that you keep the copyright and permission notice. There is no copyleft, no share-back requirement, and no network-use clause. This applies to the whole project: the authoring app, the embeddable player, the score model, the audio engine, and the bundle tooling (the .ovb format and the ovb CLI).

What this means for you, by situation

1. You use the hosted app or self-host it, changed or unchanged. Nothing is required of you. Use it freely.
2. You embed a piece on your own site with the standard player. Nothing is required of you beyond keeping the license notice.
3. You build your own tool on the libraries. Use them however you like and keep the MIT notice. Your surrounding code is entirely yours, under whatever license you choose.
4. You ship a product built on OpenVoicing, including commercially. That is fine. Keep the notice.

A few bundled and dependency components keep their own permissive licenses, and you preserve their notices when you redistribute a build: alphaTab (which does the engraving) under MPL-2.0, the fonts under the SIL Open Font License, and the FluidR3Mono soundfont under MIT. These are listed in the project's third-party notices.

"Own your files" can sound abstract until a service you relied on changes the deal. Here is the concrete case for why it matters, tied to how OpenVoicing works.

Longevity

Practice materials are things you come back to for years. A hosted library lasts exactly as long as the company hosting it, and companies pivot, get acquired, and shut down. An .ovb file on your own disk has no such expiry. It is a ZIP with plain JSON and standard media formats inside, so even far in the future it opens with ordinary tools, and the format is publicly specified so a new reader can always be written for it.

Control

When your pieces are files, you decide where they live, who gets them, and how they are backed up. You can keep a folder of bundles under version control, sync them with whatever backup tool you already trust, or archive them offline. You are never one billing failure or one terms-of-service change away from losing access.

Privacy

Because the app runs in your browser and autosaves locally, your library and your practice sessions are not sitting in someone else's database by default. There is no server collecting what you practice or how often. If you never export or embed a piece, it simply never leaves your machine.

Portability and reuse

Owning the file means you can take the work elsewhere. Every piece can also export plain MusicXML, so the score opens in other notation programs; you are not trapped in one app's ecosystem. And because the bundle format is open, the same file can be played by the OpenVoicing app, the embeddable player, or any future tool that implements the spec.

Independence from any one vendor, including this one

This is the part that makes the ownership claim credible rather than convenient. Even if the OpenVoicing project itself stalled, your files would keep working, because they do not depend on the project's servers (there are none) and the code that reads them is open source and self-hostable. The promise is not "trust us to stay online." The promise is "you do not have to."