 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. 
0 Comments
 A recent question in the Clojurians Slack channel caught me off guard when I was asked to compare FrankenScore to Sibelius. This request for a direct comparison not only made me pause but also brought back memories of Igor Engraver's rivalry with Sibelius – a competition that once saw Sibelius's own CEO defect to our side. However, that was a long time ago. Now, as FrankenScore carries forward Igor's legacy, I was challenged to articulate our unique value proposition in this new era. Here's how I responded: NN:
Hey, that looks promising! What are the advantages it will have compared to Sibelius? Peter Bengtson: Wow, that's actually a pretty multi-faceted question. While we're still in development and can't yet offer a feature-by-feature comparison with Sibelius, I can highlight some key advantages we're aiming for:
Importantly, as an open-source project, FrankenScore will be free to use. Many music departments struggle with excessive license costs. For those interested in more details, ooloi.org contains a wealth of information about the project, its goals, and its technical underpinnings.
 An Architecture Decision Record (ADR) is a point-in-time document that records architectural decisions and the reasoning behind them. And since communicating architectural ideas clearly to collaborators is extra important in open-source, I've just added a bunch of ADRs to the Documentation page.
They cover various aspects of the FrankenScore architecture, from high-level design decisions to specific technical choices. They are:
 In the past weeks, I've been focused on FrankenScore's core architecture. I'm not rushing to open-source this; instead, I'm taking my time to craft a solid platform that will do the heavy lifting for future users and collaborators. All the complexities involving data representation and manipulation in a multi-threaded environment must be solved so collaborators can concentrate on the essentials. Clojure is ideal here, just as Common Lisp was the clear choice for Igor Engraver back in 1996.
Key developments: 1. The API is now fully polymorphic and can be used in the same way internally in the backend as in the frontend. There is a system of pointerless vector path descriptors (VPDs) implemented for this purpose that all API operations can accept as part of their polymorphic setup. I wouldn't be surprised if core collaborators will use the API for internal purposes as well, as it is highly efficient and exposes the underlying functionality in an abstract, domain-specific way. There should be little need to go directly to the underlying data structures, at least not for speed - and certainly not for expressivity. This also bodes well for plugin development in other languages than Clojure, which is an important feature. 2. This beast is fast. Clojure's STM facilities ensure high-speed ACID-compliant transactions with automatic retries. They are also composable. This means that plugins can bombard the backend with hundreds of thousands of mutation requests, for instance to implement MusicXML, with the same efficiency as the pure Clojure backend. 3. Piece Manager Implementation: There's now a Piece Manager, providing functions for storing, retrieving, and resolving pieces from IDs. This allows for multiple clients to work simultaneously on the same piece in a distributed arrangement. The FrankenScore backend can run in the cloud with multiple people collaborating on the same piece. Multiple pieces can be open simultaneously to allow copy-and-paste operations between them. My next steps involve implementing file persistence (saving and opening music files), as well as tackling printing. These are foundational features, not mere add-ons. Persistence forces a clear definition of the data model and enables easier testing. Printing isn't just about output; it's about representation and serves as a sanity check on the entire system design. Both will likely inform further refinements of the core architecture, potentially revealing oversights or opportunities for optimisation. Additionally, sequencing is a crucial part of the core platform. And by sequencing I mean support for converting musical representations to timed sound events - though not necessarily via MIDI; a software synth may use direct means of control, for instance. The core sequencer can be used by plugins to generate MIDI, or to input MIDI, but the actual MIDI implementation will be done in the plugin layer. But that's a whole blog post of its own.  Finale is finally being discontinued. The reason is simple and technical in nature: after 35 years, its codebase has become exponentially more difficult to maintain, and it's now reached the point where the returns of any effort spent on it have diminished to the point where they have vanished entirely. There is a crossgrade to Dorico being offered at a fairly low price, and the Finale installer will work for some time yet, but there will be no more updates, and in a year's time Finale will be completely dead as new installations no longer can be activated. After that it's only a question of time until operating systems change beyond the point where they'll support old code no longer updated for them. Read more here: https://www.finalemusic.com/blog/end-of-finale-new-journey-dorico-letter-from-president/ This composer's take on the situation and on the available alternatives is interesting. It's clear that not much has changed in the way of user-friendliness and note entry methodology even in more modern programs, and that the learning curve still is steep. In a way, that's great news.  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.   Gustav Mahler's summer composition hut The past four weeks have been a whirlwind of productivity. Enjoying a deep creative flow, I've really been wind-surfing through parentheses as I've been working almost around the clock on FrankenScore. The results have been surprising:
This initial rush has successfully got FrankenScore off the ground, building a strong foundation in record time. However, as my holiday draws to its close and my day job with Delegat AB resumes, the pace will inevitably slow down a little. The timeline for releasing FrankenScore as open source depends on several factors, including the presence of internal collaborators before the public release. While the foundational work is largely complete, the project will continue to evolve at a steadier pace. If I'm left entirely to my own devices without any pre-release assistance, I should say the public open source release of Ooloi 0.x will happen in about a year's time. With collaborators, in about six months or so. But this is difficult to gauge with any exactness, as there are so many variables involved. Also, after going public, remember Ooloi won't be finished by any means. That's when the journey begins in earnest, travelling the distance from Ooloi 0.x to 1.0. But then we'll be travelling as a group. Anyway, there'll be regular status and road map updates on this blog. I'll keep you posted.  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:
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:
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.  (Oh, and by the way, FrankenScore is just a pre-release working name. When we open the repo, make it open source and invite collaborators to participate, we will switch to Ooloi, just like the domain you're on right now. I'll explain the reasons in a later blog posting.) |
AuthorPeter Bengtson –composer, organist, programmer, cloud architect. Currently windsurfing through parentheses. 
Archives
September 2024
Categories
All
|
RSS Feed