# MuseScore Studio: Building and Running the Open Source Notation Editor

> MuseScore Studio is a GPLv3 music notation and composition program written in C++ with Qt. This covers what the repository actually contains, how the CMake build works, and where the project's own documentation runs out.

**musescore/MuseScore** — MuseScore is an open source and free music notation software. For support, contribution, bug reports, visit MuseScore.org. Fork and make pull requests!

- Repository: https://github.com/musescore/MuseScore
- Website: https://musescore.org
- Stars: 15,161 · Forks: 3,317
- Language: C++
- License: NOASSERTION
- Published: 2026-09-21 · Updated: 2026-09-21 · Language: en
- Canonical page: https://hysenlabs.com/projects/musescore-musescore

## What MuseScore Studio is, and the problem it solves

MuseScore Studio is a desktop application for writing music in standard notation. Notes go onto what the README calls a "virtual notepaper", so the page you edit is the page you print. That single sentence separates it from two neighbouring categories. A sequencer records performance data and renders it; a notation editor records musical structure and renders that. If you need to hand a cellist a part, transpose it, and export a MusicXML file another program can read, you want the second kind.

The repository is the upstream source for that application, not a library or a service. The README lists the file formats it speaks: MusicXML, MIDI standard MIDI files, MEI, and MuseData on import. It also lists a software synthesizer and sequencer for playback, and PDF export. Those are the interfaces most integrators care about, because they define what can enter and leave the program without touching its internals.

Who this is for, concretely: C++ developers who want to compile, patch or embed a notation engine; people building tooling around MusicXML who want a reference implementation; and packagers who need to produce a build for a distribution. It is not aimed at someone who wants a notation component with a permissive licence, and the README does not present it as one.

## How the codebase is put together

The top level of the repository shows the shape of the project. src/ holds the application code, share/ holds runtime assets such as the fonts the README mentions for display and printing, fonts/ and demos/ sit alongside them, and test/ plus vtest/ hold the test suites. buildscripts/ and SetupConfigure.cmake are part of the build machinery, and CMakeLists.txt with CMakePresets.json define the CMake entry points. The README points at a wiki page called Code Structure for the package layout, which means the authoritative description of module boundaries is not in the repository root.

The dependency story is split. muse_deps holds third party dependencies, while muse/ is a git submodule pointing at muse_framework. The README is explicit that cloning without --recurse-submodules leaves muse/ empty, which is the most common way a first build fails. That submodule is not incidental: it is a separate repository with its own history and release cadence, so a MuseScore Studio build is really a build of two projects pinned together by a commit reference.

Python appears only as tooling. The pyproject.toml names the project MuseScoreStudio, sets requires-python to >=3.10, and declares two dependencies, requests and markdown. Its own description says these are "Python scripts for MuseScore Studio development", so the Python environment is for build and release helpers, not for the application runtime.

## Installing MuseScore Studio from source on Linux, macOS or Windows

The README does not give a package manager command for any platform. It points at the wiki's Set-up developer environment page for the dependency list and a complete walkthrough, and that page is where platform specific prerequisites live. What the README does give is the clone and build sequence, and it is short enough to follow directly.

The first step pulls the repository and its submodules in one go. The --recurse-submodules flag is what populates muse/ with muse_framework, and the README notes this explicitly:

```bash
git clone --recurse-submodules https://github.com/musescore/MuseScore.git
cd MuseScore
```

If you would rather not carry the full history, the README offers the source tarball from the Releases page as an alternative, unpacked with tar xzf followed by cd into the resulting directory. That path avoids git entirely, but it also means you are building a fixed release rather than tracking main.

A release build is a single CMake script invocation rather than the usual configure and make pair:

```bash
cmake -P build.cmake -DCMAKE_BUILD_TYPE=Release
```

On macOS the README adds a specific requirement: append -G Ninja, because Swift components in the build need the ninja generator. If the build directory ends up in a bad state, appending clean to the same command deletes it, after which the original command can be run again. Omitting the build type entirely defaults to RelWithDebInfo, which the README describes as a compromise between Release and Debug.

Running the result does not require finding the binary by hand, because build.cmake accepts a run target:

```bash
cmake -P build.cmake -DCMAKE_BUILD_TYPE=Release run
```

What you should see is the MuseScore Studio window with an empty score, ready for note entry. Once it opens, the first real task is entering a few notes and exporting to MusicXML or PDF through the file menu, which exercises the import/export paths the README lists. For code contributions, ./hooks/install.sh installs a pre-commit hook that formats staged files, and the README states it requires uncrustify to be installed first; ./hooks/uninstall.sh removes it.

## Where the documentation stops and the source begins

The README is a developer entry point, not a manual, and the gaps are worth naming before you plan around them. There is no documented API surface. If you want to drive MuseScore Studio programmatically, the README lists no scripting interface, no plugin API and no command line flags beyond the build.cmake targets. The wiki is referenced for unit tests, code structure and the developer environment, but the repository itself does not describe an extension contract.

Build reproducibility is another soft spot. The README gives the commands but not the dependency versions, deferring to the wiki page for the list. That means a build that worked against one Qt or compiler release may not work against another, and the repository root does not pin those versions in a way the README explains. The clean subcommand exists precisely because builds do go wrong, which is a reasonable admission but also a signal that incremental recovery is not always straightforward.

The licence field in the repository metadata reads NOASSERTION while the README and the badge both state GPL version 3.0 and point at LICENSE.txt. The README is the more specific statement, but the mismatch is the kind of thing a compliance review will ask about, and the repository does not resolve it for you.

## MuseScore Studio compared with LilyPond

The clearest alternative in this space is LilyPond, and the difference is not cosmetic. MuseScore Studio is WYSIWYG: you place notes on a rendered page, and the layout updates as you edit. LilyPond takes a text file of pitch and duration syntax and produces engraved output in a separate compilation step. One is an editor with a document model behind it; the other is a typesetting pipeline with no interactive canvas.

That changes who each tool suits. If your workflow is a build system that regenerates scores from version controlled text, LilyPond fits naturally, and MuseScore Studio does not offer an equivalent headless authoring path in anything the README describes. If your workflow is a musician sitting at a keyboard entering notes and adjusting layout by eye, MuseScore Studio's model is the direct one, and hand editing LilyPond source to nudge a slur is a different kind of work.

The overlap is at the file level. MuseScore Studio imports and exports MusicXML, which is the interchange format most other notation tools accept, so the two can coexist: author in one, exchange through MusicXML, engrave in the other. The README lists MusicXML, MIDI, MEI and MuseData support, which is a wider set of import and export paths than the README claims for any single format.

## Maintenance, releases and what upgrading costs

The repository is not archived, and the last push was on 2026-09-21. Releases are frequent and versioned in the 4.7.x line: v4.7.3 on 2026-06-11, v4.7.4 on 2026-07-07, and v4.7.5 on 2026-09-08. That cadence matters for anyone tracking main, because the distance between a release and the branch tip is measured in weeks rather than quarters.

The upgrade cost sits mostly in the submodule. Because muse/ is a pinned reference to muse_framework, moving to a new MuseScore Studio commit may also move the framework commit, and the README does not describe how those two are versioned together. A patch that compiles against one pairing may not against the next. The build.cmake clean escape hatch is the documented recovery, and it means a full rebuild rather than an incremental one.

On licensing: the README states GPL version 3.0 and links LICENSE.txt. That is a copyleft licence, and the practical consequence for anyone embedding the code in another product is that distribution terms propagate. The repository metadata's NOASSERTION value does not override the README's statement, but it does mean automated licence scanners may report the project as unknown. This is a description of what the files say, not legal advice; the terms themselves are in LICENSE.txt.

## Conclusion

MuseScore Studio suits engineers who need a GPLv3 notation engine they can compile and modify: the repository is a full C++/Qt application with MusicXML, MIDI and MEI import/export, and the last push was on 2026-09-21. It is the wrong choice if you only want a notation library to link into a proprietary product, since the licence is GPLv3 and the README offers no alternative terms. Before committing, verify three things: that the muse_framework submodule is checked out, that your Qt and compiler versions satisfy the wiki's dependency list, and that the interfaces you intend to call are documented anywhere outside the source.

## FAQ

### How much does MuseScore Studio cost?

Nothing. The README describes it as open source and free music notation software, and the source is published under GPL version 3.0.

### Is MuseScore Studio actually free?

Yes, the README states it is open source and free, and the repository carries a GPL v3 licence badge pointing at LICENSE.txt. The source is available to clone and build yourself.

### What are the disadvantages of MuseScore Studio?

The README documents no scripting or plugin API, no command line flags beyond the build.cmake targets, and no pinned dependency versions, deferring those to the wiki. It also does not document an equivalent to LilyPond's headless text-to-score workflow.

### How do I use MuseScore Studio to write music?

The README describes a WYSIWYG design where notes are entered on a virtual notepaper, with MIDI input available for note entry and a built-in sequencer and software synthesizer to play the score back. Scores can then be printed or exported as PDF.

### How do I use MuseScore Studio for free?

The README presents the software as open source and free, licensed under GPL version 3.0, with the full source available in the repository. There is no paid tier described in the README.

### How do I install MuseScore Studio plugins?

The README does not document a plugin system, a plugin format or an installation path for plugins, so the repository gives no answer here. The only extension-adjacent item it mentions is the ./hooks/install.sh pre-commit formatting hook for contributors.

## Sources

- [Issues](https://github.com/musescore/MuseScore/issues)
- [musescore/MuseScore on GitHub](https://github.com/musescore/MuseScore)
- [Project website](https://musescore.org)
- [README](https://github.com/musescore/MuseScore/blob/main/README.md)
- [Releases](https://github.com/musescore/MuseScore/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/musescore-musescore