We did not set out to build a product for sheet music. It began with something simple: printing PDF scores and filing every page in a binder was a chore.
Paper scores were such a hassle that I bought an iPad
In 2017, I bought an iPad hoping I would no longer have to do it. That was already nine years ago.
Viewing PDF scores on an iPad was clearly more convenient. I no longer had to print them or sort a growing stack of paper into different binders. Simply carrying every score I needed on one device was a substantial improvement.
But once choir rehearsal started, another problem emerged.
Rehearsal was a constant search for the right place
Whenever we repeated a passage that was not going well, we looked for the measure number. When the conductor said, “From A,” we searched for the rehearsal mark A. When we reached a repeat sign, we scanned the score again to find where we needed to return.
Paper had become a screen, but rehearsal was still a continuous search. Each choir member had to locate in their own score the place the conductor was already looking at. If someone lost their place, it took even longer for everyone to look at the same point and sing together again.
That led to a question:
What if everyone could see the place in the score that the conductor was looking at?
Opusis did not begin as an attempt to eliminate paper scores. It began as an effort to help the whole choir see the same place in the same score, spend less time searching, and focus more on singing.
A problem PDFs alone could not solve
PDF was enough to move a paper score onto a screen. But to identify the current position and the structure of a score, then show that position on several screens at once, we had to treat the score as musical information rather than an image or a set of pages.
MusicXML was the most practical choice because it represents the structure of a score and works across many notation programs.
The first prototypes and the WebView wall
Even while busy with other work, I built prototypes in several different ways. I also tried using open-source libraries to display MusicXML scores.
The libraries I found at the time were built on HTML5 and JavaScript. Using them in an app required a WebView. I was already familiar with Android WebView performance issues from previous projects.
When I rendered a score, the performance problems I had worried about were less pronounced than expected. But controlling the view the way I wanted remained difficult.
I had the idea, but I could not turn it into something I could keep developing. For a long time, the thought that became Opusis remained somewhere between my head and a series of prototypes.
One of them was a simple experiment that highlighted notes in the score as playback advanced.
Then came the age of AI
In 2026, with about five months of parental leave remaining, I wanted to do something meaningful before returning to work. The idea that had stayed in my head for years came back to me.
In the meantime, the environment for building software had changed significantly. AI was quickly becoming part of how software was built.
When building a product in spare moments, getting stuck once made it costly to pick the work up again.
AI did not remove the complexity of music notation. Nor did it understand the problems of choir rehearsal or complete the product on its own. What it did was give me room to revisit an idea that had stalled years ago, try possible approaches quickly, discard the ones that failed, and move on to the next.
The idea that began in 2017, when I bought an iPad because I did not want to print scores and file them in binders, was taking shape as a product again.
What Opusis aims to create is not simply a digital replacement for paper scores. It is a rehearsal environment where conductors and performers can look at the same place and focus on making music together instead of searching through the score.
The problem I first saw in a choir also exists in orchestras and many other kinds of ensembles. Anyone rehearsing from a shared score spends time finding and communicating the same position.
Today, this is how that idea takes shape in Opusis. The leader view is on the left and the performer view is on the right. When the leader moves to a position in the score, a red vertical line and highlight appear at the same position on every performer's screen.
Creating this view meant revisiting the score-rendering technology that had previously hit the WebView wall. The next post will cover the process of porting VexFlow and OSMD to Dart.