OOLOI.ORG
Menu

OOLOI

An Organism Evolved.

OVERVIEW

DOCUMENTATION

NEWSLETTER

Stave Size Matters

29/3/2026

9 Comments

 
Picture
Working on the Instrument Library – which has occupied the last few posts – I came to the point of editing staves inside instruments. That led, as it does, to clef representation; and clef representation led to the question of stave heights; and stave heights, once you look at them honestly, open onto a set of questions about what the numbers actually mean and who they serve. This is how development works: you pull on one thread and another appears. You pull that one and something else comes loose. The art is not pulling on all threads at the same time, or you end up with all yarn in one tangled clump. And when the threads start to proliferate, that is the signal to stop pulling and start architecting.

So: stave sizes. One thread at a time.

The stave space – the distance between two adjacent stave lines – is how Ooloi measures everything. Glyph dimensions, stem lengths, beam thicknesses, spacing: all of it derives from that single value, stored in millimetres. Not stave height; the space. The height is a consequence.

I spent some time recently with the rastral table. A rastrum was a pen with five nibs, drawn across the copperplate page to produce a music stave in one stroke. The finite set of available pen widths produced nine standard stave heights, numbered 0 (largest) to 8 (smallest), each associated with a particular use. The pens are gone; the vocabulary remains. When an engraver says 'Rastral 3', the meaning is immediate: 7.0 mm, standard parts, piano. No conversion required, no mental arithmetic. It encodes decades of professional judgement about what is legible at what distance for which purpose.
Picture
These values follow Gould (Behind Bars). Ross gives very slightly different numbers at some sizes – tenths of a millimetre – but Gould is the more recent authority and the more widely referenced in current practice.
Ooloi's sizing model is compositional. The base stave space propagates through a scaling chain – system, instrument, stave – where each level is a ratio against its parent. Change the base and everything follows. An ossia stave sits at two-thirds; a cue stave at three-quarters. The user works in ratios. The system reports the consequences in millimetres, with the approximate rastral equivalent alongside.

That last part is where the investigation led somewhere I hadn't originally planned. Once I had the scaling chain and the rastral table in front of me, the obvious next question was: should Ooloi simply display the effective size, or should it also say whether that size is appropriate for what the layout appears to be?

The answer, I think, is that it should. Wherever Ooloi reports an effective stave size – layout inspector, part configuration, print preview – the display will include a contextual assessment. Not just '7.4 mm (Rastral 2)' but whether that size makes sense for a flute part, or is slightly small for a piano reduction. The assessment will draw on published professional standards: MOLA puts 7.5 mm as the most readable size for orchestral parts, with anything below 7.0 mm unacceptable. The NZSO requires parts between 7.0 and 7.5 mm and rejects submissions outside that range.

The software will tell you what it knows. It will not prevent you from doing anything.
​
Rastral presets will appear on the base stave size control as named starting points, and again as targets when generating parts. Three places in total; nowhere else. The vocabulary will thread through the workflow without touching the architecture. A professional courtesy, not a load-bearing wall.
9 Comments
Peter Bengtson
29/3/2026 12:46:09

Clarification to the first five-line staff illustration: the 1.75 mm measurement is really from the _centre_ of each staff line, regardless of their thickness.

Reply
Roland Gurt
29/3/2026 14:17:40

What many scoring programmes get wrong in my opinion is the question of which notation elements should scale according to the staff size, and which should stay the same.

Specifically, line thickness of staff lines is roughly absolute in traditional engraving, meaning that a smaller sized ossia staff (or the solo instrument staff in a piano accompaniment part) has about the same absolute staff line thickness as the regular sized staves (which in turn makes it appear proportionally thicker).

The same goes for stems and ledger lines – they should be equally thick in grace notes as in regular sized notes (and not get thinner as the staff size shrinks, usually a dead giveaway that a score was computer-engraved).

Of course this would also apply to the glyphs themselves. I believe this is called "optical sizing" by Lilypond, one of the only programmes to get this right.

Reply
Malte
29/3/2026 15:24:36

Yes, LilyPond uses optical sizing: The Emmentaler font has eight font “sizes” for stave heights of approx. 11, 13, 14, 16, 18, 20, 23 and 26pt. IIRC the exact sizes are 20pt · 2^(n/6) with values from -5 to +2 for n.

I think this idea comes from TeX which has optical sizing with sizes of 10pt · 1.2^n.

Reply
Malte
29/3/2026 15:28:50

And if course both didn't invent this but mimick traditional typography/music engraving.

Peter Bengtson
29/3/2026 16:03:05

Roland, Malte – this is exactly right, and it touches a problem I have wanted to address for a long time. Anaemia in digital engraving is a long-standing problem, and this is one of the places where it surfaces most clearly.

The scaling chain described in the post governs the stave space, which determines symbol sizing and spacing. But line weights are a separate concern. In traditional engraving, staff line thickness, stem thickness, and ledger line thickness are near-absolute: they do not scale down proportionally when a stave is reduced. An ossia at two-thirds size has staff lines of roughly the same weight as the parent stave, which is precisely what gives reduced staves their visual solidity rather than that characteristic anaemic look. This of course has to do with the physical properties of the copperplate, like the total absence of sharp corners.

Optical sizing of glyphs is the deeper question, and Malte is right that LilyPond's Emmentaler is one of the few implementations to take it seriously. The principle goes back to punchcutting: a smaller letter is not a photographically reduced larger letter. Ooloi uses SMuFL fonts, which do not currently ship with optical size variants, so this will need to be addressed either through the font metadata or through rendering-time compensation. It's on the horizon, not yet resolved, and I'm glad you've raised it because it deserves to be visible.

Reply
Roland Gurt
30/3/2026 17:23:15

While SMuFL fonts might not ship with full-on optical sizes, it does (at least in its reference implementation Bravura) contain some "stylistic alternatives" for accidentals, clefs, flags, time signatures on smaller staves, as can be seen e.g. here https://w3c.github.io/smufl/latest/tables/standard-accidentals-12-edo.html

These are not used by Dorico yet as far as I'm aware.

Reply
Peter Bengtson
30/3/2026 22:23:27

Roland – yes, I'm aware of those alternates. Bravura's small-stave variants for accidentals, clefs, flags, and time signatures are exactly the kind of thing the glyph selection architecture (ADR-0048) is designed to handle: the three-level cascade (house style → piece → local) already filters by font availability, so wiring in the small-stave alternates where they exist is straightforward.

Where they don't exist, there may be another path. Skia – which Ooloi uses for all rendering – may allow continuous weight adjustment of glyph outlines at draw time: a slight boldening to compensate for optical thinning at reduced sizes. Whether this produces acceptable results at the fine tolerances engraving demands is an empirical question I haven't tested yet, but it's worth investigating as a complement to the discrete alternates.

Reply
Roland Gurt
3/4/2026 23:41:40

That sounds very interesting, as the black-white-balance of a page depends severely on balanced line weights across all elements. More substantial line thickness for staff lines, stems, barlines, ledger lines etc. (which are usually related by certain proportions as has been discussed) need a heavier text font weight like Medium or Semi-Bold (which many standard fonts don't have), but also the music font glyphs should be heavier. More recent SMuFL-fonts like VintageBH or the MTF fonts have come out in multiple versions of varying heaviness. More control in this area is always appreciated, though the user still has to dial in all settings prudently to come close to the visual harmony of traditional engravers toolkits. Thanks as always Peter!

Reply
Peter Bengtson
4/4/2026 11:39:34

Roland – I didn't know about VintageBH or the MTF weight variants. That's exactly the kind of development I need to be tracking, and I'll be acquiring those fonts to study how they handle the weight graduation. Thank you for the pointer.

On full control: yes, that is the intention, but the phrase deserves unpacking. Full control in most notation software means the parameters exist somewhere, usually buried in nested dialogs where you spend hours adjusting values whose visual consequences you can only judge after closing three windows and regenerating the layout. That's not control; to me, that's duct tape.

What I want is for the defaults to be correct – correct in the copperplate sense, where line weights, glyph proportions, and spacing produce the black-white balance that makes a page readable at a glance. And where they need adjustment, the adjustment should be immediate, visible, and musical: you change a value and see what it does to the page, in the context of the page, without leaving the page. Line and glyph thicknesses for grace notes, ossias and cues should be correct without requiring a degree in IT operations.

Hardware should bow to art, not the other way around.




Leave a Reply.

    Author

    Peter Bengtson –
    Cloud architect, Clojure advocate, concert organist, opera composer. Craft over commodity. Still windsurfing through parentheses.

    Search

    Archives

    April 2026
    March 2026
    February 2026
    January 2026
    December 2025
    November 2025
    October 2025
    September 2025
    August 2025
    July 2025
    June 2025
    April 2025
    March 2025
    September 2024
    August 2024
    July 2024

    Categories

    All
    Accidentals
    Alfred Korzybski
    Architecture
    Benchmarks
    Clefs
    Clojure
    CLOS
    Common Lisp
    DDD
    Death Of Igor Engraver
    Documentation
    Donald E Knuth
    Dorico
    Dynamic Programming
    Finale
    Fonts
    FrankenScore
    Franz Kafka
    Frontend
    Functional Programming
    Generative AI
    GRPC
    Igor Engraver
    Instruments
    Jacques Derrida
    JVM
    License
    LilyPond
    Lisp
    Localisation
    MIDI
    MPL 2.0
    MuseScore
    MusicXML
    Ooloi
    Ortography
    Pitches
    Playback
    Plugins
    Python
    QuickDraw GX
    Rendering
    Rhythm
    Rich Hickey
    Road Map
    Scheme
    Semiotics
    Sibelius
    Silicon Valley
    Site
    Skia
    Sponsorship
    Transposition
    UI
    Umberto Eco
    Vertigo
    VST/AU
    Wednesday Addams

    RSS Feed

Home
​Overview
Documentation
About
Contact
Newsletter
Ooloi is an open-source desktop music notation system for musicians who need stable, precise engraving and the freedom to notate complex music without workarounds. Scores and parts are handled consistently, remain responsive at scale, and support collaborative work without semantic compromise. They are not tied to proprietary formats or licensing.
​
Ooloi is currently under development. No release date has been announced.


  • Home
  • Overview
    • Background and History
    • Project Goals
    • Introduction for Musicians
    • Introduction for Programmers
    • Technical Comparison
  • Documentation
  • About
  • Contact
  • Home
  • Overview
    • Background and History
    • Project Goals
    • Introduction for Musicians
    • Introduction for Programmers
    • Technical Comparison
  • Documentation
  • About
  • Contact