The story behind Sibelius 6: part 1


The release of a major new version of Sibelius is the culmination of thousands of hours of work from dozens of people. Sibelius 6 has in many ways been our most challenging version to date, and this is a glimpse behind the scenes into what went into making this new version.

To understand what we set out to achieve with Sibelius 6, first I need to tell you something about our experiences of developing Sibelius 5.

Sibelius 5 was released in June 2007, and although it has been our most acclaimed version to date (hopefully shortly to be surpassed by Sibelius 6!), we weren’t 100% happy with it when we released it. Although our basic principle is that we won’t release a new version of Sibelius until we really feel it’s ready, the truth is slightly more complicated. Now don’t get me wrong: many features, like Panorama, Paste as Cue, undoable plug-ins, and the much-improved bundled sample library, Sibelius Sounds Essentials, were instant hits, but there was enough that was simply too different about Sibelius 5 that some of our customers found it too much to deal with.

The fact that we weren’t 100% happy with Sibelius 5.0 at the time of its release is no reflection on the work of the development team, by the way, who worked long hours for months before release to get the program finished on time. We were facing a unique set of challenges: Apple were making a big architectural transition from PowerPC to Intel processors, which forced software developers into costly and time-consuming rewriting of their software; sound production on computers was rapidly moving from external MIDI devices and synths to virtual instruments, a move that we at Sibelius anticipated as early as 2003 when we added Kontakt Player to Sibelius 3, but our custom integration with NI’s technology was going to prove too limiting in the future, and we needed to embrace the industry standards; and in the midst of all this, the company was acquired by Avid, halfway through development.

What did Apple’s technological shift mean for the development team? It meant that we had to switch our development tools (from Metrowerks’ CodeWarrior, which just about all independent Mac applications were developed with) to Apple’s new Xcode environment, which at the time wasn’t well-suited to handling very large applications like Sibelius. We had to remove lots and lots of deprecated APIs in order to make the program build under Xcode, and in fact we invested heavily in replacing the user interface code with the latest Carbon HIToolbox APIs (only to discover at WWDC in 2007 that Apple were effectively discontinuing development of these APIs in favour of exclusively developing Cocoa, which would be the 64-bit wave of the future — but more of that some other time).

Sibelius’s playback engine, meanwhile, was 10 years old (older if you count its antecedent in the Acorn version of the program) and was closely coupled to the MIDI standard, with its strict limits of 16 channels. In order to give Sibelius a solid foundation for the next 10 years, we decided to rebuild the playback subsystem from the ground up. In the end this involved rewriting around 25%, or possibly more, of the program, hundreds of thousands of lines of code. We invented the SoundWorld concept to build an abstraction between the capabilities of a particular playback device and how Sibelius would map notation events in the score into playback events. It’s a pretty ingenious system, but it required a big shift in thinking from our customers: no more thinking about MIDI channels and program numbers, and instead thinking more about the sound you wanted to hear, trusting Sibelius to be able to handle all the mechanical stuff on its own. It turned out that a fair few of our users didn’t want to entrust this to Sibelius, and worse, because of the way that SoundWorld requires each sound provided by a device to be mapped onto a specific sound ID that describes the sound very precisely, we were not able to maintain the same level of compatibility with external MIDI devices that previous versions had boasted.

The result of all this, coupled with a certain amount of user apprehension about what it would mean for their favourite little notation company to have been acquired by a big corporation like Avid, was that we put our users through a certain amount of pain in the early days following Sibelius 5’s release, and that experience has really stuck with us. We worked hard to make improvements to reduce those pain points, and while we were also working on the localised versions of Sibelius 5 (which were finally finished a year after the English release of Sibelius 5.0), we were able to issue three maintenance releases that got Sibelius 5 to the point where we are all as proud of it as we wanted to be from the outset.

All the while, we were busily planning Sibelius 6. The planning process for a new version is multi-dimensional, as you might expect. Obviously we have a huge list of feature requests logged (numbering in the thousands!), and we have our own new ideas, and we have the feedback that we gather from the thousands of Sibelius users who fill in our user surveys after the release of each version (we hear not only from those people who have bought Sibelius 5, either as a new copy or as an upgrade, but also from those people who have not bought Sibelius 5 for whatever reason, and it’s always fascinating to see what those reasons are). Over a period of months, we established our goals for what we wanted to achieve with the next version of Sibelius. There were two big things we didn’t want to do, based on lessons we learned from Sibelius 5; and there were three big things we did want to do.

What did we not want to do? Firstly, we didn’t want to introduce any changes in workflow as disruptive as the architectural changes to playback were in Sibelius 5; and secondly, we didn’t want to make such a big investment in the platform technologies used for the program as we had in Sibelius 5, so we could focus as much of our available development time as possible on adding lots of cool new features to the program.

And what did we want to do? Firstly, we wanted to make the new version as appealing as possible to educators and students, particularly for those using Sibelius in a networked classroom environment; secondly, we wanted to address some specific areas where some users felt that competing products had the edge on Sibelius; and finally, we wanted to add some really incredible, innovative new features that would be very enticing for new users coming to notation software for the first time, existing users of Sibelius, and existing users of competing notation products, in the hopes of switching some of them to Sibelius. (Tens of thousands of Finale users have bought Sibelius over the years, but we want more people to try Sibelius, because we genuinely believe using Sibelius will help them become more creative and have more fun doing it!)

In the next post in this series, I’ll talk about how we approached meeting our three big “can do” goals for Sibelius 6.

Leave a Comment

Your email address will not be published. Required fields are marked *