The craft of music engraving
Q: Is the main goal of the program to produce quality engraved music?
Engraving is certainly paramount, and it’s an area that personally matters to me. There’s a very important role that music notation software developers play in how music is communicated. If we didn’t care about making the quality of our application’s engraving as good as we could make it, it would be a bit like word processor designers saying that it was okay to print a mistake in every tenth word.
Because virtually all newly-generated music that musicians come into contact with today is produced on the computer, musicians have expectations for what is right and what is wrong — or, to be less black and white, more optimal and less optimal — that are driven by the music they are seeing, which is, more often than not, the default output of one of the big two scoring programs. You have high school teachers printing out music for their students, and you have students printing out music for each other. Certainly when I got my music degree, we didn’t spend much time at all talking about the traditions of music notation and why something is engraved a certain way, and it’s not part of the music courses that I’ve seen.
So we have a huge responsibility in terms of upholding a craft that is centuries old. You have to work for years to develop the skills to do it, and to understand why things are done in a certain way. Earlier on I met with a gentleman who worked for Halstan. When he was trained by a master engraver, it was years before he was allowed to draw slurs!
In the age of computer engraving — much like desktop publishing allows anybody to produce a newsletter, but 99% of them look terrible — it’s the same with music notation. It’s wonderful that it’s democratized things. However, since most people never learn why something is good or bad, if those of us who are in a position to make sure that we uphold those traditions — and see the value in those traditions — can do something about ensuring that they are preserved, then we absolutely should.
We have always felt that way, but now that we’ve got the chance to go back to the very beginning and make sure that, for instance, when we do ties, we’re thinking about every situation that a tie may be seen in — and slurs, and beams, and accidental stacking, and all the rest of it — we do. When you’re working on top of a huge code base like Finale or Sibelius, the effort required to create an incremental improvement for something that was written years ago is very large. So I would guess those programs are not going to go much further than beyond where they are now in those areas. That same trade-off will also happen to us, of course, in the end. That’s why we’re trying to do the best job we can out of the gate with all of these issues.
We’re looking at many more scores produced by hand than we are scores produced by computer. In the scheme of things, published music going back to the 18th century is the tradition that we’re interested in. The last 20 years of computer engraving is a blip when you consider it in the light of that tradition.
As far as existing engravings are concerned, I admire Henle’s engravings, and I have their edition of the Brahms Klavierstücke on my desk at the moment. Even their computer work is good, because they put a lot of time into making sure that if there’s something that the program can’t do — and they use Finale, Sibelius, and Amadeus — they fix it. I respect that level of attention, because very few publishers these days, sadly, can afford to do it.
Product design and workflow
Q: What will the program look like, and how will users interact with it?
Being able to start 20 or 30 years later than the other programs did, you have a heck of a lot of knowledge about what has and hasn’t gone well — both from the inside and the outside — and you’ve got the opportunity to ask, ‘how can we do it better?’ As a designer, as somebody who’s trying to come up with natural ways for you to work with music, it’s a wonderful opportunity.
The fact that we’re part of Steinberg allows us to take advantage of the audio and playback expertise of the company. We’ll be able to have Cubase’s audio engine at the heart of our program. The long-term vision is that you’ll be able to transition between the DAW and the scoring program as smoothly as possible.
One of the ways that we hope to be able to do this is to have data interchange that’s smarter than just MIDI, particularly between Cubase and our own program. Also, when you’re in the DAW, quite a lot of time goes into making sure that the score plays back correctly with a sensitive choice of virtual instruments and mixing. Ideally we’d like to be able to carry that over into our program as well. In other words, you’d be able to take a Cubase project, export it in some special interchange format, open it in our program, and then it would play back using the same instruments and effects without needing to set everything up again, which is currently one of the big time-wasters. Not all of these things are going to be in our very first version, but over time, we hope that the growing integration between the technology and the products is going to be powerful.
Workflow that is optimized for today’s hardware is going to be hugely important as well. Right now I’m using my MacBook Pro, which is the only computer I have. It’s got a very limited set of keys, only one pointing device, one screen, and only a couple of USB ports. In order for this to be a workable environment, we want to make sure that the workflows that we are developing are optimized for the kinds of computers that people are actually using: that means laptops. That doesn’t mean that we’re not interested in people who have got an external keyboard or display or super-turbo Mac Pro, but it does mean that we’re focusing on the default case of the simple, stripped-down keyboard. What does this mean? Don’t use the function keys, because they all do wacky things on Macs these days. Don’t use the numeric keypad, because there isn’t one.
We’ve spent a lot of time thinking about how to use the resources available on the typical computer. That means that making sure that the way the interface is laid out makes efficient use of space and that it’s clear and logical. One way we’ve done that is by separating the user interface, according to the phase of work, into five discrete sections. Setting up the score is done in one place; entering the music is done in one place; the engraving details are in one place; playback is in one place; and outputting the music, whether to print, audio or another kind of file is done in one place. It’s all within a consistent framework, but you actually can do away with large chunks of user interface that you don’t need if you focus on the area that you’re working in right now.
At the same time as making the visual appearance of the program focused in that way, we can also effectively make efficient use of the limited number of keyboard functions. In other words, if you’re writing music, the keyboard shortcuts will do one thing, whereas when you’re tweaking the engraving details, the same keyboard shortcuts will do something else. By having a quick and easy way of explicitly moving from one phase of work to the next, you change the set of tools that you have available to you in what will hopefully seem natural, once you’ve learned it.
To extend this further, a whole class of users should never have to touch the engraving mode, because they’ll type in the music using all the tools they’ve learned in the writing mode, and the output will be perfectly good enough for them without needing to take further action. It’s very important to us that we focus the way in which you interact with the program in a way that’s reflective of the jobs you want the software to do and also the modes of interaction given the typical setup that you’ve got.
The program can do lots of clever things for you if you can clearly communicate your desire to the program. That comes not only in terms of deep things, like the way the music is represented — hopefully there will be less need for fakes and hacks where you have to subvert the way the program thinks about the music — but it also manifests itself at the surface-level, in the way the program is actually presented to you in the interface.
I’m a believer in opinionated software. We have to take a strong stance on issues of design, because otherwise the software will have a wishy-washy feel to it. So it prescribes a certain division of labor that perhaps doesn’t exactly fit every job that somebody might be doing with notation software, but it is at least logical, and of course it’s not to say that you have to go through them in sequence; you can freely switch at any time.
The point is that we have to have a way of slicing up the program. If you were to try to present the whole world of music notation, and all the kinds of projects you’d be doing, from a simple example for an academic essay to producing score and parts for a 3,000-bar opera, you can’t just stick them up all on the screen and hope that the user can find their way through on their own. You have to make some decisions about how to divide that up, and that’s what we’ve done. The idea is to have internal consistency in how they’re presented, and also to say that it’s totally fine for one key to do something different in each of those modes.
Composing and representing the music
Q: So, in addition to engraving and playback, will the program be useful as a compositional tool?
I hope that, more than any notation program to date, our program will be a compositional tool. When people use their DAWs these days, they’re used to a much more flexible mode of work. A lot of the underlying architectural and design decisions that we’ve made are to enable those kinds of experiences that you have with a sequencer, but still everything being displayed to you in terms of notation; after all, that’s what the program is for. In order to actually have the flexibility that something like Cubase has, you have to have another representation that lives underneath the notation, so that editing operations are carried out on that representation, and then the notation is, essentially, a side effect of those edits.
We’ll be able to expose editing operations that don’t inflict a penalty if you want to insert another note, or to change one kind of tuplet into another kind of tuplet, or even to insert a barline wherever you like. We want to remove these kinds of limitations that exist in current notation software.
For example, in some other software, if you have two eighth notes tied together over a barline, for evermore those notes are represented as two eighth notes, even if you copy and paste them to a place where that figure would be more correctly represented by one quarter note. In our program, the fact that the notes happen to be notated as two eighth notes tied together over a barline is just a side effect of the fact that it happens to fall where a barline is, like in a DAW.
So you can definitely think of the underlying representation of the music in our program as being “MIDI-like” inasmuch as you have a time line that goes from the beginning of time to the end of time, and you have notes of given pitches that have durations, but they don’t, in their underlying representations, exist in bars. That was a very crucial decision that we made early on: that bars are imposed almost at the end of the notation process. You decide what the duration of the notes are according to where they come in stream, and then you impose barlines on it naturally. The philosophy behind that, in addition to it matching MIDI relatively closely, is that this is how human beings experience music. We don’t hear barlines. We hear metrical groupings; we hear stresses, unstresses, emphases and de-emphases.
It’s tempting to think of how you’re going to store the data from a top-down approach: The top-level thing is a staff, the next level down is a bar, the next level down is all the notes, and all the rest of it. It’s true, that’s really convenient in many ways. Most scoring programs work that way: it gives you a nice tree graph that you can chop, change and perform different operations on, and for huge swathes of music, it works perfectly.
But where you run into problems is where something breaks out of those little boxes, because every box has to be smaller than the box that it lives in. If you get to the point where one of those littlest boxes at the bottom level of the tree suddenly wants to be twice as big as the box that it lives in, then you have a big problem; that’s where the representation falls down. So the approach that we’re taking is to store everything in those smallest boxes. We build up, and we impose hierarchy on it from the bottom. So, if you could characterize the typical approach that’s used by, as far as I know, Finale, Sibelius, and MusicXML as being “top-down,” then you could characterize our approach as being “bottom-up.”