On the “Finalification” of Sibelius


Composer and educator Joshua Harris has just upgraded to Sibelius 5, and has posted a short review, in which he coins the term “Finalification.” This term resonates with me, and perhaps I might be permitted to attempt a (cheeky!) definition:

Fi•na•li•fi•ca•tion (fin-ah-li-fi-key-shuhn, fə-nāl’ē-fĭ-kā’shən, noun): an act of masking great power behind bewildering complexity.

I’m only kidding, of course, but I think there’s a serious point here. In Joshua’s review, he takes issue with some of the new features in Sibelius 5. First, Panorama:

The scroll view is, at least, inelegant.  Although it is not the default view, it panders to Finale users.

We actually worked hard to make sure that Panorama has all the elegance you would normally associate with a Sibelius feature. Unlike Finale’s Scroll View, in Sibelius you can scroll smoothly left and right by any distance; you’re not limited to scrolling a bar at a time. We also made the staff spacing independent between Panorama and normal view, because it seems crazy for dragging staves in scroll view to have any effect on the staff spacing in page view (although that’s exactly what happens in Finale). And we added extra controls in Preferences for expanding the default note and staff spacing to make the default appearance in Panorama as good as possible.

I didn’t expect to find myself using Panorama much: like many Sibelius users I was completely comfortable with the page-based view that I had been using for 10 years. But over the course of working on Sibelius 5, I found myself using Panorama more and more during note input. I found that being able to look at my MIDI keyboard and then up at the screen and know that the range of motion is only left to right and not up and down really helped keep my place, and eliminated the occasional disorientation that I sometimes experience when Sibelius moves the page while I’m not looking at the screen.

To each his own, of course! We’re certainly not going to force anybody to use Panorama, but it is an important feature for lots of people — and I don’t know too many die-hard Finale users who would even consider switching to another notation program if that program didn’t feature scroll view.

On Paste as Cue, Joshua says:

Another nod to Finale’s inelegance is the new automated cues.  I don’t want to have to remember a hundred automactic functions designed to help me.  I simply want to shrink notes so that they look like cues.  That’s intuitive.

I would certainly agree that being able to make notes cue-sized simply is important, and of course Sibelius has been able to do that since Sibelius 1.0. However, making the notes cue sized is only the start of the story: you also need to label the cue so that the player knows what instrument is being cued, you may need to add other markings to help the performer understand more about the context, and depending on the style of music, you may also need to add full-sized rests to reassure the performer that he or she really isn’t supposed to be playing at that moment. Prior to Paste as Cue, it could be as many as a dozen steps in total to create a properly-formatted cue, and it might take a minute or two per cue. After Paste as Cue, it’s literally the work of a couple of seconds.

Yes, it’s true that Sibelius is making some decisions for you here, but you have lots of control over them (see the Paste as Cue page of Preferences), and the result is something that really does simplify a mechanical process, leaving you free to spend more time actually writing the music.

Finally, Joshua doesn’t like instrument changes:

The new “change instrument” feature bundles the old staff transposition with the corresponding instruments playback change.  I prefer to make these changes manually.  That way, I get exactly what I want–not Sibelius’s best guess.

We thought long and hard about this feature before we decided to combine staff type changes and transposition changes into a single instrument change object. In the end we decided to do this because the only time you ever need to use staff type or instrument changes is when you’re changing instrument (why else would an instrument suddenly go from being, say, in B flat to being in E flat if not because you’re doubling, say, clarinet and alto sax?). Again, the idea was to prevent the user from having to do a series of mechanical tasks in order to accomplish a single result, and I think when judged on that basis, instrument changes are a success.

Ultimately, Joshua concludes:

Overall, I like the changes in version 5, but I’m worried that some of those changes point toward more Finalification in the future.

Hopefully I have been able to provide some insight into the thinking that went into these features. Thanks for the review, Joshua!

Leave a Comment

Your email address will not be published.