US composer Joshua Harris recently posted a short review of the scorewriter program Sibelius 5 on his blog. I picked it up via a response from Daniel Spreadbury (Daniel is product manager for Sibelius), who expands on Joshua’s main complaint as follows:

[The term 'finalification'] 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.

(The joke here is at the expense of Sibelius’s main rival in the scorewriting world, Finale, a program with a ludicrous learning curve.)

Like Joshua, I’ve been a regular user of Sibelius for years. My love affair with the program dates back to pre-version 1, when it was called Sibelius 7 (er – don’t ask). I’m also an unashamed early adopter of Sibelius upgrades, so I’ve been using version 5 of the software for the best part of a year now, and its changes have been absorbed into my workflow fairly unconsciously. I guess that makes it more difficult for me than Joshua to step back and judge the value of those changes. Still – Joshua’s review and Daniel’s response piqued my interest.

Joshua argues that Sibelius risks getting more complex as it attempts to compete by adding new features:

Sibelius 5.0 has several dubious “improvements.”  The scroll view is, at least, inelegant.  Although it is not the default view, it panders to Finales users.  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.  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.

And Daniel replies by pointing out the rationale behind this increase in automation — for cues, for instance:

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.

At first glance, it looks like Joshua wants less automation, to which Daniel’s response (not unfairly) is that the whole philosophy behind Sibelius is to “simplify a mechanical process, leaving you free to spend more time actually writing the music”.

But, reading Joshua’s original post more carefully, I wonder if the issue here is really a gradual change in approach from Sibelius. I’ve noticed myself that the program is moving from what you might call a ‘visual’ approach to a ’semantic’ approach.

What I mean is this. Sibelius started off very much as a ‘visual’ program. To perform a particular task, you had to think as follows: “Right, what musical feature do I want to create? OK, so what would the notation of that look like? OK, so how do I create that notation in Sibelius?”. And then you went ahead and did it. For instance, pre-Sib5, when you wanted to change instrument, you visualised a score and realised that an instrument change consists of several notational elements: some text to announce the new instrument name, a key change, sometimes a clef change, sometimes a staff type change. Then you worked out how to create those elements in Sibelius… click-click-click-click… job done.

But, as Sibelius gets more sophisticated, its approach gets more ’semantic’. For the latest features, such as Paste As Cue and instrument changes, your pre-task thought process is now this: “Right, what musical feature do I want to create? OK, so where’s the function in Sibelius?”. And then you go ahead and do it. You don’t have to make the mental journey via the notational representation of what you want. Sibelius cuts out the middle man – it does all the notation work for you.

I think this is a journey that many computer programs go down. They start off by trying to recreate whatever it is they’re replacing visually – like Microsoft Word providing bold and italic functions, or Quark XPress allowing you to draw lines and colour in boxes. Then, over time, designers realise that a bit of intelligent programming can bypass the visual and get straight to the semantic – like Microsoft Word providing automated text styles, or Quark XPress allowing you to create tables.

(Nothing is this straightforwardly black-and-white in reality, of course. Most programs have a mix of elements from the start, and the move from visual to semantic is only a general trend. For instance, even in version 1 of Sibelius, when you created a clef change in the middle of some existing music, you didn’t have to go through and move all the notes after the clef change to their correct new lines on the staff — Sibelius did this for you.)

So is the move from visual to semantic an improvement? From Daniel’s point of view, definitely. We users are musicians. Melodies and instruments are our bread-and-butter, not staff types and noteheads. The more our software can implement our meaning directly, the less we’ll have to translate our ideas into the dreary language of notation, click-click-click-click-click.

But from Joshua’s point of view, it’s not so clear. His mental way of working, I suspect, is via notation. His brain is pre-processing his musical intentions and producing visual intentions like ‘OK, now I need to make those notes small’ or ‘I just want to change the staff transposition to Eb!’. How frustrating, then, to have to hunt around until he finds Sibelius’s way of doing what he wants — especially when it’s packaged up with a whole load of other tasks into a single semantic feature.

In the end, I’m with Daniel. I think Sibelius 5’s improvements in that regard are just that: improvements. But it’s not cut-and-dried. They aren’t ‘finalification’ in the sense of adding complexity, but they are ‘finalification’ in the sense of forcing the user to work the software’s way. One of the wonderful things about the early days of Sibelius was that a musician with no experience of the program could sit down at the computer and make the software work intuitively, simply by reproducing what they would otherwise write out by hand.

With features like scroll view, instrument changes and Paste As Cue, Sibelius is moving away from that — you can call it ‘finalifying’ if you like. Daniel won’t call it that, because for him (as for me) it’s a really good thing. But for others, including I think Joshua, it’s a concern.