NoteLite puts optical music recognition and score following in one Java app

It is Audiveris with a practice mode attached

NoteLite's positioning is precise and worth quoting, because it sets the expectation correctly. NoteLite builds on the Audiveris optical music recognition engine, keeping the original desktop editor and adding a separate practice mode. Recognize a PDF or image, review and correct the score, then export MusicXML / MIDI or start playing along.

So the recognition half is not NoteLite's own invention, it is an established engine, Audiveris, that NoteLite builds on and extends. That matters for the evaluation, because the quality of the optical music recognition is Audiveris's quality, and the accuracy question is a question about the upstream engine.

The product shape is then a three step loop. Recognise, refine, practise. The README's own framing is a single line: turn printed music into scores you can refine, listen to, and practice.

The two modes are presented as a table with what each is for. The original desktop editor is for recognising, inspecting and correcting the score. The practice mode is for following the score, finding mistakes and reviewing a session. The README notes that the original editor remains available while practice opens, and that practice is launched from the Book menu in a local browser window.

That is an interesting architectural decision. The desktop editor is a Java application, and the practice mode is a web application in a browser window. The reason is visible in the build instructions, since the practice assets are a separate Node.js project in practice-web/ that gets built with npm run build and produces assets included in the repository. The application serves those assets and opens them in a browser, so the practice interface is web technology and the recognition engine is Java.

Both screenshots in the README show the same piece, Minuet in G major, which is a sensible choice for a demo, since a Minuet in G is in most beginner method books and therefore the piece most likely to be lying around as a PDF.

Practice mode waits for the note, and scores only what it can

The practice side is the part that is NoteLite's own, and the README is unusually careful about what it does and does not do.

Practice offers a wait mode that advances when the expected notes are played, and a tempo mode for playing in time. Score rendering and pitch detection run locally. Desktop practice opens in your browser while the editor stays available.

The wait mode is the interesting one. Instead of playing continuously and scoring afterwards, the score waits until the expected note arrives, which is how a practice tool behaves when the point is to drill a passage you keep getting wrong. The tempo mode is the alternative for playing through, which is the useful mode for a piece you are trying to learn the shape of.

Then the limitations, and they are stated as a table of input methods with a scope column for each.

| Input | Scope | | --- | --- | | MIDI | MIDI-capable instruments; matches single notes and chords, and checks pitch and note onset timing | | Microphone | One pitched voice at a time; no individual-note scoring for chords, strumming, or ensembles | | Computer keyboard | A demo input for trying score following and note feedback |

So MIDI is the serious path, and it handles chords and checks onset timing, not just pitch. The microphone path is monophonic, one pitched voice at a time, and cannot score chords, strumming or ensembles, which is an honest description of what polyphonic pitch detection from a microphone can do in a practice tool. The keyboard is described as a demo input, which tells you it exists so the feature can be tried without hardware.

The README is also direct about what is out of scope. Practice does not assess tone, pedal use, fingering, or touch. And continuous playing across real instruments still needs further validation.

That last sentence is the one a pilot programme should read, because it says the continuous playing path, which is what most people would use, is not yet validated on real instruments. A teacher testing this on a real piano should know that before promising anything to a student.

Recognition errors become playing mistakes, so proofreading matters

There is a warning in the quick start that is the most practically important line in the README.

Practice uses the imported score as its reference. Check recognition results before starting so a recognition error is not treated as a playing mistake. Older releases may not include features present in the current source.

That sentence describes the whole failure mode of the tool in one line. The practice mode is not comparing your playing against the printed page, it is comparing your playing against the recognised score. If the recognition got a note wrong, the score is wrong, and the practice mode will then tell the player they played the wrong note, when in fact the software misread the page.

So the workflow is not optional. The user has to open the recognised score in the editor, look at it, and fix it before practising. That is why the README keeps emphasising that the original editor remains available, and why the two modes are presented as one application rather than two products.

The input options for practice reinforce this. You can import MusicXML or MXL, or use the current recognition result, so a user who already has a good digital score skips recognition entirely and goes straight to practice. And for a score exported by another application there is a specific menu entry, Book → Import external recognition result for practice.

The instrument handling is described in similar detail. You choose an input based on the score's instrument information, with manual overrides, and instrument suggestions use the score's instrument names, parts and MIDI programs, and you can select an instrument manually when that information is missing. That is a sensible approach, since the instrument selection determines the MIDI program and therefore which notes the practice mode expects for a given staff, and a score whose instrument metadata is wrong would otherwise produce nonsense feedback.

Build from source with Gradle, or take a package

The quick start offers two routes, and the package route is the one most people will take.

For the desktop app, download a package for your system from Releases, following that version's release notes. For a ZIP distribution, extract it and run bin/NoteLite.bat on Windows or bin/NoteLite on Linux and macOS, and these packages require Java 21, while macOS installers that bundle Java do not need a separate runtime.

The source route needs JDK 21 and JAVA_HOME pointed at it.

git clone https://github.com/Lucas0623z/NoteLite.git
cd NoteLite

# Start the original desktop editor
./gradlew :app:run --no-daemon

# Package the editor and practice launchers
./gradlew :app:distZip --no-daemon

The gradlew.bat equivalent is used on Windows, the distribution ZIPs are written to app/build/distributions/, and if OCR language data is needed for a first recognition run you configure it in the app's language settings.

That last point is a practical detail that can hold up a first recognition run.

The practice interface is a separate build step, because it is a separate application.

cd practice-web
npm ci
npm test
npm run build

Built practice assets are included in the repository, and Node.js 20 or newer is required to rebuild them after changing the practice interface.

The repository layout shows the shape of the project, with app/ for the Java application, practice-web/ for the web practice interface, apple/ for the native Swift clients, bridge/ for the recognition bridge the Apple clients talk to, benchmarks/ for the measurement guides, data/ for bundled data, schemas/, tools/, dev/ and packaging/ with a MACOS.md guide, flatpak/ for Linux packaging, and the top level build.gradle, settings.gradle and gradle.properties.

The Apple clients are a thin client over a bridge

The platform table lists three things, and the third is where the interesting engineering is.

The Windows, Linux and macOS desktop is the Java application with full recognition, manual score editing, export and practice. The native iPhone and iPad client is a score library, source previews, recognition jobs, practice and session history, on iOS or iPadOS 16 or later. The native macOS client is a score library, recognition jobs, practice and session history, on macOS 13 or later, with a SwiftUI split workspace.

The constraint is stated clearly and it is the design. Native Apple clients send PDFs and images to the recognition bridge you configure, they do not run the Java recognition engine on the device. Existing MusicXML files can go straight into practice, and full manual score correction remains in the desktop editor.

So the native clients are not a port of the application. They are a client for a server that runs the Java engine, and the bridge/ directory is the service that receives the images and returns the recognised score. The iPhone client gives you a library and a way to submit a job and see the result, and the correction work still needs a desktop with Java.

That is a reasonable division for a project whose recognition engine is a large Java application, and it is also why the README says the Apple builds are currently for development and testing, with no App Store release, and that installing on a physical device or distributing a build requires your own signing setup.

The macOS desktop packaging is called out separately, with a guide at packaging/MACOS.md, and the platform table notes that the macOS packaging supports both Apple Silicon and Intel, which is a compatibility decision worth having for a desktop application in 2026.

There is also a Flatpak directory in the repository, so the Linux distribution story has both the ZIP package and a sandboxed format.

Benchmark guides instead of a single accuracy claim

The benchmarks section is short and it is the most credible part of the README.

Recognition, MIDI export, and practice input are tested separately. Results from small test sets do not establish accuracy for every score or instrument.

That sentence is the kind of disclaimer that a project with something to hide does not write. It says the measurements exist, they are on small test sets, and they do not generalise.

There are separate guides for each concern, and the separation is the point. The Image and PDF to MIDI benchmark holds the original inputs, the independent references, the actual recognition outputs and the reproduction steps, so a reader can check the claims rather than take them. The MIDI export validation covers pitch, timing and regression checks for MusicXML to MIDI export, which is a different question from whether the recognition was right, and the third guide is for the practice input.

Splitting them matters because the three stages fail differently. A recognition error is a notation reading problem, an export error is a transcription problem, and a practice error is a signal processing problem, and a single accuracy number would hide which one is at fault.

The repository also carries a Designer.md and a MIDI_EXPORT_PLAN.md at the top level, which are the design notes for the export stage, and a CHANGELOG-style release history in the tags, with v5.11.0 in April 2026, v5.12.0 in July 2026 and v5.13.0 in September 2026, where the v5.13.0 release is labelled Guided Practice and Apple Previews.

The release cadence is notable for a project of this kind. Three feature releases in six months, with the practice mode being recent enough that the README warns that older releases may not include features present in the current source.

Where NoteLite is the wrong choice

The first wrong case is a musician who wants a finished score without proofreading. The recognition stage is Audiveris, and the output needs checking. The README says so directly, that practice uses the imported score as its reference and you should check recognition results before starting so a recognition error is not treated as a playing mistake. If your expectation is a clean MusicXML file from a photograph, this will disappoint.

The second wrong case is an Apple user who wants an App Store application. The native clients have no App Store release, require your own signing setup for a physical device, and they do not run the recognition engine locally, so a score you photograph on your iPhone is recognised by a bridge you have to configure and host yourself. The Java engine does not run on iOS, and the project does not pretend otherwise.

The third wrong case is a practice use case the input methods cannot support. The microphone path handles one pitched voice at a time, with no individual note scoring for chords, strumming or ensembles, and the tool does not assess tone, pedal use, fingering or touch. A violinist practising a piece with heavy string crossing gets pitch and onset feedback and nothing else.

The fourth wrong case is a musician who wants ensemble or ensemble-like feedback, which is a different category of tool entirely, or one who wants the continuous playing path validated on real instruments, since the README says that still needs further validation.

How it differs from a standalone OMR tool

The comparison worth making is with the optical music recognition tools that exist on their own, and the difference in approach is what happens after the recognition finishes.

A standalone OMR tool produces a file. You run it on a PDF, it gives you MusicXML, and the workflow ends there. The score is a document, and the tool has done its job when the document is written. If you want to listen to it, you import it into a notation editor, and if you want to practise it, you import it into a practice application, and each of those imports is a conversion with its own failure modes.

NoteLite keeps the recognition and the practice in one application, and the score is a working object rather than a file that gets passed around. The recognition result goes into the editor, the editor result is what the practice mode follows, and the export is available if you want a file rather than a session.

The second difference is the practice mode's design. A practice app that works from a MusicXML file has no opinion about where that file came from, so it cannot know whether a wrong note is the player's mistake or the file's. NoteLite's practice mode opens on the current recognition result, so the two stages are connected and the warning about checking the score is the seam where the user is expected to intervene.

The third difference is that the practice side is web technology inside a desktop application. The Java editor and the browser based practice window are separate code bases, with the practice assets built by Node and served by the Java process. That is a pragmatic way to get a modern interface without rewriting the editor, and it is also a constraint, since a user who wants the practice experience on a tablet gets a native Swift client that talks to a bridge rather than the same web assets.

Editorial conclusion

NoteLite fits a musician or a music teacher who has printed scores and wants them as editable MusicXML, or who wants a practice mode that waits for the right note and highlights mistakes, and who is prepared to check the recognition output by hand. It does not fit a musician who wants a finished score without proofreading, since the README is explicit that a recognition error will be treated as a playing mistake, and it does not fit an Apple user expecting an App Store app, since the native clients have no release and require your own signing setup. Before adopting it, check that the recognition accuracy on your own material is acceptable using the image and PDF to MIDI benchmark, note that the ZIP packages need Java 21 while the macOS installers bundle it, and be aware that the newest tagged release is v5.13.0 from 2026-09-23 with the last push on 2026-10-12.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. Lucas0623z/NoteLite on GitHub
4. README
5. Releases