SyMusOMRcodename is the product of a long-running research program in end-to-end visual understanding that is general-purpose. Our primary engine applies that work to music: it interprets an entire page as a connected spatial and musical system, then writes a structured score locally on supported Apple devices.
Limited technical overview. This page is a selective, non-exhaustive explanation for users and general readers. It intentionally omits source code, model weights, training recipes, data-generation logic, hyperparameters, and other implementation details, and it is not a reproducibility guide, technical specification, or authorization to implement the system.
During training, each example supplies only two things: a score image and its corresponding output sequence, written in a human-understandable grammar designed to map cleanly to MusicXML. No segmentation masks, bounding boxes, or symbol-level image annotations are provided.
First, the visual encoder learns what evidence is useful. It is never given pixel labels that identify staff lines, noteheads, stems, beams, rests, clefs, accidentals, or barlines. End-to-end sequence training teaches it to form useful visual features implicitly from the page.
Next, the architecture learns musical and spatial relationships. A dot can be a duration mark or visual noise; a curved mark can connect notes or belong to another symbol; and a notehead can participate in a chord, voice, beam group, and measure simultaneously. Those relationships are not supplied as a separate annotation layer - they emerge because the model must generate the correct music sequence.
Finally, the music decoder writes the corresponding grammar sequence. The sequence is human understandable and MusicXML compatible, and the app converts it into an editable score where pitches, durations, voices, staves, clefs, meters, and supported changes can be reviewed and corrected.
A dense page contains more relationships to resolve and more events to write. Runtime therefore tends to follow musical complexity - staff count, polyphony, symbol density, and layout changes - rather than a single fixed delay.
SyMusOMR grows from approximately ten years of research and development in multimodal understanding, including more than five years focused on a general-purpose vision-language Transformer architecture.
Music notation is relational: the meaning of a mark depends on what surrounds it and how it connects to other marks. Relational recurrent neural-network research helped establish ways for memory representations to interact through attention.
Original, currently unreleased work developed for Vision-Language Models (VLMs) explores positional representations intended to remain useful beyond the lengths seen during training. In music, position is not only left-to-right: events also belong to staves, measures, voices, systems, and nested groups. Selected aspects will be discussed only partially in future technical report(s).
Instead of bolting a music-specific parser onto a segmentation model, we took a fundamentally different approach for several reasons: Segmentation and bounding boxes, which many Music OCR engines use today, are fundamentally inflexible for the versatility we were looking for in musical expression. The resulting hard-coded, programmed system is of limited scientific interest, lacks scalability, and doesn't learn from experience. Moreover, segmentation based rules are often brittle even for standard, printed notation. We instead designed a general architecture that is astonishingly robust and adaptable. It learns how visual structure becomes musical structure, and it does so entirely through self-supervision.
The year counts and architecture names are project-history descriptions supplied for this partial beta overview. Future technical reports may discuss selected aspects, but are not intended to constitute a complete implementation specification or reproducibility package.
The engine is trained from procedural, randomly-generated score images and output sequences - not human-drawn segmentation masks, bounding boxes, or symbol-level labels. It is also designed to avoid collecting users' scores and to keep inference local whenever the supported device can perform it.
The learning signal is the final image-to-sequence correspondence. Visual features and musical relationships are learned implicitly, without masks, boxes, keypoints, or other human-annotated image labels.
Score images and their grammar are generated together from notation rules and rendering systems. The engine does not depend on a manually annotated score-image corpus or on private user uploads. Thus, no copyrighted works were involved in the trained VLM, and user data ownership is respected by being kept 100% private.
Recognition is designed to run locally on supported iPhone, iPad, and Mac hardware. A page need not be sent to a cloud recognition service.
The model is engineered for practical on-device memory, compute, and energy budgets rather than uploading anything to the cloud. Thanks to the power of Apple Silicon, recognition usually takes only several seconds per page, while documents are always kept private.
Why synthetic data? Music notation has combinatorial structure. Programmatic generation produces both the image and its exact target sequence while varying clefs, keys, meters, voices, chords, tuplets, handwriting-like fonts, page geometry, perspective, blur, lighting, and noise. No human has to draw masks, boxes, or symbol labels for those examples. Creating and validating such annotations is time-consuming work that is often labor-intensive, tedious, repetitive, and underpaid.
Why end-to-end? The only learning target is the corresponding music sequence. Traditional OMR pipelines can fail cumulatively when an early staff-removal, segmentation, or symbol-classification mistake constrains every later stage. Here, useful features and relationships are learned together from the final image-to-sequence objective, allowing distant context to help when local evidence is uncertain.
Why on-device? Local inference gives the musician direct control over the source image and avoids making recognition contingent on registration, network access, or recurring cloud processing.
The recognition workflow is designed so that score images can remain on the device. Testers should still follow the app's beta-reporting instructions before voluntarily attaching any diagnostic image to feedback.
Because the model learns relationships and structured output jointly, improvements can generalize across notation, page layout, image quality, and device conditions instead of requiring one handcrafted fix per symbol or specific example.
The model considers the page as a visual scene and document, not a bag of disconnected symbols. That enables it to use staff context, spacing, repetition, and neighboring measures to disambiguate marks.
Future versions can learn additional notation types while preserving the same core architecture. The roadmap includes text, chord symbols, lyrics, tablature, dynamics, expressions, articulations, and special noteheads.
Training intentionally varies camera perspective, rotation, lighting, scanner artifacts, fonts, handwriting-like rendering, score density, and staff configuration so that the model learns the underlying relationships.
We do not label pixels: no segmentation masks, bounding boxes, or other human-annotated image labels are part of the training objective. The model goes directly from a page image to a human-readable, MusicXML-compatible sequence, which the app turns into a score that can be auditioned, edited, corrected, and exported.
Our long-term vision is an engine that becomes more versatile without giving up privacy, robustness, or a general and flexible end-to-end architecture.
Evaluation note. Internal testing includes public-domain scores from sources such as IMSLP, as well as controlled synthetic test sets. Performance varies with notation coverage, page quality, density, and whether a feature is inside the current beta vocabulary.
The prism is a visual metaphor for a compact model separating and recombining overlapping evidence: appearance, musical identity, and position can share internal directions rather than occupying one dedicated unit each. The cited works in this section are guides to terminology and intuition only, not implementation recipes or claims that SyMusOMR adopts their mechanisms unchanged.
In mechanistic-interpretability research, superposition describes a network representing more useful features than it has individually available dimensions, by placing partly overlapping features in shared directions. Sparse features can coexist efficiently, although overlap can also create interference that later computation must resolve.
In our image-and-positional computational framework, overlapping is intended in two related senses. Spatially overlapping evidence can arise when visual marks, staff geometry, and nested positional scopes occupy or influence the same region—for example, a notehead may simultaneously belong to a chord, voice, measure, staff, and system. Probabilistically overlapping evidence means that a continuous internal state can retain weighted support for several candidate features, relations, positions, or continuations before later computation resolves them into a discrete music sequence.
The continuous-reasoning work below provides a related computational perspective: continuously valued chain-of-thought states can track multiple candidate traces in parallel rather than committing immediately to a single discrete path.
A fuller technical report is in preparation and will partially discuss selected aspects of the architecture, positional framework, image-to-sequence objective, and the intended relationship among spatial, probabilistic, and representational overlap. It will supersede this beta insert as the preferred technical citation, but is not intended to disclose a complete implementation or reproducibility package.
Suggested interim citation:
Symphony Pro Research (symphonypro.net), SyMusOMR Project. “Many Features, One Shared Representational Space: Superposition in Image and Positional Representations.” In How the MusicOMR Engine Works, beta documentation insert, revision 2026-08-04.The sources below are guides to terminology and related research directions.
Adam Santoro et al., 2018. Introduces a Relational Memory Core using multi-head dot-product attention so memory slots can interact during sequential reasoning.
Role here: conceptual guide only; not an implementation specification or reproducibility recipe for SyMusOMR.
Nelson Elhage et al., 2022. Uses small synthetic models to study how sparse features can be represented in overlapping directions when feature count exceeds representational dimension.
Role here: conceptual guide only; not an implementation specification or reproducibility recipe for SyMusOMR.
Halil Alperen Gozeten, M. Emrullah Ildiz, Xuechen Zhang, Hrayr Harutyunyan, Ankit Singh Rawat, and Samet Oymak, 2025. Studies continuously valued chain-of-thought states that can track multiple reasoning traces in parallel, with the attainable parallelism linked to embedding capacity.
Role here: conceptual guide only; not an implementation specification or reproducibility recipe for SyMusOMR.
Philip Heejun Lee, 2025. Introduces PRISM, a probabilistic relative-position mechanism designed for length extrapolation beyond the training horizon, and applies it to learning logical and algorithmic rules end to end from observations.
Role here: conceptually related prior work and a guide to positional terminology only; in contrast, SyMusOMR is a vison-language model, and is an unreleased positional framework for multimodal VLMs.
This is a partial overview of project philosophy and user-visible behavior. It intentionally omits proprietary implementation details and is not authorization to implement the system from any partial description thereof. Refer to Rights, permissions, and proprietary boundary for details.
Copyright. © 2026 Xenon Labs, LLC. All rights reserved. The text, diagrams, graphics, selection, arrangement, and other copyrightable expression in this material are protected. No license is granted by this publication to reproduce, adapt, translate, publish, distribute, or prepare derivative works from protected material, except as permitted by applicable law.
Written permission process. Before using protected material in a reproduction, adaptation, translation, publication, distribution, or derivative work, request written authorization by emailing team@symphonypro.net. State the material, intended use, distribution, commercial or noncommercial status, territory, and duration. Any permission or license is effective only through an express written authorization from an authorized representative that identifies the permitted use and terms. Merely viewing this page, sending an inquiry, or receiving no reply does not create permission or a contract.