It’s been a long time since the last entry in this diary, and as the year draws to its close, I know there is an appetite for news on how our project is progressing. I hope this update will bring you some festive cheer and excitement for the year ahead.
The past several months have included two meetings with people in the music publishing industry. In early July, I travelled, along with my colleague James Larcombe, who is one of our developers, to Munich to meet with the engravers and Head of Publishing at G. Henle Verlag, and in October I was in New York City meeting with nearly two dozen engravers, editors, and production managers from the city’s top classical music publishers, including Boosey & Hawkes, Schott, Theodore Presser, Carl Fischer, ECS Publishing, Subito Music, and others.
It has been very exciting to get out on the road and to be able to show the application to professional users, to share with them some of the things we have been working on, and to gather their feedback. Building an application that is suitable for truly professional use is our primary goal, and meeting with top professionals helps to validate our approach. I am pleased to report that the feedback we have had so far is universally positive, and this is a source of great motivation for the team.
We continue to work on every area of the application, from its engraving engine to input and editing methods, by way of user interface design and work on integrating the Cubase audio engine, and more besides. In this installment of the diary I’ll touch on a few of these areas to give you a flavour of where we are spending our time.
Let’s start with dynamics. This gives us an opportunity to talk about a number of different aspects of the application, including how different notations are created, how the program thinks about them, and how they can be edited by the user.
Our application has a single-window design, with the interface split into five different modes (Setup, Write, Engrave, Play, Print), roughly divided up according to the different phases of working on a given project. In each mode, collapsible panels down the left- and right-hand sides of the screen, and in most cases also along the bottom too, show the main interface elements for creating and editing your music. Dynamics, along with all other musical material, are created in Write mode.
The left-hand panel in Write mode contains the main controls for inputting notes, including choosing the note value, setting accidentals and articulations, and changing various options related to note input and editing, which perhaps we’ll talk about more another time. The right-hand panel, by contrast, can show one of about a dozen different panels for creating other kinds of notations, such as clefs, key signatures, time signatures, tempo marks, and, of course, dynamics.
You can input notes, dynamics, and other markings using the mouse by clicking in the panels and then clicking into the score where you want the note or marking to be placed (and the application will automatically position the marking for you according to the current set of engraving options), but the quicker way to create things is to use the computer keyboard.
Take a look at this little capture, which shows creating a dynamic by typing, then editing the resulting dynamic using the buttons in one part of the Dynamics panel.
We are using a consistent set of key command patterns wherever we can: single keys for basic note input and editing (A for a note with pitch A, Q to start inputting a chord, or “quord” if you prefer, S for a slur, and so on), and Shift with a letter key to start inputting other markings (e.g. Shift–M for meter, or time signature; Shift–T for tempo; Shift–K for key signature, and so on). So to start inputting a dynamic, first you type Shift–D, at which point the little pop-over that you see in the capture appears (we expect it will look a bit prettier in the released software).
Now you can type the dynamic you want: notice how I typed “poco piu f” without the required grave accent on the “u” of “più”, and I didn’t need to do anything special to tell the application that I wanted the proper bold, italic “f” for forte. When I hit Return, the application parses the input I provided and creates the appropriate dynamic.
This is an important concept in our application: you can create markings by typing a description of the marking you want. For some types of markings, these are a bit more abstract (e.g. for key signatures, you can type “f” for F minor, “G” for G major, “3s” for A major, or “5f” for D flat major), but for dynamics they are essentially the text you want to appear. However, the resulting dynamic object is not simply a text object as it might be in some other applications; instead, it is a special dynamic object with rich semantic knowledge about its role and meaning, which happens to look like a run of text with a font change in it.
This is illustrated by what happens after the dynamic has been created: clicking on the buttons in the part of the Dynamics panel that you can see to the right of the music changes the properties of the selected dynamic. This is another important concept in our application: when you select an existing item in the music, you can edit its meaning in the right-hand panel by interacting with the various control there.
Likewise, you can double-click an existing item to edit it: when you do so, the pop-over reappears with the text that gives rise to the existing item, and you can edit or replace that text. When you hit Return, the text is parsed again, and the appropriate dynamic or other item is created in place of the original one.
You might be wondering how the application handles unusual dynamics that are not shown in the panel. The application has a set of dynamics and modifiers whose meanings it understands (which means that they can, for example, be interpreted automatically during playback), but you can of course create your own: if you type, say, “ff strongly”, then the resulting dynamic would still be as you expect, but the word “strongly” would have no direct effect on playback itself.
Notice also how the dynamic is positioned: because the application understands which part of the dynamic is the actual dynamic level (in the case of “poco più f”, it’s the forte dynamic itself, of course), it can ensure that the whole dynamic is positioned such that the main part of the dynamic is centred under the note from which it takes effect; at the end of the capture, the final dynamic is “pp sub.”, and again notice that the pianissimo is centred under the note, with the “sub.” running off to the right. (If you prefer “sub.” to go to the left of the dynamic level rather than to the right, or to be written as “subito” or “sub” with no full stop, there are options for that, too.)
Dynamics are also intelligently positioned vertically. If you have a complex dynamic, such as a pair of hairpins with starting and ending dynamics, and perhaps a specific dynamic in the middle of the pair of hairpins, these can be grouped together, which means that they will all be moved vertically if remaining in their default position would result in a collision with, say, a low note, articulation, or slur on the stave above.
By way of example, here’s a short excerpt taken from Prelude no. 2 by Julian Scriabin, the youngest son of Alexander Scriabin, a prodigious musician and composer before his tragically early death at the age of 11. I came across this example thanks to Djuro Zivkovic, who has published an edition of the younger Scriabin’s Preludes via his imprint Editions Octoechos, and who also recently founded the online forum Notat.io, a community for people interested in the art and practice of music engraving (if you enjoy reading this blog, you will very probably feel right at home there).
To produce these examples, I imported the same MusicXML file into each application1 (except for Product C) and the results shown are the default produced by each, with as little further editing as possible.2
Our application does its best to line the immediate dynamics up with the hairpins, and to ensure that the hairpins start and stop an appropriate distance to either side. It also tries to keep the dynamics centred between the keyboard staves (as shown in the first three bars), but when this is not possible, it moves the dynamics away from the centre to avoid collisions (as shown in the final two bars).
Compare this result with Product A, where the staves have been moved far enough apart to ensure that the dynamics do not collide with either the notes or the staves, but where they are poorly-aligned relative to each other, and are generally too far from the left-hand stave. Product B does not have any features for automatically adjusting the distance between staves to avoid collisions, but of course it would be the work of a moment to move the staves further apart (though you may potentially have to do this yourself for every system). Product C does a good job of balancing the various compromises involved in laying out this music, but the dynamics are not centred between the staves where possible (perhaps because the dynamics are entered in their own context between the two staves, as recommended).
We still have much more work to do on dynamics in our application, but I believe the fundamentals are sound (no pun intended).
Adding glissando lines to our application’s burgeoning capabilities has been an interesting challenge. You might be surprised at how much complexity there can be in positioning what is essentially a straight line between two points, but a look at how glissando lines are handled by several of the existing scoring programs demonstrates some of this complexity.
Product A, for example, makes no attempt to attach either end of the line to the starting and ending notes of the glissando automatically. Product B does attach each end of the line (more or less) appropriately, but it does not automatically prevent the line from colliding with an accidental to the left of the ending note. Product C, meanwhile, does prevent the line from colliding with an accidental to the left of the ending note, but does not automatically add any extra space, which means that the glissando line can end up at an extremely steep angle.
Although Product B and Product C attempt to position the start and the end of the glissando line close to the appropriate notes, they don’t prevent the ends of the line from colliding with stave and ledger lines, which can compromise legibility.
None of the other scoring programs handle glissandos that start and end in the same stave position (e.g. from a C natural to a C sharp) especially well: a glissando line should (almost) never be completely horizontal (or indeed especially close to horizontal), because it can start to become confused with stave lines, but all of the other applications produce a horizontal glissando line in such a situation.
I’m pleased to say that, after a good deal of work by our development team, all of the above situations are handled reasonably by our application: each end of the line is attached to the starting and ending note, as appropriate; the line end points are positioned carefully such as to avoid collisions with stave and ledger lines at either end, or with obstructions such as rhythm dots at the left-hand end or accidentals at the right-hand end; to prevent them from becoming too steep, additional rhythmic space is added if necessary; and glissando lines that join notes on the same or adjacent stave positions are always angled, to prevent them from being confused with stave lines.
In some editions, glissando lines are drawn with clarifying text, typically using the abbreviated form gliss. (or sometimes port., for portamento), running along their length. Product A and Product B both allow angled text to appear over the glissando line if there is sufficient room for such text to appear; however, Product C does not allow text to be drawn along the length of the line. Our application, like Product A and Product B, will only show the text if there is sufficient room, and you can easily specify whether a specific glissando line should or should not display text by means of setting a property on the item.
However, one further nicety of our application’s support for glissando lines is in the rare but not unheard-of situation of a glissando between several notes of successive chords. In this situation, our application automatically displays the gliss. text only over the topmost glissando line in the chord, to avoid cluttering the score with redundant markings. None of the other applications we have tested handle this situation automatically.
Here’s a short musical example that shows these situations in action:
As well as working on matters relating to engraving, inputting, and editing, we’re also working on fleshing out the rest of the application. One such area of focus over the past couple of months has been Print mode, from where you can print or export graphics from your project.
In the same spirit as making it as easy and quick as possible to input your music and get it looking great, we likewise want to get music out onto paper via your home printer, onto your digital device, or into print quickly and efficiently.
When you switch to Print mode, the large central area in which you work with your score is replaced with a print preview that shows you exactly what you will get when you print or export. Down the left-hand side is a list of all of the layouts (scores and parts) within your project, with quick controls to choose how many copies to print, and helpful read-outs of the page size and number of pages of each. Down the right-hand side are all of the options for printing, allowing you to choose between printing or exporting graphics (e.g. in PDF format). The program can automatically produce booklet layouts, and can take advantage of your printer’s duplex unit, if it has one. You can print or export one or more layouts in a single print job, and your chosen settings (e.g. which paper size to use, and whether to print 2-up or as a booklet) are saved in the project so you can quickly and easily print revisions later without needing to set the options up again.
One neat addition that I don’t believe is supported by any other application, courtesy of an idea shared with me by a certain music notation enthusiast friend of mine, is that when printing 2-up or spreads, i.e. printing two portrait pages side by side on sheets of paper in landscape orientation, if the layout in question has an odd number of pages, you can choose to print the odd final page on a different paper size, in portrait orientation. This means you have fewer sheets of paper to tape when you’re putting the parts together.
That’s all, folks
I have only been able to write about a few of the things we have been working on over the past few months; I could have written an entirely different post covering the work done by other members of the team. Everybody continues to work exceptionally hard towards the goal of bringing you a useful new tool for working with music notation. I hope you have found something to interest you in this latest update, and I will do my best to make the interval before the next instalment shorter. Until then, on behalf of all of us working on Steinberg’s new scoring application, please allow me to wish you all the best wishes of the season. Happy Christmas!
- Long-term readers of this diary will be familiar with these appellations by now, but in case you’re new to the series: Product A and Product B are the two leading commercial scoring programs; and Product C is an open-source music engraving and typesetting system that uses plain text files for input. ↩
- In all applications, I had to reduce the default stave size to make the music fit onto a single system. In Product A, I also used a feature to automatically adjust the distance between the staves after adjusting the stave size. In Product B, I had to re-enter the immediate dynamics, as they were imported above the right-hand piano stave. ↩
- Product A did not import the glissando lines at all, so default glissando lines were added by selecting each starting note and adding a glissando line. No subsequent editing was done to the positioning of each glissando. ↩