For many readers of this blog, Daniel Spreadbury surely needs no introduction. For the unacquainted, Daniel started working at Sibelius in 1999 and, when he left Avid in 2012, was its senior product manager. During his time there he independently started the very blog you’re reading now, for which he wrote hundreds of posts. So it was a special privilege to invite him to talk about what he’s been doing for the last two-plus years as product marketing manager for Steinberg.
For the better part of two hours we spoke via Skype about a variety of topics related to his current work on a new music notation program. An edited version of his remarks appears below.
Progress on the new product
Q: How are things going?
Things are going really well. It has been a learning experience. We came into this thinking, “well, we know how to do this, we’ve been doing it for years.” But when you’re faced with a blank canvas to paint on, it can actually be very difficult to make decisions. You start to realize how much you take for granted the foundation that you were building on top of.
As far as our progress is concerned, you can look at it in two ways. On one hand, you could say, well, it’s taking longer than we thought it would, when we first started talking with Steinberg about working together. On the other hand, we’re committed to doing it right the first time. With a relatively small team, and in a relatively short space of time, for the things that we’ve done so far, we’re achieving results that are superior to the current top-end scoring programs. The things that we’re actually going to have in our first version are going to be much better than the things that are already in these mature products, and we’ll have achieved it — by some definition — in a fraction of the time.
Goals and details
Q: You said you’re committed to “doing it right.” What does it mean to “do it right” when it comes to music notation, with its wide variety of styles and permutations?
Well, there isn’t one “right” answer, but there is a fairly narrow range of good answers. We want the program to get as close as possible to the desired end result automatically. All the things that we’re talking about in this regard are engraving details. We’re not happy with getting it right, say, half the time or three-quarters of the time. We want to be getting it right nine times out of ten, at the very least. There’s already a huge amount of sophistication in the existing notation programs. I’m talking not only about Finale and Sibelius, but also, and especially, LilyPond. LilyPond is the one that lives and dies on the automatic results that it gets because it’s so time-consuming and, for the average user, awkward to tweak the results that it gets. So LilyPond gets closer to what you might call traditional engraving by default than the other two do, but the other two make it much easier to tweak it.
Interestingly enough, I’ve been spending some time looking at beaming at the moment, comparing the default beam angles and stem lengths that are produced by various programs. We’re to the point that we’ve now honed in on tiny details, and I would say that already our beam angles are at least the equal of the defaults you get in any other program, but we’re still not quite satisfied. I recently picked up the Alfred Essential Dictionary of Music Notation to read it again, and one of the things that I found very interesting that hadn’t struck me before is that it says that it’s very time-consuming to adjust beams in computer programs, and so it essentially cops out on giving very specific guidelines!
That’s the exact kind of cop-out that we’re trying to avoid. We’re trying to make it such that when you type in the music, it just looks good. If you want to change it, you can — you’re provided with a number of tools to do so — but the goal is that music that is entered without any tweaking could be printed and put in front of a musician without the musician having any problems understanding it.
That’s a pretty tall order, because it encompasses not only fairly obvious things like page layout, staff and note collisions, and so on, but also how the music is actually notated: how the rhythmic durations are broken up; how beat groupings are represented; where you have ties and where you don’t; how you show the metrical emphases in the music. And then it comes down to the really minute details, like making sure that a tie doesn’t clash into a sharp, or that a beam angle isn’t misleadingly steep for a relatively small interval. All of these are things that professional music preparers spend an awful lot of time fixing up, because it makes such a difference when you put the music on a stand in front of a player for the first time. Most musicians can’t articulate why music looks right or wrong; it’s more subliminal.
So even if, as a user, you don’t like the very specific solution we’ve come up with to a given notational problem, we want you to at least find it acceptable. Depending on the amount of time and effort you’re then willing to expend to go beyond that, the default bar that we’ve set is that much higher, and the distance between there and exactly what you want is much shorter. We’re trying to make the program behave so that making local changes to a given tie or a given beam is not necessary; instead, you’ll be able to set an engraving rule that communicates your intentions not only in that individual instance, but also in other cases like it.
The user base
Q: Who do you envision using your program?
We’re unashamedly targeting pro users. When I say “pro users,” though, I don’t necessarily mean the technical term of somebody who actually makes the majority of their living from using notation software; those people are pretty few and far between. What I mean is that we are trying to build something that will satisfy those people, on the theory that if we can satisfy those people that can distinguish quality engraving, efficient workflow, and configurable playback, then we can more easily satisfy the broader universe of people who are currently less demanding, but who are on their way up that ladder.
We’re not saying that we aren’t interested in amateur users, but I would say that the least experienced user we’re targeting would be the university student — not the high school student, not the elementary school student — the university student, the music major, who is serious about doing music prep, music production, composition, or arranging. This is the program that is going to provide the kind of tools that those people need to do their job as efficiently as possible, and to produce results that stand up to the level that they would expect.
Existing programs like Finale and Sibelius surely target those users, but I don’t think they do as good a job of meeting the needs of those people as they might. That’s where we see the opportunity — to be the professional choice.
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.”
On working at Steinberg
Q: What’s your work environment like?
There are 14 of us in the office, and of the 14, 12 of us worked together before. We’re very fortunate that we’ve been working together for a very long time; many of us for more than ten years. We have a strong rapport; we’re friends as well as colleagues, and have been since we were much younger and didn’t have babies and spouses. That, I think, goes a long way towards what will hopefully make this a successful endeavor.
We all have a strong feel for the field that we’re working in and we have a really strong team dynamic that has survived completely intact from being transplanted. We’re a small team, but I like to think that we “punch above our weight” in terms of the results that we get given the number of people that we have. That’s no reflection on me; that’s because the people doing the programming are tremendously talented individuals who no doubt could turn their skills to any field and excel, and we’re lucky that we have them working with us on this project. They often take hare-brained ideas of mine and improve them a lot by telling me, not in so many words, that I’m an idiot, and that’s quite all right!
The nice thing about working here at Steinberg is that we don’t have anything else to do other than work on this project. So these days I have no excuse for not being able to come up with answers to pressing development questions on demand. In a way, that’s a wonderful thing because it means that, as much as much my mental energy will allow it, it can be 100% dedicated to building a better program.
We collaborate with our colleagues in Hamburg, but it’s not like we’re poking around into the internals of Cubase. Steinberg as a whole is run on the agile software methodology, so we work in short iterations, or sprints. There’s a fairly flexible allocation of people among projects. We do work with them in ways you would imagine: we go over to Hamburg for a few days at a time to do in-person work and we have weekly meetings via teleconference.
VST hosting and VST plug-ins that are currently included with Cubase are just a couple of the ways, no doubt, that the first version of our program will bear the fruit of those efforts. We don’t know what kinds of sounds will ship with our product when it becomes available, and that’s a bit of challenge: pros have already probably chosen what libraries they wish to use for playback, so in a sense it’s probably even more important that we figure out how to work well with existing third-party libraries than we do with yet another orchestra that comes in the box with our software.
Down the line, as I said, we want to look at more specific integration to transfer data between Cubase projects and our program’s projects, and we’ll come up with little teams that are focused on that for a period of time according to the way that the priorities all shake out.
Comparing features to existing products
Q: Are you looking at the existing music notation software products as a baseline for features? Is there anything you’ve ruled out including in your program?
Naturally, we have constraints in terms of how much we can do in a reasonable time frame so that we can come up with a coherent first version that we can release and hopefully sell, and that customers will hopefully want to buy. Inevitably we won’t have all of the features that the existing, mature programs have. They have an accumulated 20-plus years of features. I won’t categorically rule out adding any particular features in the future, of course. One example of a feature that is unlikely that we’ll have in our first version is support for scanned music, but that’s the kind of thing that we might very well add later on down the line because it is a genuinely useful workflow.
Do we look at the existing notation products as a baseline? Only in one sense: the actual repertoire of types of music notations that you simply have to be able to handle in order to be useful to anybody is very large. In other words, pretty much every type of instrument needs notes, accidentals, staff lines, barlines, slurs, ties, beams, dots, plain text, techniques, rehearsal marks, bar numbers, staff labels… the list goes on and on. So we have to make sure that our program is capable of doing conventional notation in the first version. It’s inevitable that some more specialized notations, such as those used by early music, or perhaps some guitar things, will have to wait for later versions.
The challenge is, every time you turn over a stone, whether it’s ties, or beams, or stems, you discover a huge amount of stuff you have to do. If we can’t do, for example, instrument naming at least as well as in Finale and Sibelius, why would any pro who’s likely already using one of those programs bother to take a look at our program? So that sets the bar in terms of core notational elements; we have to be at least as good as those guys at those things. But it can’t be just “me, too.” We have to have things that are unique to our program — and I believe we have a number of things that we are doing that are unique to us — but if we can do some fancy thing, but can’t label our staves, then, it’s a non-starter. We have to cover the same ground, and we have to cover it well.
SMuFL and Bravura
Q: You’ve talked about SMuFL (Standard Music Font Layout) and Bravura on your blog and elsewhere, but what is it like seeing the response to it in the field, and how it has begun to be used and implemented?
SMuFL was born of necessity. We needed a font, and we knew that it couldn’t be done the way it was done before. So it made sense to approach it in a way that made sense beyond our little world. There is a difficulty with interchanging existing music fonts, and hopefully this will help.
It’s been really fantastic to see the enthusiasm for it among a variety of different types of software. Logic Pro X 10.1 now works with Bravura and is, effectively, SMuFL-compliant, in that it knows what code points to pull out of the font to get the right symbols. MuseScore 2.0 will ship with Bravura; SoundSlice is using SMuFL and Bravura; MakeMusic will support it in an upcoming version of Finale; there are a number of independent developers that are making use of it in various mobile apps that will eventually see the light of day; and Robert Piéchaud just released a new version of November, which is the first commercial SMuFL font. It’s really cool to see another font designer working through the issues and coming up with a font.
My goal is that we should have fonts developed to this standard so that people who use our program and hopefully other programs, if other developers choose to support it, will have a wider variety of fonts they can use in the same way that you can with your word processor. I would like for a font designer to think that it will be worth their while to produce a music font because its use won’t just be limited to one particular program.
The state of music notation and the field
Q: Is it a good time to be investing in the development of music notation software, with all the predictions of the decline of the art form?
I’m always very dubious of people warning that the death of classical music is upon us. If you’re going to have music of any sort of complexity that’s going to require multiple humans to play it, you need music notation. So I don’t worry about the state of our field. It’s a bit like saying, “is the e-book going to be the death of reading,” or “is the internet going to be the death of reading,” or “is TV going to be the death of reading?” No!
The point is, we’re still training musicians to play acoustic instruments. Obviously, yes, kids are more attracted to guitars and drums these days than they are to piano, clarinets and violins; all the same, we still have wonderful orchestras, wonderful ballet houses, and wonderful opera houses. We still have fantastic conservatories that are teaching these things, and I haven’t heard about any of them closing, other than the occasional university dropping a music program here and there. Juilliard isn’t closing; the Royal Academy of Music isn’t closing.
We are still training musicians, and we still have an appetite for music that can move us. I’m sure that there is always going to be a need for music notation, just as much as there is there is going to be a need for the written word. It is a way in which humanity’s artistic endeavors are communicated to the current and future generations. I cannot see it going away.
To refer to something I said earlier, we see our role that we have in building this program as being part of that tradition that goes back hundreds of years: how these things are communicated, and, in the end, they can be brought to life by humans actually picking up instruments and playing them. That’s our role. We’re the toolmaker who replaces the craftsman that was doing that job — or at least enables somebody who doesn’t have the training to do it at all, to do it, and to enable somebody who does have the training to do it better, and to get closer to the tradition of it — and then to help make that music come alive.
In the end, that’s what this is all about. We make music notation software so that you can make music notation that can be played by a human being, so that we can have the shared experiences of music. That’s not going away, and I think that there is room for us to make something that does these things in a new way that’s faster and better, so that it’s worth somebody’s while to check it out when it arrives.