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.