Since the last diary instalment just before Christmas, another three months has very nearly sped past, and as winter finally gives way to spring here in London, we can reflect on the progress we have made over the dark and cold months now behind us, and look forward to the work that still lies ahead.
It’s been a long time since the last entry in this diary, and as the year draws to its close, I know there is an appetite for news on how our project is progressing. I hope this update will bring you some festive cheer and excitement for the year ahead.
After the last instalment’s detailed discussion of beam grouping and sloping, today’s development update is going to focus on some of the issues around laying out a page of music, in particular working in the horizontal dimension, including casting off and justification.
Very nearly two years since my last appearance on the SoundNotion podcast, hosts David MacDonald, Nate Bliton and Sam Merciers invited me to return this past weekend to give an update on how things are progressing. In the hour-long conversation we covered a wide range of topics, including how our new application can help with building an understanding of music theory as well as music engraving, and a variety of new tidbits about what we’ve been working on… plus how much older (and in my case, how much beardier) we all look two years on from our last conversation.
You can watch the podcast on YouTube, listen to the audio via the SoundNotion web site, or if you would like to listen to new episodes of SoundNotion weekly, search for it in your podcast application to subscribe. Enjoy!
As a wise man once said, there are as many rules of music engraving as there are music engravers. This is a joke, of course, but perhaps only half of one: although there are certain aspects of how music notation should be presented that more or less everybody can agree on, there are many more that provoke lively debate.
One of these latter areas is beaming; specifically, the placement of beams relative to stave lines, and the amount of slant or slope that should be applied to beams given notes of different pitches, the amount of horizontal space occupied, and so on.
Advance warning: this post goes into a lot of detail about subtle aspects of engraving practice concerning beam placement. Engraving nerds only need apply.
As the year draws to a close, thoughts naturally turn to the events of the past twelve months, and indeed to the promise of the year ahead. For us, the past year represents a lot of forward progress on our project, but the year ahead will bring more milestones on the road towards the release of our new application.
A year ago, we were around nine months into the development of the music engine at the heart of our application, but really had no functional application to speak of: we had a test harness that could display only (unbeamed) notes and rests imported from MusicXML, but nothing in the way of interaction. Over the past year, we have chosen and adopted a new application framework, introduced the basic editing loop, built the skeleton of a functional application, developed our step-time input method, added grace notes to our music model, added ties, articulations, ledger lines, time signatures, key signatures, clef changes, accidentals, beams, and so on, and so on.
We are still building up the core of our application’s functionality, but our approach remains to focus above all on quality, rather than speed. If our application is going to be worth the time and attention of professional composers, arrangers, engravers, copyists, and teachers, then it must not only have a critical mass of features, but it must also have both a more efficient workflow and a faster path to excellent results than the tools professionals are already using. That’s a high bar for us to meet, but we are determined to clear it.
Don’t get me wrong: we are going as fast as we can. But we are committed to developing an application that will redefine the state of the art in scoring software, and that can’t be done overnight.
Enough with the ghost of Christmas future. Let’s talk about the ghost of Christmas past – what we have been working on since the last instalment of this diary at the end of September.
As summer gives way to autumn here in London, it’s time for another update on our progress. As the photo above shows, there is great satisfaction to be gained from lining things up just so. In this post, I’m going to discuss two of the areas in which we have expended tremendous effort in ensuring our automatic engraving produces as many of these moments of satisfaction as possible.
It’s been almost three months since the last instalment in this series, so it’s high time for another update on our progress. In this update, as promised I will share some information about our music font, Bravura, and the project we have been leading to standardise the layout of music fonts, and some insights into how we are going to build the user interface for the new application.
In the last update, we started discussing some of the individual engines that are under development to handle atomic notation and engraving tasks, and I described the engines for note and rest grouping, and positioning rests in multiple voices. Let’s take a look at another couple of little engines that could.
All of a sudden, over the past week I have received lots of requests for an update on our progress, so here we go. My last update was at the start of November, on the occasion of the first anniversary of our team joining Steinberg. This new update comes more or less on the occasion of the first anniversary of us starting to write our new scoring application. We’ve made a lot of progress in a year, but we still have a long way to go before the product will be in your hands.
In my last update I described the high-level design of the musical brain at the heart of our application: lots of individual engines performing single tasks, some dependent on one another, others running independently. This design approach allows us to break down the immensely complex problem of how to correctly notate and lay out music into smaller, more manageable chunks, and also provides the opportunity for these little engines to be designed and implemented independently, and eventually to run in parallel (unless an engine is dependent on the output of another engine, of course).
I described in broad terms the first couple of such engines that we had implemented already: determining the staff position of a note (taking into account clef, transposition and octave shift), and determining the stem direction of a note (taking into account staff position and musical context). We were also starting to embark on engines to handle note and rest grouping, and to position rests in multiple voices correctly. Over the next couple of posts, I’ll talk about these engines, together with a few other new ones we have developed since the last update.