Musique Technology

Musique Technology · the engraving engine

The engraving engine is ours, end to end — every glyph, every spacing decision, every byte of the PDF.

This is the engine under Musique notation. We wrote it. Pure Rust, one process, no subprocess, no copyleft license anywhere.

This page is about the engine, not the product. The writing product on top of it is still being built, and this page says so plainly in every place it comes up.

What the engine actually is, in numbers

Measured from the source tree and from a real test run. Each figure carries the bound it was measured under.

  • 5Rust crates in the engraver workspacestencil, engine, render, fidelity, wasm
  • 65source files under src/Counted 2026-07-28. Excludes build output.
  • 968 / 970tests passing across the workspaceMeasured 2026-07-28. 2 failed. Both named below.
  • 3third-party crates in the engraving pathA serialization pair and a font-outline reader. Nothing else.

The two that fail. Both are repeat-barline geometry assertions in the systems module. One checks the thick-then-thin stroke order. The other checks that start and end repeats mirror each other.

We print them because a page that hides its red tests is not proof of anything. It is a brochure with a number on it.

The run was cargo test across the whole workspace, 2026-07-28, 24 test binaries. Ask and we will send you the raw output.

Why an owned engine, and why you should care

Notation software has to solve a hard, invisible problem: turning notes into a page a player can read at speed. Most tools do not solve it themselves. They wrap an engine somebody else wrote, usually under a copyleft license. That is a reasonable engineering choice. It is a worse ownership position, and the difference lands on you.

A license you can print under

Copyleft licenses attach conditions to what you build with the tool. Our engine carries none. Print the parts. Sell the program book. No license question follows the page.

One process, not a chain

The engine never shells out to another program. There is no second binary to install, break, or version-pin. Layout happens in the same process that reads your file.

Nobody upstream can change your page

When layout lives in someone else’s project, their release can move your notes. Ours only changes when we change it. Your March reprint matches your September print.

We can fix the thing you found

Report a collision in a beamed run and it is our code. No upstream issue queue, no waiting for a maintainer who never met your ensemble. The fix ships when we ship.

It runs where the browser runs

The engine compiles to WebAssembly. That means engraving in a tab, on a school laptop, without an install request to the technology office.

It is an asset, not a rental

The engine is owned code on our books. That matters in a review: the capability does not evaporate if a third-party project changes direction or shuts down.

The honest counterweight. Wrapping a mature engine is faster and starts out more complete. We chose the slower road on purpose. It means our coverage grows leaf by leaf, and this page tells you where that coverage currently stops.

Score text in, engraved page out — the whole chain

Nine stages, all in one process. You can name every step, and so can we. That is the point of owning it.

  1. Read the score text

    A parser reads a plain-text score syntax and produces tokens. Text in, structure out. No binary format, no database, nothing to migrate.

  2. Build the note IR

    Tokens become ScoreIR, a frozen note-level model: pitches, durations, ties, measures, clefs, lyrics. This is the layer that knows what the music says.

  3. Place the notes horizontally

    Spacing decides how far apart events sit. A skyline pass tracks the ink already on the staff so nothing lands on top of something else.

  4. Group beams, ties, and tuplets

    Beaming decides which notes join and how the beam slopes. Ties and tuplets get their own passes, because both are shape decisions, not note data.

  5. Set accidentals and columns

    Accidentals resolve against the key and the measure. A column pass stacks simultaneous accidentals so they read as a chord, not as a pile.

  6. Break into systems and pages

    Systems fill the staff width. Breaking chooses where lines and pages end. The engine searches for the best set of breaks, not merely the first that fits.

  7. Bake the glyph outlines

    Every notehead, clef, rest, and dynamic becomes a real outline. Either an owned parametric definition or an outline read from a music font we license permissively.

  8. Assemble the scene

    Everything lands in a Scene: a flat, integer-coordinate list of shapes and text. The Scene is the last format that is still ours to inspect.

  9. Write the file

    The Scene emits native SVG, native PDF bytes, a PNG raster, or a standard MIDI file. No external printer, no conversion utility, no temp directory.

Inside the engine room

Each of these is a module with its own tests, not a bullet on a feature list. If you want to know how a decision gets made, there is a file that makes it.

The frozen note model

One IR sits between reading and drawing. Freezing it means a spacing change can never quietly alter which notes exist. Musical truth and page layout stay separate.

Spacing with a skyline

The engine keeps a running profile of the ink already placed. New material is fitted against that profile. Collisions get avoided, not cleaned up afterward.

Optimal line breaking

Breaking evaluates whole layouts rather than filling greedily. Its own tests compare the chosen result against an exhaustive search on small inputs.

Lyrics on their own layer

Text sits in a dedicated layer with its own metrics. Verse lines align under the syllables they belong to instead of floating near them.

Score transforms

The engine can re-time a score into a new meter and re-arrange it in a given style. Both operate on the IR, so the result is still fully engraved.

MIDI in and out

A score exports to a standard MIDI file, and MIDI can be read back in. Playback and part checking do not require a second application.

Its own rasterizer

A Scene rasterizes to PNG inside the crate. Screen previews and the legibility checks both use it. There is no image library in the dependency list.

Bin targets you can run

8 command-line binaries ship with the workspace: render tools, conformance probes, a token ledger, and the parity gates. The proofs are executable, not screenshots.

The glyph program: drawing our own music symbols

A notation engine is only as good as its symbols. Most engines rent theirs from a font. We are authoring ours as code, family by family, so the shapes are ours to tune and ours to own.

Outlines we author

A glyph is defined as parametric bezier curves and baked into an outline at render time. The definition is code we wrote, not a file we downloaded.

11 families, one registry

Noteheads, rests, clefs, accidentals, flags, dynamics, articulations, ornaments, braces, directions, and time digits each register into the same source.

A weight axis, not a second font

Style parameters flow into the authoring function. A heavier notehead for a beginner part is a parameter change, not a separate font to license and ship.

Standard names throughout

Glyphs are keyed by the industry-standard music symbol names. Anything built against that vocabulary can read our output without a translation table.

Layered, so gaps degrade gracefully

Where an owned glyph is not authored yet, the source layers over a permissively licensed music font. The page still engraves. Nothing renders blank.

Measured against the reference

A comparator rasters our glyph and the reference glyph side by side. It reports overlap, extra ink, optical center shift, and advance width difference.

Where this currently stops. The owned glyph set does not cover every symbol yet. Uncovered names fall through to the licensed font underneath, by design, while the families are written.

So the honest version is: some of what you see on a page is our outline, and some is still the font. Both are cleanly licensed. Neither is copyleft.

The same score always makes the same page

Engraving math in this engine uses integers only. There is no floating-point arithmetic in the geometry.

That sounds like a detail. It is the reason a part you print in March matches the one you printed in September. Decimal drift is how two runs of one file end up a hair apart. It is also how a page break moves overnight, with no explanation you can give a room full of students.

The determinism goes all the way to the file. Our PDF writer includes our own compression codec, written to be byte-deterministic: the same input produces the same compressed bytes, every time. Its tests compare against stored golden output and fail if a byte moves.

For you, that means one practical thing. A part is a stable artifact. You can archive it, hand it to a copyist, reprint it three years later, and get the page you approved.

Why we wrote a compression codec. Not for fun. Pulling in a compression library would have added a dependency to a crate that advertises three. So the codec is ours, integer-only, and round-trip tested inside the same crate.

What comes out the other end

Every format below is produced inside the engine. There is no conversion utility in the chain, and no format we cannot explain.

SVG, written directly

The engine emits SVG from the Scene with no conversion step. Vector output for the web, for a projector, or for a print shop that wants curves.

PDF, written by us

PDF bytes come out of our own writer, with our own compression. No external PDF printer is installed, invoked, or required anywhere in the path.

PNG for previews

The built-in rasterizer turns a Scene into a PNG. Thumbnails, proofs, and the automated legibility checks all use the same renderer.

Standard MIDI files

A score exports as a standard MIDI file. Play it back, load it into a rehearsal tool, or hand it to a student to practice against.

A MusicXML bridge

The test harness reads and writes MusicXML. That is the interchange format the notation world already shares, so scores are not trapped here.

A WebAssembly build

Five functions cross into the browser: render to SVG, render to PDF, export MIDI, re-time, and arrange. Engraving happens on the machine in front of you.

The license gate: a machine says no, not a person

Anyone can write “no GPL” on a page. We wanted it checked by something that does not get tired.

The engraver ships a license policy file. It is an allowlist: MIT, Apache-2.0, BSD, ISC, and a short list of similar permissive terms. Every dependency in the graph gets checked against it before the engine can ship.

The important part is the direction it fails. Anything not on the allowlist is rejected, including licenses the file has never seen. Unknown is not permitted. Copyleft terms cannot pass, because they were never added.

The check resolves the whole dependency graph across every build target, including the WebAssembly chain. Restricting it to one platform would have blinded it to the exact code that reaches a browser.

The hole we found in our own gate. An early version let any crate declare itself proprietary and pass. A planted crate named as an obvious foreign blob did exactly that, and the gate exited clean.

The fix binds the exemption to crate identity. A crate must both declare the license and be one of ours, by name. Declaring the string is no longer enough.

We are telling you this because a gate nobody has attacked is not a gate. It is a hope. The attack, the failure, and the fix are all recorded in the policy file itself.

How we prove it engraves correctly

Claiming an engine works is easy. The harness that checks it has three passes, and each one is built so it cannot pass by accident.

Semantic: the right notes

The engine’s note model and an independent MusicXML reading of the same music are reduced to one ordered stream, then compared. Pitches, durations, ties, measures.

Layout is deliberately excluded

The semantic pass ignores position, page breaks, and fonts. Mixing layout into a correctness check is how a cosmetic difference gets reported as a wrong note.

Legibility: the page is readable

The engine renders to PNG, then the pass asserts ink exists, every notehead anchor lands on the page, and each sits near its staff band.

Checked with the engine’s own maps

The staff-band check reads the engine’s real spacing and staff maps. It does not re-derive them, because a re-implementation would test itself.

Per-glyph: shape parity

Our glyph and the reference glyph get rastered and compared: overlap, extra ink, center shift, advance width. Numbers, not a visual impression.

A threshold, then a human

Glyph parity is a reviewed threshold, not pixel equality. We intend to diverge from the reference where we think we can do better, so equality would be the wrong target.

Two limits the harness states about itself. The legibility pass renders at a reduced preview scale. A full multi-measure work at the engine’s native unit would exceed the rasterizer’s pixel ceiling.

And the line-breaking leaf it renders through is still a single-system stub. When a scene exceeds the ceiling, the harness reports that in its notes rather than recording a false pass.

The semantic pass is scale-independent and unaffected by either. We keep the limits written down in the code that has them.

Wrapping an engine, versus owning one

Both approaches produce notation. They produce very different answers when someone in a district review asks a hard question.

The two positions compared on the questions a buyer actually asks.
The questionWrapping an outside engineOwning the engine
Who owns the layout codeAn outside project, on their release scheduleWe do. It changes when we change it.
License on the engraving pathOften copyleft, with conditions attachedPermissive only, checked by an allowlist that fails closed
How a page gets producedThe app calls out to a separate programOne process, start to finish, no second binary
Reprint in three yearsDepends on that program still installing and behavingInteger math and byte-deterministic output, by design
A bug in your ensemble’s musicFiled upstream, then you waitOur file, our fix, our release
Running in a browserUsually a server round trip, or an installCompiles to WebAssembly and runs on the device
What the vendor can show youA feature listCrates, modules, tests, the license policy, and the known gaps

No product names appear in this table on purpose. The comparison is between two engineering positions, not between us and a company.

Who this page is written for

The music director who has to defend a choice upward.

You know what good engraving looks like. You can spot a beam that lies about a rhythm from across the room. What you may not have is the language for the other meeting. The one where someone asks whether the district can legally print what this thing makes. And what happens if the vendor goes away.

So here is that language, in four lines. The engraving code is owned outright, not licensed from an outside project. Nothing in the shipping path carries a copyleft license, and a fail-closed gate enforces it. The output is deterministic, so an archived part reprints the same. And it runs in a browser, so it is not an install request.

If someone in that meeting wants more depth, the crates, the module names, the test counts, and the license policy are all above. Point at them.

The technology director

No install, no license question, and no second binary to package. It compiles to WebAssembly and runs in the browser you already support.

The business office

The engine is owned code, not a subscription to somebody else’s project. There is no upstream license that can change terms on your printed music.

The student in your program

Parts that read cleanly at a stand, and files that still open years later. That is what all of the above is actually for.

The words on this page, in plain terms

You read music for a living, not build notes. Here is every technical word above, defined once, so you can use them in the meeting where it counts.

Copyleft license

A license that attaches conditions to whatever you build with the code. Powerful, and deliberately sticky. Our engraving path carries none of it.

Permissive license

A license that lets you use the code and keep your own terms. MIT and Apache-2.0 are the common ones. Everything we depend on is in this family.

Subprocess

One program launching another to do part of the job. Convenient, and a common failure point. Our engine never does it.

Deterministic

The same input always produces the same output, byte for byte. It is why an archived part reprints exactly as approved.

Integer-only geometry

Positions are whole numbers rather than decimals. Decimals drift a hair between machines. Whole numbers do not drift at all.

IR, or intermediate representation

The engine’s internal model of the music itself, separate from how it is drawn. Keeping them apart is why layout work cannot change your notes.

Glyph

One drawn music symbol: a notehead, a rest, a clef, a dynamic. A page is thousands of them, placed to the hundredth of a point.

Rasterizer

The part that turns drawn shapes into pixels for a screen or a proof. Ours is inside the engine, not a separate image library.

Allowlist

A list of what is permitted, where anything unlisted is refused. The opposite of a blocklist, and the reason an unknown license cannot slip through.

WebAssembly

A way to run compiled code inside a browser at near-native speed. It is how engraving happens on a school laptop without an install.

MusicXML

The interchange format notation programs use to hand scores to each other. Support for it is what keeps a library portable.

Fail-closed

When a check cannot answer, it refuses rather than allows. A gate that shrugs and passes is not a gate at all.

What is built, what is partial, what is not

A proof-of-engineering page that only lists wins proves nothing. Here is the whole ledger, including the rows we would rather not print.

The engine, honestly scoped. Measured 2026-07-28.
CapabilityStateScope
The engraving engineBuiltParser, note IR, spacing, beaming, ties, tuplets, accidentals, systems, breaking, lyrics.
Native SVG and PDF outputBuiltOur own writers, including our own compression codec. No external printer in the path.
MIDI export and importBuiltStandard MIDI files, both directions, inside the engine crate.
The fail-closed license gateBuiltAllowlist policy, identity-bound exceptions, resolved across every build target.
The WebAssembly seamBuiltFive functions exposed to the browser. The logic behind them is plain Rust and host-testable.
Owned glyph outlinesPartialEleven families are being authored. Uncovered symbols layer over a permissively licensed font.
Line breaking at full scalePartialThe leaf the legibility pass renders through is still a single-system stub.
Repeat barline geometryFailingTwo tests fail on stroke order and on start-versus-end mirroring. Open, and printed here on purpose.
The note-entry editorNot builtThe product a musician opens and works in does not exist yet. This is the honest gap.
The in-browser appNot builtThe engine compiles for the browser. The application around it is not finished.
Any published score on our sitesNot wiredThis engine has not produced any score published elsewhere on the platform. Those came from other tooling.

The order of work from here

Ordered by dependency, not by date. We are not putting a calendar on this page, because we would rather be right than early.

  1. Fix the two failing tests

    Repeat-barline geometry: stroke order, and start-versus-end mirroring. Small, specific, and currently red. It goes first because it is red.

  2. Finish the owned glyph families

    Keep authoring outlines family by family until the licensed font underneath is no longer carrying any of the page.

  3. Line breaking at full scale

    Take the single-system leaf to full multi-system, multi-page output at the engine’s native unit rather than a preview scale.

  4. Widen the score syntax

    Conformance probes already measure which parts of the input syntax the parser covers. Widening that coverage is a measured, incremental job.

  5. Build the note-entry editor

    The surface a musician actually opens. This is the largest remaining piece of work, and none of the engine above substitutes for it.

  6. Ship the in-browser app

    The WebAssembly seam exists. The application around it does not. That is the last step between an engine and a product you can use.

This is intent, not a commitment. It is the order we believe the work has to happen in. If it changes, this list changes, and the reason will be on this page.

Questions we actually get

Can I use this today?

Not as a product. The engine is built and running. The editor a musician opens is not finished, and there is no in-browser app to hand you yet. Early access is the honest next step.

What does “owned engine” actually mean?

We wrote the layout code. Spacing, beaming, breaking, glyph outlines, and the file writers are our source files. No outside notation program is installed, called, or embedded anywhere in the path.

Is there any GPL code in it?

No. A fail-closed allowlist checks every dependency before the engine ships. Copyleft terms are not on the list, so they cannot pass. Unknown licenses are rejected too.

Why does the license matter to a music program?

Copyleft licenses attach conditions to what you build with the tool. A permissive engine leaves no license question hanging over the parts you print or the program book you sell.

Are all the tests passing?

No. On 2026-07-28 the workspace run was 968 passed, 2 failed. Both failures are repeat-barline geometry in the systems module. We would rather print that than publish a badge we have not earned.

Does this engine make the scores on your other pages?

No. It has not been wired to any score published elsewhere on the platform. Those were made with separate, existing tooling, and this page makes no claim about them.

Does it use AI to write or arrange music?

No. There is no generative music anywhere in it. The engine sets the notes you wrote. Its re-time and arrange transforms restructure your own material; they do not invent new material.

Why write your own glyphs instead of using a music font?

Owned outlines can be tuned, weighted, and shipped without a font license question. It is slower. Until a family is authored, we layer over a permissively licensed font, and the page still engraves.

What does integer-only math get me?

Repeatability. Floating point drifts between runs and platforms. Integer geometry does not, so a part reprinted years later matches the one you approved.

Can it run without installing anything?

That is the design. The engine compiles to WebAssembly and runs in the browser. Five functions cross the boundary: render to SVG, render to PDF, export MIDI, re-time, and arrange.

Can I get my music out again?

Yes. The harness reads and writes MusicXML, the interchange format the notation world shares, and scores export as standard MIDI files. Your library is not locked in here.

What does it cost?

There is no pricing on this page and no checkout. The engine is not sold separately. Ask about the suite and we will talk about what you need first.

What is the weakest part right now?

Two things. The owned glyph set does not cover every symbol yet, so some symbols still come from the licensed font. And the line-breaking leaf the legibility harness renders through is a single-system stub.

Where to go next

This page is deliberately narrow. These three cover the product, the program, and the platform.

musique.software

The suite this engine sits under. That page is the product a musician opens; this one is the machinery underneath it.

musicschool.software

Running the music program itself: lessons, studios, scheduling, enrollment. A different job entirely, and a different tool.

homeroom.software

The wider school platform this family belongs to. Records, publications, picture day, communications, all on one roster.

What this page claims, and what it does not

Claimed. The engraving engine exists and is built. It is pure Rust across five crates. It carries no copyleft code, and a fail-closed allowlist enforces that. Its geometry is integer-only and its output is byte-deterministic. It writes SVG, PDF, PNG, and MIDI with its own code.

Not claimed. That the suite is green — it is 968 of 970, and the two failures are named above. That the finished writing product is available — it is not, and it is the largest gap on this page. That the owned glyph set is complete — it is not, and a licensed font covers the rest. That this engine produced any score published elsewhere on our sites — it has not been wired to them.

Never claimed. No AI-generated or auto-composed music. No pricing, no checkout, no payment. No competitor is named anywhere on this page, because the argument is about engineering, not about anybody else.