 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. Where We StandDespite the public quiet, work has continued, albeit at a more measured pace. The foundational architecture – that robust, high-performance platform for ACID-compliant transactions – remains solid. I've made incremental improvements to the core API, particularly in how it handles complex musical structures through our vector path descriptor (VPD) system. The polymorphic API is now fully mature, offering a consistent interface whether used internally in the backend or remotely by the frontend. This uniformity will prove invaluable both for our own development and for future JVM plugin creators, who'll benefit from the significant abstraction it provides. File persistence using Nippy has been fully implemented, creating a solid foundation for saving and loading pieces. This might seem a mundane milestone, but anyone who's worked with complex software knows that solid persistence mechanisms are like plumbing – unglamorous but absolutely essential, and you certainly notice when they're missing. File persistence, like high-quality printing, should be implemented early in the development cycle as they can be devilishly difficult to just tack on later. They also provide an acid test for the whole architecture. A Bit of ReflectionFive 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.) Community BuildingWith 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. Looking ForwardSo what comes next? The gRPC layer for communication between frontend and backend remains a priority. This is the bridge that will allow the beautiful architecture we've built to manifest in a usable form for musicians and composers. Following that, the initial frontend work – that "Hello World" window that will serve as proof of concept – beckons. While the backend architecture is undoubtedly important, it's through the frontend that users will experience Ooloi. Getting this right is crucial. The SMuFL integration for standard music font layout continues to progress, ensuring that Ooloi will render beautiful notation with consistency across platforms. Challenges and OpportunitiesEvery project faces challenges, and Ooloi is no exception. Time constraints remain the most significant hurdle, as this is still predominantly a one-person effort with limited hours available. There's also the natural tension between getting it right and getting it done. The perfectionist tendency can be both a blessing and a curse in software development. While it drives us towards excellence, it can also delay progress if not properly balanced. The task here is to create a platform for music processing and notation. This balance has to be exactly right so that contributors can treat Ooloi like a music notation OS rather than just a bunch of API endpoints. I think the balance is right; it's looking very promising. Yet within these challenges lie opportunities. The time spent refining the architecture will pay dividends in the long run, creating a more solid foundation for future development. A Call to Potential CollaboratorsAs Ooloi progresses toward its eventual public release, I'm increasingly aware of the need for collaborators. If you're a Clojure programmer with an interest in music notation, or a musician with programming skills, your perspective could be invaluable. While we're not yet at the point of opening the repository – though a "soft release" isn't out of the question – I welcome conversations with those who might be interested in contributing once we do. The journey from FrankenScore to Ooloi – from private project to open-source collaboration – will be richer for having diverse voices involved from the early stages. Closing ThoughtsFive 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
0 Comments
 When I started programming in Lisp in 1979, after reading an article in BYTE Magazine, I hardly imagined that 45 years later I'd be embarking on a new Lisp adventure. Yet here we are, with FrankenScore (to be renamed Ooloi upon open-source release) – a modern music notation software built with Clojure. It's a project that brings together all my lifelong passions: music, programming, and the pursuit of elegant solutions to complex problems. The Path from Common Lisp to Clojure My journey with Lisp began in an era when optimising Common Lisp compilers were cutting-edge technology. I cut my teeth implementing Common Lisp interpreters and compilers (as one did in those days), delving into the intricacies of a truly original programming language. This experience shaped my understanding of what a powerful, flexible programming language could be. And now in 2024 I find myself in the world of Clojure, a modern Lisp dialect that runs on the Java Virtual Machine. The transition feels both familiar and novel. Clojure's emphasis on immutability and its handling of concurrency through Software Transactional Memory (STM) aligns with the functional programming principles I've long appreciated in Lisp. But it's not just about the language. The ecosystem around Clojure – the JVM, the interoperability with Java libraries, the rich set of tools and frameworks – provides a robust foundation that we could only dream of back in the Common Lisp days. CLOS Thinking in a Clojure World One of the more interesting aspects of this transition has been adapting CLOS-style thinking to Clojure's more data-centric approach. CLOS, with its powerful multiple inheritance and method combination features, encouraged a certain way of modelling problems. In FrankenScore, I've found myself reaching for these familiar patterns, but implementing them in Clojure's more functional style. For instance, the use of Clojure's protocols and multimethods, combined with hierarchies and the Methodical library, allows us to achieve CLOS-like polymorphism. It's a different approach, but one that feels natural once you embrace Clojure's philosophy. Clojure's deliberate avoidance of traditional object-oriented features felt immediately familiar and refreshing. It resonates with CLOS's approach, which many, including myself, have long regarded as transcending traditional OOP. Composition over inheritance, a principle I always valued even in the CLOS days, is not just a best practice in Clojure but the very fabric of its design philosophy. This alignment between CLOS's advanced features and Clojure's functional paradigm makes the transition feel natural and even inevitable. Changes in ThinkingPerhaps the most significant shift has been in embracing Clojure's emphasis on immutable data structures and pure functions. While these concepts weren't foreign in Common Lisp, they're central to Clojure's design. This shift encourages a style of programming that's inherently more thread-safe and easier to reason about – crucial for a complex application like FrankenScore. Another major change has been adapting to Clojure's more minimalist standard library compared to Common Lisp. This has led to a greater appreciation for carefully chosen, interoperable libraries and a more modular design approach. SimilaritiesDespite the differences, there are of course similarities in the overall approach. The emphasis on interactive development, the power of macros for domain-specific languages and the elimination of boilerplate code, plus the satisfaction of working in a dynamic, expressive language – these are all as present in my Clojure work as they were in my Common Lisp days. Moreover, the focus on solving complex problems through abstraction and composition remains. Whether it's CLOS or Clojure, the goal is still to create systems that are powerful, flexible, and pleasant to work with.  Closing ThoughtsThis journey from Common Lisp to Clojure, from Igor Engraver to FrankenScore/Ooloi, is both challenging and rewarding. It's a testament to the enduring power of Lisp's ideas and the continued evolution of programming languages.
As I continue to develop FrankenScore, I'm captivated by the possibilities that Clojure and its ecosystem offer. While creating a powerful music notation software is the immediate goal, the project's scope extends far beyond that. It's an exploration of the synergies between music, technology, and open-source collaboration – a playground where these elements intersect and interact in novel ways. To those considering a similar journey, I'd say: embrace the change, but don't forget the lessons of the past. The parentheses may look familiar, but the world inside them is ever-evolving.  As I windsurf through parentheses on my holiday, reviving the spirit of Igor Engraver in the form of FrankenScore, I'm struck by a profound realisation: this is how programming should always feel. Free. Uplifting. Intellectually stimulating. A far cry from being shackled to the oars of enterprise galleys, with some middle manager shouting "ATTACK SPEED!" at bewildered code monkeys. But why should this freedom be a holiday exception? As programmers (not "developers," please!), we should be grounded in computer science thinking. We need to regularly return to these ancient founts of wisdom, like Lisp, and apply their lessons to our everyday work. Otherwise, we're just highly paid button-pushers in a digital sweatshop. Remember when computer science curricula started with Scheme? It wasn't about the language; it was about learning to think algorithmically. Then Oracle, in its infinite wisdom (read: hunger for "cannon fodder"), saw Scheme replaced by Java Enterprise. And thus began the great shitshow that's lasted for decades. Yet, for all its faults, we must tip our hats to Java for gifting us the JVM. And here's where Clojure enters, marrying Lisp's elegance with the JVM's robustness and interoperability. It's like finding out your eccentric uncle and strait-laced aunt had a brilliant love child. But thanks to the JVM, your weird uncle can now fit into the enterprise world. Diving into Clojure led me to Rich Hickey's talks. The man veers into philosophical territory faster than a Silicon Valley startup pivots to blockchain. He ponders things like what names are, and why we use them - essential musings for any first-class programmer. It reminds me of my friend Niklas Derouche, architect and coder extraordinaire, who insists you must read Derrida to be a proper architect. Because nothing says "I understand this codebase" like a healthy dose of deconstruction theory. And he is right. Make no mistake. In three weeks of holiday hacking, I've made more progress and felt more fulfilled than in months of enterprise work. It's a stark reminder of what's possible when we shed unnecessary constraints and return to first principles. So, fellow coders, I challenge you: When was the last time you felt truly free in your programming? Perhaps it's time we all took a holiday to rediscover the Lisp arts. Who knows, you might just find your programming parentheses - I mean, paradigms - shifted. P.S. If you're about to comment that 'modern' languages and frameworks are just as good, save your breath. I'd sooner believe in the tooth fairy than in the supposed superiority of JavaScript or the 'agility' of SAFe. P.P.S. If you missed the Ben Hur reference (you uncultured git), this is sprint execution according to SAFe, with the CTO watching: |
AuthorPeter Bengtson –composer, organist, programmer, cloud architect. Currently windsurfing through parentheses. 
Archives
March 2025
Categories
All
|
RSS Feed