It’s been four months since I last provided an update on our progress in building our new scoring application, so I thought it was about time to lift the curtain a little bit and give you some idea about what we’ve been working on. Warning: this post is pretty nerdy, and very long… and it only covers April and May.
The image above is our project timeline, which we update every two weeks at our sprint review meetings. For those of you not familiar with software development methodology, Steinberg uses agile development, which is based around short spans of work (our team uses two weeks, and other teams within Steinberg use four) with an emphasis on achieving measurable progress in that time. The sprint review meeting at the end of each iteration serves both as a forum to share what we’ve been working on, including a little bit of show and tell where possible, and to plan the next sprint. As the meeting goes along, we write down any milestones we’ve reached during that sprint, and put them up on the timeline (good things are green, obstacles or impediments are pink — fortunately there have been relatively few of the latter, so far). Our timeline is now nine months long, and lots of good stuff has been happening.
The biggest event in any given April for a company like Steinberg is Musikmesse, the huge trade show that takes place in Frankfurt every spring. I was fortunate enough to attend the show for a couple of days, and filled those days talking to interesting folks working in our field, including Michael Good of MusicXML fame, Joe Berkovitz of Noteflight, Dominik Hörnel of Scorio, Thomas Bonte of MuseScore, Yair Lavi of Tonara, Bob Hamblok and Jonas Coomans of NeoScores, and others besides.
I came away from the show energised by what I had seen and full of ideas about how our new application might fit into this ecosystem of interesting companies all coming at the intersection of music notation and technology from different angles.
Of course, the Steinberg booth was packed every day, and the show attendees were wowed by the new products on display, in particular Wavelab 8, which was launched at the show, and Cubasis for iPad, not to mention the continued excitement around Cubase 7, released a few months before.
Later in the month, we had a visit from an expert SCORE engraver, Simon Smith, who works for Boosey and Hawkes in London and Éditions Durand in Paris. We wanted to see first-hand the strengths and weaknesses of SCORE’s almost entirely graphical (rather than semantic) approach towards score production. Simon skilfully entered a system of polymetric music from a score by Thomas Adès in a matter of minutes, demonstrating both how quick the text-based entry method of SCORE can be once you become proficient with it, and one of SCORE’s secret weapons: being able to space any rhythmic item as if it has a different duration than its notated duration (e.g. to space a dotted half note as if it were a quarter note, and so on).
Our aim with our new application is to produce a tool capable of the same kind of flexibility that SCORE’s graphics-based approach allows without compromising on the semantic richness that programs like Finale and Sibelius are built upon — indeed, we aim to go significantly further in semantic terms than current-generation scoring programs.
I also drove out to visit with engraver and publisher Barry Ould, who runs the Bardic Edition imprint, which publishes works by composers as diverse as Sorabji, Busoni and Grainger. Indeed, it’s Grainger who is particularly near and dear to Barry’s heart, as he has been one of the prime movers in The Percy Grainger Society, which seeks to promote the works of this under-appreciated Australian composer and performer, and we talked for some time about how he got involved — which is an interesting story that will have to wait for another day.
My reason for visiting Barry wasn’t to talk Grainger, however. Barry is himself an engraver with several decades of experience, and he has been witness to the seismic technological shifts in how music engraving is performed. He showed me his old Musicwriter modified typewriter, and we talked about the first computer engraving package he used on an early Mac (HB-Engraver from HB-Imaging), and so on. Barry was also an extensive user of Not-a-set dry transfer sheets, which he used to augment the limited output produced by his Musicwriter, and he very generously provided me with a number of new sheets that I hadn’t previously seen, all of which are useful models for symbol design in Bravura, our new music font.
I was also very fortunate to receive some further sheets from an editor and engraver for G. Schirmer, Peter Cressy, who took the time to package up some sheets and send them to me all the way from Vermont for me to scan and return to him. Thank you, Barry, and thank you, Peter.
In May, I presented my work to date on the Standard Music Font Layout initiative at the Music Encoding Conference in Mainz, Germany. I wrote about SMuFL and the Bravura font at the time, but things have progressed enormously since then — indeed, it’s the main thing I’ve personally been working on since I returned from Germany at the end of the month.
The announcement of SMuFL seemed to strike a chord, and I got a flood of feedback. A community of software developers, engravers and even a couple of font developers immediately started discussing the standard, suggesting new symbols to be added, debating various technical issues about the use of particular font features, and so on.
The upshot of all this discussion is that since the initial release of SMuFL on 23 May, there have been two further major revisions, which have between them expanded the repertoire of symbols in the standard from just over 800 to around 1700 in the current release at the time of writing, SMuFL 0.6.
The Bravura font has likewise been updated in step with the expansion of SMuFL, and a number of minor technical problems with the font have been fixed. For example, several people were eagle-eyed enough to spot a peculiar kink in the outline of the G clef, which was undetectable except at very high magnification:
Here are a couple of my favourite new glyphs that have been added to Bravura since the initial release in May:
Hundreds of new symbols have been added, including the complete set of Sagittal microtonal accidentals, thanks to the help of Sagittal’s creators George Secor and Dave Keenan, ranges of wiggly lines of various shapes and sizes (thanks to Emil Wojtacki for help with those), pictograms for electronic music (such as volume faders, transport controls, etc.), further instrumental techniques, and many more besides.
While I have been beavering away on SMuFL and Bravura, the rest of the team has continued to build up the foundations of our new application. Our test harness, which exercises the underlying music model, can now display barlines, which may not sound like much, but in fact it’s quite a significant step, because bars are by no means the fundamental structural container in our model that they are in other scoring programs, and this has the potential to unlock all sorts of sophisticated functionality. The test harness can also save files in the beginnings of our application’s native file format, in addition to being able to export rudimentary MusicXML.
Finally, inspired both by the previous month’s visit by SCORE engraver Simon Smith, and by a couple of talks at the Music Encoding Conference about Plaine & Easie Code, an extraordinarily long-lived text-based encoding for musical incipits widely used by libraries and other academic research projects, I began to think about the step-time input method for our application in the light of translating the keystrokes you would use to input music interactively into strings of text that could be processed in a single operation, effectively providing something a little like the text-based input method of SCORE (and other similar programs, such as Lilypond, and formats, such as ABC).
By looking at an excerpt of music and typing out the keystrokes that would be needed to input that music in our application, I could start to get a feel for how inputting music directly into our application will work. I’ll share one little tidbit to give you an insight into the design process: should accidentals be specified before or after the pitch name when inputting notes from the computer keyboard? There are pros and cons to either approach, but in the end we decided that you should specify the accidental before the pitch name so that you’re not forced to hear the wrong note before you can tell the software you want to apply an accidental. This same principle also applies to things like specifying the octave of the note you’re about to input.
This post is already quite long enough, so you’ll have to wait for the next instalment of this developer diary to find out more — but I promise I won’t make you wait another four months to read it. We love to read your comments, so please feel free to share your thoughts below.