In my last post, I started to bring you up to date on our progress over the past few months, and today I’m going to continue the story. You have probably by now come to expect a fair amount of nerdy detail, and hopefully I won’t disappoint.

The image above is a screenshot of Steinberg’s internal build system, which sits in Hamburg churning out build after build of all of Steinberg’s products under development. We employ continuous integration, which means that the software is constantly being built and rebuilt after every change to the source code is committed to the central repository. Every time the software is compiled, the compiler runs all of the unit tests that our team have built into the software to check that every part of the program is still working as it was designed to: unit tests are an important way to guard against bugs in complex software, because they check every part of the program independently of each other — provided the developer has written the unit tests in the first place, of course! One of the advantages of starting a new application from scratch is that it’s practical to ensure good unit test coverage across the whole program from the outset, which should result in a better-tested, more robust and less buggy final product than current-generation scoring programs. A good deal of the time the team spends writing code is spent writing unit tests, and you should feel the benefit of this time investment in the stability of the final product.


While the development team are beavering away at the lower levels of our application’s musical brain, my colleague Anthony (@AntHughes) and I are free to think about the way the user will interact with the software. As part of this work, Anthony is using an application called Axure RP (the RP stands for “Rapid Prototyping”) to design interactive wireframe mock-ups of key parts of the application’s interface.

Prototyping in Axure

Prototyping in Axure

From the image above, you can get some kind of idea of the sophistication of the tool. Each element in the wireframe can have conditional behaviours, so you can create multi-step workflows directly inside the prototyping environment. Our aim is to produce something that we can put in front of real humans to validate our design concepts as a more sophisticated version of a paper prototype or the fabulously-named Wizard of Oz prototype.

We have a pretty clear idea of large parts of the application’s user interface. Our goals are to put the most important tools at your fingertips without overwhelming you with screen after screen of buttons and toolbars. At the same time, we want the application to use as few pop-up dialog boxes as possible, so that you are interacting directly with the score itself as much as possible, with few interruptions.

We will be trying out some of Anthony’s mock-ups with real human beings soon, which will provide some important validation of our core user interface concepts before they have been implemented in the main application.

Portland Place in London, home of the ABRSM (Courtesy scotticus_ on Flickr)

Portland Place in London, home of the ABRSM (Courtesy scotticus_ on Flickr)

Continuing our visits of major publishers, James and I went to visit the publications team at the Associated Board of the Royal Schools of Music here in London. We had a wide-ranging discussion with Simon Mathews, Stuart Briner and Stuart Rose about how the ABRSM is looking to the future and a time when its publications, so familiar to hundreds of thousands of instrumental students around the world, will be available in a variety of digital formats in addition to the well-loved print editions. We got a glimpse of the sorts of content management challenges that the ABRSM faces with producing its syllabuses and course materials in a variety of languages, and how to pull together text in different languages with score pages. This meeting reinforced our view that, as music publishers grapple with the seismic changes in how they distribute their content, the tools that will flourish will be the ones that best solve these content management and output format problems.


As London began to swelter under an oppressive heatwave, things were hotting up in our office, too, as several significant steps were taken by the development team.

Apple's profiling tool Instruments showing our test harness running tasks on multiple CPU cores.

Apple’s profiling tool Instruments showing our test harness running tasks on multiple CPU cores.

One of the technical goals for our new application is to take advantage of the parallel processing capabilities of today’s CPUs. The beginnings of a framework to tackle editing operations in parallel rather than in series was taken in July, with some parts of the MusicXML import process being successfully handled by all eight cores of the Mac’s CPU simultaneously. Although this is just a small step, it’s indicative of the care that’s being taken by the team to ensure the program’s operations are sufficiently independent and modular that they can be run in parallel.

Another important step forwards was the design and implementation of key signatures and tuning systems in the low levels of the music model, steadily building up its knowledge of core musical concepts. Just as with the team’s previous work on time signatures, the aim is for our application to handle key signatures as flexibly as possible, with support for custom key signatures (such as those found, famously, in Bartók’s folk song transcriptions and studies) — but we also have a number of other clever tricks up our sleeves, about which more will be revealed in the fullness of time.

We’re also working closely with the rest of the engineering team in Hamburg, who are lending their time and expertise to take the first steps towards coupling our proto-application to the audio engine that powers Cubase, so that we can start to hear the fruits of our labours. There is still a great deal to be done, but it’s now possible to import pitches, rhythms, dynamics, time signatures and key signatures from a MusicXML file into our test harness, perform some edits on the musical content, and then export a MIDI file and hear it played back. Again, small steps, but a journey of a thousand miles starts with a single step — and hopefully we have taken more than a single step by now.

As July came to an end, we released a third major revision to SMuFL (taking it to version 0.6) and to our open-licensed music font Bravura (taking it to version 0.3). The font now contains more than 2000 glyphs, and it’s starting to take advantage of some of the advanced features provided by OpenType, such as stylistic alternates.

In most scoring applications, the same glyph in a music font is used to draw the same musical symbol at all sizes, though this can give unsatisfactory results: when a font character is scaled down, all of its strokes appear thinner, which can make the shapes harder to discern at small sizes, and thus make the music subtly harder to read. For example, take a look at this improbable musical excerpt, part of a nonsense score I have cooked up to test various features of Bravura at different sizes:

Scaled accidentals on the left, alternate glyphs on the right.

Scaled accidentals on the left, alternate glyphs on the right.

The differences between the two sharp and flat signs is pretty obvious when blown up to this size: the symbols on the left are the standard glyphs, designed for use at normal staff sizes, while the symbols on the right are stylistic alternates, designed to be substituted by the scoring application when they end up smaller than a certain size, for example when used on a small staff.

These are subtle details, to be sure, but music engraving is a world of subtle details, and we are determined to produce great-looking results, taking advantage of the latest technology to produce results that uphold the finest traditions of this centuries-old art.

That’s it for this instalment of our development diary. As always, we love to read your comments, so we encourage you to share your thoughts and ideas with us in the comments below.