​Madeleine never existed. Igor Engraver did.

Scottie reconstructs a performance designed to deceive him. I'm reconstructing software that worked perfectly well with the technology it had. Igor Engraver didn't die from technical inadequacy. It died from narcissistic neglect by guys with ponytails who couldn't see past their own reflections.

The architecture was sound. QuickDraw GX handled what we asked of it. Common Lisp did exactly what we needed. The software worked. What failed was human commitment, not technical capability.

Ooloi takes the same architectural vision and asks: what becomes possible when you're free of narcissistic partners and have access to genuinely better tools? The answer: not survival, but fulfilment of what was always possible.

​For, which is important: unlike Scottie, I'm not reconstructing the same woman. That's another significant difference. Igor's strengths lay in its ease of use and its user interface (and its playback, but that's another matter). Ooloi must go much further than Igor ever did in terms of typographical beauty, and it must do so from the first release.

​Bernard Herrmann's score for Vertigo doesn't just accompany the psychological state; it induces it. Those falling, spiralling arpeggios. Obsessive motifs that keep returning. Chromatic harmonies that never resolve. Lush orchestration that simultaneously feels unstable.

The music is Wagner's Tristan und Isolde transformed – the same chromatic restlessness, the same endless longing, the same refusal to resolve. Wagner created music about impossible love that could never find harmonic rest. Herrmann took that DNA and made it cinematic, made it about obsession itself rather than the object of obsession.

Years ago I quoted four measures from Herrmann's Vertigo in my opera The Maids – using his music about false love to underscore Genet's performed identities. Servants performing their mistress, performing revolution, performing each other. Identity as pure theatrical construction with no stable referent.

The circularity is almost too perfect: the composer of Vertigo scoring the film about vertigo, whose music I once quoted to mark falseness, now frames my own question – whether I'm caught in the same spiral of reconstruction.

But notation software can prove itself. Ooloi either handles Strauss's Elektra without freezing or it doesn't. It either supports real-time collaboration or it doesn't. Unlike Scottie's obsession, mine has to compile.

​This has always been the question. Vertigo asks it. The Maids asks it. Every recursive project asks it.

Is Judy really Judy if she becomes Madeleine? Was Madeleine ever real? Does performed identity become real identity through sufficient commitment? Is Ooloi Igor Engraver, or am I performing the identity of my younger self while building something entirely new?

Most programmers rebuild things pragmatically – new requirements, new tools, new project. But I'm asking whether I'm still the same architect when the materials have completely changed. Whether continuity of vision across technological discontinuity constitutes identity or elaborate self-deception.

The technical choices answer the question.

I preserved the idea: architectural vision, musical semantics, core abstractions, the fundamental insight that notation software requires deeper engineering than the industry has provided. But I let the implementation transform completely: Clojure instead of Common Lisp, STM instead of locks, GPU rendering instead of QuickDraw, immutable data structures, client/server architecture.

That's what genuine identity actually is: essential persistence through necessary transformation.

​Scottie's spiral destroyed him because the object was always false. The reconstruction was doomed because there was nothing real to reconstruct.

My spiral can succeed because the architecture was always sound; what failed was human commitment, not technical possibility. Igor Engraver died from neglect, not inadequacy. The guys with ponytails moved on. I did too,  from the circumstances. But not from the subject.

Twenty-five years later, the obstacles aren't technological maturity – they're human. I can build this alone, without partners whose narcissism exceeds their commitment. I can use tools that are genuinely better (Skia, STM, cloud architecture) without needing them to justify the project's existence.

The obsession is real. The vertigo is real – that uncanny feeling when you realise what was abandoned can be completed. The psychological pattern is acknowledged. But where Scottie's reconstruction existed purely in romantic space with no objective validation, mine has material proof: code that compiles, tests that pass, collaborative editing that actually works, Strauss's Elektra rendering in real time.

Identity is architectural continuity, through material transformation and human liberation. Not performance. Not even evolution. Completion.

The spiral passes the same point, but at a different height. This time, without the ponytails and the pop zombies.

​Vertigo remains my favourite film. I understand Scottie's obsession. I recognise the danger. But I also know the difference between reconstructing what was never real and finishing what should never have been abandoned.

The partners are gone. So are the commercial pressures. The new architecture holds. Herrmann's spiral ends in unresolved ascent – motion without final cadence. Ooloi's must too.

Research for Ooloi’s input system turned up something I hadn’t expected. Igor Engraver’s Flow Mode – the modal, stateful keyboard entry that defined its way of working – has never been recreated. Not by Dorico, not by Sibelius, not by Finale, nor by any of the open-source projects. Twenty-three years on, the idea has simply vanished.

Flow Mode was straightforward. You pressed “.” once and staccato stayed active; crescendos extended naturally as you continued writing. The commands mapped directly to the symbols – intuitive, fast, and oddly satisfying. When Igor died of business failure in 2001, the method died with it. There is no academic record, no terminology, no sign that anyone even remembered it existed. I had fully expected other programs to have copied this feature; it gives a five- to ten-fold increase in music-entry speed.

Web forums on notation are full of people asking for faster, more fluent keyboard entry, yet without the vocabulary to describe what they want. They are looking for something they have never seen.

So this part of Ooloi isn’t innovation; it’s recovery. The system worked. It was lost for reasons that had nothing to do with design. The decision to re-implement it, and the details, are now recorded in ADR-0032: Ooloi Flow Mode.
​
What remains is to implement it – and to find Magnus Johansson, who just might still have the user manual.

​Our solution was elegantly brutal: we seized complete control of attached MIDI units and employed pitch bend to achieve microtonal accuracy. This required distributing notes across MIDI channels according to their pitch bend requirements, using register allocation algorithms borrowed from compiler technology. In a chord containing one microtonally altered note, that note would play on a different channel from its companions. We changed patches frantically and maintained no fixed relationship between instruments and channels – everything existed in a kind of 'DNA soup' where resources were allocated dynamically as needed.

This approach let us extract far more than the nominal sixteen-channel limit from typical MIDI synthesisers. We maintained detailed specifications for every common synthesiser on the market, including how to balance dynamics and handle idiosyncratic behaviours. 

​The system's sophistication extended well beyond pure pitch calculations. When my opera The Maids was commissioned by the Royal Stockholm Opera, I spent considerable time crafting realistic rehearsal tapes. Everything I learned from that process was automated into Igor's playback engine.

We also collaborated with the KTH Royal Institute of Technology Musical Acoustics department, led by the legendary Johan Sundberg, whose research had quantified subtle but crucial performance characteristics. Those famous four milliseconds – the consistent temporal offset between soloists and accompaniment in professional orchestras – found their way into our algorithms. Such details proved particularly effective with Schönberg's Hauptstimme markings (𝆦) or similar solo indicators.

We also developed what my composer colleague Anders Hillborg and I privately called 'first performance prophylaxis' – a deliciously cruel setting that simulated the sound of musicians who hadn't practiced. In other words, the kind of sound landscape any composer is used to hearing at a first orchestral rehearsal of a new piece and which always makes you doubt your own talent. Turn this setting up, and you'd hear a characteristically dreadful youth orchestra. Turn it down completely, and you'd get the robotic precision that plagued every other MIDI system. Rather like Karl Richter's Baroque organ recordings.

The humanisation algorithms incorporated realistic instrumental limitations. Passages written too quickly for an instrument would skip notes convincingly. We modelled the typical rhythmic hierarchy of orchestral sections: percussion most precise, then brass, then woodwinds, with strings bringing up the rear. Instruments were panned to their proper orchestral seating positions. Piccolo trills were faster than tuba trills. The result was startlingly realistic, particularly by 1996 standards.

​Now, twenty-five years later, that laundry basket discovery has culminated in ADR 0026: Pitch Representation and Operations, documenting Ooloi's comprehensive pitch representation system. The original Common Lisp has been reborn as Clojure code, with string-based pitch notation ("C#4+25") serving as the canonical format and a factory-based transposition system supporting both chromatic and diatonic modes.

The string representation offers several advantages: compact memory usage for large orchestral scores, direct human readability for debugging, and seamless integration with parsing and caching systems. Most crucially, it supports arbitrary microtonal deviations, something that remains problematic in most contemporary notation software.

The factory pattern generates specialised transposition functions that encapsulate their musical behavior rules through closures. Rather than repeatedly passing configuration parameters, the factory creates efficient, composable functions that understand their specific musical contexts. A diatonic transposer preserves letter-name relationships; a chromatic transposer produces frequency-accurate results with canonical spellings.

The t-shirt in my laundry basket represented more than nostalgic memorabilia; it was unfinished business. That higher-order function embodied a sophisticated understanding of musical mathematics that took a long time to develop and seconds for an AI to recognise as architecturally significant.

Now, with Ooloi's pitch operations properly documented and implemented, that business approaches completion. The code has evolved from promotional garment to production system, carrying forward those insights from 25 years ago into a new, modern technological context.

It's exciting. And still a little unnerving.

​Igor's demise taught me harsh lessons about market timing. When you create genuinely superior tools because existing software actively gets in your way, you discover that technical excellence alone can't guarantee survival.

Igor actually started as freeware – that was my original vision. The VCs wanted features, revenue streams, market capture. I wanted musicians to have tools that actually served their creativity. The collision between these fundamentally incompatible visions, plus the economic chaos after 9/11, killed what could have been transformative.

That experience shaped every decision in Ooloi. This time: transformation through collaboration rather than zero-sum market battles.

The MPL 2.0 licensing reflects this philosophical approach. The core backend becomes commoditised infrastructure; commercial value migrates to sophisticated interfaces, proprietary plugins, premium workflows. What traditional systems charge for – collaboration, large ensemble support, quality rendering – becomes architectural givens.

This isn't theoretical. Martin Keary (Tantacrul), who heads MuseScore development, had been interested in Igor Engraver as a young composer. When we discussed our open source projects, the conversation was refreshingly direct: 'Well, feel free to help yourself to whatever's useful when it goes open source​' – 'Likewise!' Both projects share the belief that notation software shouldn't cost students hundreds of pounds.

This is precisely what I want – for the code to be used, extended, transformed. The platform approach only works if others build on it. That's not threat; it's the point.

​The irony isn't lost on me that companies who once viewed architectural advances as existential threats might ultimately benefit from them. I still recall Sibelius management phoning after Igor's demise to enquire about my plans – ensuring no resurrection attempts, obviously.

Should those companies adopt approaches they once feared, the satisfaction would be collaborative rather than competitive. Success through enabling others, not defeating them.

​Of course, this depends on Ooloi actually working. Functional programming should provide significant performance benefits, but what happens with complex layout calculations across a hypercomplex 100-staff score by Brian Ferneyhough (whom I had as guest teacher at the Royal College of Music in Stockholm back in the day) whilst maintaining real-time collaboration?

The arrogance in predicting that these approaches will outperform decades of commercial development is considerable. My instincts could be spectacularly wrong – though they've been reliable enough to spot architectural dead ends before they become obvious to everyone else.

That's the architect's bargain: trust your reasoning, build on principles, prepare to be surprised.

"Next-generation" gets thrown around as a PR term so casually it's meaningless. If Ooloi genuinely represents next-generation architecture, that should be inherent in the platform design rather than claimed through marketing. The question isn't whether Ooloi calls itself next-gen, but whether others build on it in ways that would have been impossible previously.

Perhaps this time, it might be composed collaboratively.

Ooloi isn't here to "disrupt" anything. I despise that cheap neoliberal selfishness. It aims to transform, to evolve, to open possibilities. But there's no will to conquer — it's simply not in its DNA.

It's been five months since my last update on Ooloi – or FrankenScore, as it's still known in its pre-release incarnation. This silence wasn't planned; rather, it happened because life got in the way. A demanding day job, a significant career change – we had to liquidate Delegat AB and I had to find a new job as a principal-level AWS Cloud Architect – and other responsibilities all conspired to slow Ooloi's momentum.

​I won't bore you with excuses – sometimes one simply must pause to change course, and I really needed to devote all time and mind space to finding what I hope is my final employment. Now that I've secured a great position with HiQ in Stockholm, I can return to Ooloi with full force.

Five months of relative silence offers time to think. Perhaps there's value in stepping back from the constant pressure to show visible output. In such moments, the architecture is refined not through frantic coding but through careful consideration.
​
The journey from Igor Engraver to Ooloi spans decades, and a few months of slower progress hardly register on such a timescale. What matters is that the vision remains clear and the foundation solid.

After all, the whole purpose of the Ooloi project is not to "disrupt the market". Like Octavia Butler's ooloi aliens, we're neither aggressive nor competitive. What is important, however, is doing this right using modern tools. The idea is to create an architecture and a platform that'll last and that musicians and publishers will want to use.

It's also to provide a powerful environment that can be easily extended through any JVM language. Ooloi has a tight, lean and efficient core, organically and seamlessly  augmented by a flora of plugins for any vertical. This would include jazz, early music, tablature, etc - but also commercial plugins to support things like virtual instruments, extremely intelligent playback, or perhaps GenAI used for musical purposes. The idea is to shift the initiative to the users, not to a central committee trying to anticipate user needs.

Ooloi is designed for flexibility and efficiency. Uniting these two aspects sucessfully requires careful architectural design. (And a language like Clojure for the core and the JVM for the plugins.)

With the core architecture stabilising, I'm thinking more about community. Ooloi is intended as an open-source project, a collaborative effort that will benefit from diverse perspectives and expertise.

The extensive documentation work completed earlier – including the architecture decision records, READMEs, and technical specifications – was not merely for my benefit. It prepares the ground for future collaborators, creating a clear map of the territory for those who will join us.
​
The website, this blog, and the growing collection of documentation all serve as beacons for those who might be interested in contributing. They signal our commitment to transparency and proper communication – essential ingredients for any successful open-source project.

Five months of comparative quiet doesn't mean I've abandoned ship; it simply reflects the natural ebb and flow of a project undertaken alongside life's other commitments. Ooloi continues to grow, perhaps not as swiftly as in those heady initial weeks, but with steady purpose nonetheless.

I'm reminded of how musical compositions themselves develop – sometimes in great creative bursts, other times through careful refinement of existing material. Both approaches have their place.

To those following Ooloi's progress, thank you for your patience. The work continues, and updates will come more regularly as we approach the milestone of public release. The vision of a modern, efficient, and elegant music notation system – one built on sound architectural principles and open to community collaboration – remains as compelling as ever.
​
Until next time (which will be considerably less than five months hence),
/ Peter

​FrankenScore is our current working title. It's fitting for now, as I'm essentially stitching together old ideas with new ones in a highly charged electrical atmosphere somewhere in a metaphorical Transsylvania. But as the project progresses, it's clear this isn't just resurrecting or recombining; it's the creation of something rather different.

When we go open-source, the project will become Ooloi.

For those unfamiliar with Octavia Butler's work, the Ooloi are alien beings with a knack for genetic manipulation and transformation. It's a decent metaphor for what we're doing: taking the DNA of music notation software and turning it into something new. 

This future name change isn't mere whimsy. Where FrankenScore suggests our current closed-source phase of experimentation, Ooloi represents what comes next. It's organic, sci-fi, modern, mind-bending. A bit like the software itself, one hopes.

Ooloi is also just a good name. It's odd, memorable, and stands out in a field not exactly known for its naming creativity. 

So, there it is. When this project eventually emerges from its closed development, it'll do so as Ooloi. A name that, with any luck, will suit the software it represents.

The metamorphosis is coming. Eventually.

FrankenScore is still private. There is a number of things that need to be in place before the project can go public and I can start inviting collaborators, so let's touch a little on names, releases and versions.

At this stage I'm finalising the robust, high-performance platform for ACID-compliant transactions which forms the basis of everything in FrankenScore and is manifested through the backend API.

FrankenScore becomes Ooloi when released as open source. But the first release doesn't need to be Ooloi 1.0, which by definition would be feature-complete. In fact, it should be Ooloi 0.n with an n as low as possible, meaning it's best to go public as early as possible, yet feature-complete enough so Ooloi's promise is immediately apparent.

Here's a very rough project plan:

1. Finalise the API (nearly done)
2. Implement File Persistence using Fressian (saving and loading pieces)
3. Implement gRPC Layer and Event Handling (for communication between the backend and the frontend)
4. Create Initial Frontend with Hello World Window (proof of concept)
5. Implement printing in the frontend client (of the Hello World Window)
6. Implement enough of the frontend/backend interaction so that a score can be set up and simple elements can be entered and manipulated. This is an complex. multi-step process that also involves setting up event handling in the frontend. It's the basis for everything that is to come and must be rock solid.
7. Implement measure reformatting locally for measures according to a simple linear method that will be upgraded later
8. Implement backend reformatting and reflow of measures over systems and pages
9. Iteratively add more notational elements and features until Ooloi 0.n can be released, meaning that the project is released as open source.
10. After the release, adding more notational elements continues in parallel with the remaining points:
11. Implementation of a more advanced measure formatting algorithm
12. Implementation of the plugin system.
13. Implementation of an open source plugin for simple MIDI in- and output.
14. Implementation of an open source plugin for reading and writing MusicXML files.
15. When all notational elements are supported, Ooloi 1.0 can be released.

​So, point 9 represents the point where the project goes public and Ooloi 0.n appears. It remains to be seen how feature-complete the notation must be to confidently take that step.

However. There might of course be room for collaborators in the project before the public release as open source, as there are points in the above list that cover isolated features that could be delegated to an experienced Clojure programmer. Hmm. Let's think about that.

Twenty-five years ago, I embarked on a journey to revolutionise music notation software with Igor Engraver. Today, I'm resurrecting that spirit with FrankenScore. But why now? Why breathe new life into a project that's been dormant for a quarter-century?

A Vision Deferred

Igor Engraver was always meant to be freeware, a tool for musicians and composers to express their creativity without financial barriers. Commercial considerations, however, steered us away from that vision. Now, with FrankenScore, we're returning to those roots by embracing open-source development. This aligns with my original intentions and the spirit of accessibility that drove Igor Engraver's creation.

The Tech Landscape: Then and Now

Back in '96, when Igor Engraver was born, the technological landscape was vastly different:

• OS X hadn't been released
• Most computers were single-core
• Software was largely platform-specific
• Clojure, our chosen language for FrankenScore, didn't exist

Today, we have multi-core processors, cross-platform development tools, and languages like Clojure that offer powerful abstractions and concurrent programming models. These advancements allow us to build FrankenScore as a more robust, efficient, and flexible tool than was possible with Igor Engraver.

The State of Music Notation Software

Igor Engraver was conceived because the available options at the time – Finale (as user-friendly as a cactus) and Sibelius (marginally better) – weren't up to the task. They fell short in usability, flexibility, and output quality.

I hated using Finale (and I've written an entire opera in it). Instead of enhancing your creativity – which, at the end of the day, is what a music processor should do – Finale and all other similar programs hampered your creativity.

Surprisingly, a quarter-century later, the field hasn't progressed as much as you might expect. While there have been improvements – some of them clearly inspired by Igor Engraver! – there's still a significant gap between what's available and what's possible.

Why FrankenScore, Why Now?

The time is ripe for FrankenScore, and I can't help but feel a sense of excitement and purpose. We're at a unique intersection of technological readiness and persistent unmet needs in the music notation world. The tools and platforms available to us now make it possible to build something truly revolutionary – a modern, efficient, and cross-platform solution that was merely a dream when Igor Engraver was conceived.

What strikes me is how, despite the passage of time, the music notation software landscape still leaves much to be desired, especially in terms of usability and flexibility. It's both frustrating and motivating. But here's the kicker – we now have this thriving open-source ecosystem at our fingertips. It's the perfect environment for collaborative development and continuous improvement, something I could only have wished for back in the day.

There's also a personal element to this timing. I feel a renewed focus, unburdened by the commercial constraints that ultimately derailed Igor Engraver. We can, as a community, now pour our energy into creating the best possible tool for musicians and composers, staying true to the original vision of accessibility and innovation. And you know what? Those years weren't wasted. The experiences from Igor Engraver – our successes, our setbacks, the lessons learned – they're all invaluable insights that we're bringing to FrankenScore's development. It's like we're picking up where we left off, but with 25 years of additional wisdom and technological advancements in our toolkit.

FrankenScore isn't just a revival; it's a reimagining. We're taking the core ideas that made Igor Engraver revolutionary and implementing them with modern technology and development practices. Our goal is to create a music notation tool that's not just incrementally better, but fundamentally transforms how musicians interact with notation software.

We're excited to embark on this journey, and we invite you – musicians, developers, and enthusiasts – to join us in shaping the future of music notation software. Together, let's bring Igor Engraver's vision to life in FrankenScore.