In the last update, we started discussing some of the individual engines that are under development to handle atomic notation and engraving tasks, and I described the engines for note and rest grouping, and positioning rests in multiple voices. Let’s take a look at another couple of little engines that could.
Accidental duration
Most scoring programs implement what might be termed the “common practice” rule for when accidentals should appear: an accidental is shown on a note of a given staff position whose pitch differs either from its unmodified pitch determined by the key signature, if any; the accidental applies only to the octave in which it appears; and the accidental lasts until the end of the bar, unless it is contradicted by a further accidental in the meantime.
Some scoring programs also implement support for cautionary (or courtesy) accidentals, either as proper built-in features or by way of plug-ins that have to be run and re-run as the music is edited.
A couple of scoring programs (though neither of the two most mature commercial products) provide options that support a variety of different conventions for accidental durations, such as accidentals applying only to the note on which they appear, with naturals shown on all other notes, or sometimes with no other accidentals shown (in which case a note with no accidental shown is played as if it had an explicit natural shown), and so on.1
By now it should not surprise you to hear that our goal is to handle accidentals more powerfully and more flexibly than any other scoring program, though specific details will have to wait for another day. The engine for calculating the required accidentals feeds its output into another engine for calculating the order in which accidentals should appear before a note or chord, via a minor detour.
Stem side calculation
The engine for stacking accidentals needs to know not only which accidentals should appear for a given note or chord, and other fundamental information like the staff position of each note, but also what the arrangement of notes in a chord will be: specifically, it needs to know on which side of the stem each note will appear.
When a chord includes notes on adjacent lines and spaces (i.e. intervals of a second of some kind), noteheads have to be positioned on opposite sides of the stem. A notehead that is positioned on the opposite side of the stem to the majority of noteheads in a chord is known as a back-note. It’s very important that the majority of noteheads appear on the correct side of the stem (i.e. on the left for an up-stem chord, and on the right for a down-stem chord), with the back-note (or back-notes) positioned on the opposite side of the stem.
The engine to calculate the correct arrangement of notes around the stem of a chord takes as its input the staff position of each note in the chord, and its stem direction, each of which is worked out by other engines. Each engine keeps all of its information up to date for the whole span of music, so that it is readily available to other engines that need it, and great care is being taken to ensure that only the minimum required recalculation is being carried out when the musical content changes due to edits, new music being entered, and so on, so that the performance of the application as a whole is as good as possible, despite the complexity of the calculations being performed.
Accidental stacking
Accidental stacking is another deceptively simple aspect of music engraving: in general terms, the aim is to arrange accidentals such that they appear to the left of a chord in notional “columns”2 in as compact an arrangement as possible, taking into consideration various conventional practices, such as aligning accidentals on notes an octave apart in the same column (except when you don’t) and aligning accidentals on intervals of a second such that the accidental for the higher of the two notes is positioned immediately to the right of the accidental for the lower of the two notes (except when you don’t), and so on.
Each of the major texts on the finer points of engraving cover accidental stacking to some extent; Elaine Gould’s book Behind Bars is probably the most explicit and detailed in terms of both the general approach that should be taken and some key exceptions. However, as with more or less any aspect of engraving, a set of simple rules and some exceptions to those rules do not account for every possible case, and the job of deriving algorithms to produce pleasing accidental stacks in every case is by no means trivial.
For simple chords of up to three or four accidentals, there is generally little argument among music engravers about what the correct stacking arrangement should be. Once chords get more dense, then there is substantially less agreement, and a perusal of a variety of published editions from the age predating computer engraving shows just how much variety there can be. As with many complex problems of geometry, there are many possible solutions for each case, and the correct arrangement is as much a matter of taste as it is anything else. There is no thought that our accidental stacking algorithm – or indeed any of our other engraving algorithms – should replace the judgement of an experienced engraver, but our aim is to produce a satisfactory result that a musician will accept automatically, so that users who do not have years of experience in manually stacking accidentals against complex chords can have confidence in the default appearance it produces.
Since a picture paints a thousand words, let’s take a look at a few examples. These chords are drawn from the first few bars of Max Reger’s Introduction, Passacaglia and Fugue in B minor (Op. 96) for four hands, two pianos; it’s an interesting test case for accidental stacking because it’s a thickly-textured work largely consisting of chords in all four hands.
Here’s the result produced by one of the two leading commercial scoring products, which we will call Product A:
The other leading commercial scoring product, Product B:
The open-source music engraving program, which we’ll call Product C:
Interestingly, all three programs come up with different stacking arrangements for three of the five chords, all three agree for the third chord, Product B and Product C agree for the fourth chord, and Product A and Product B agree for the fifth chord.
The basic rule for stacking accidentals can be described as a zig-zag: start with the highest accidental in the chord and position it in the first column (immediately to the left of the chord), then the lowest in the second column, then the next highest in the third column, the next lowest in the fourth column, and so on, until you run out of accidentals. At each stage, if you find an accidental on the same note name in another octave, position that in the same column, so that accidentals on octaves are aligned. This is something of a simplification, of course, but it’s enough for you to get a general idea of how accidental stacking works.
Now look at the first chord, and in particular Product A’s default rendering: it positions the sharp on F#3 (assuming middle C is C4), the third lowest accidental, in the first column. It does this because it can be tucked underneath the leger line on D4, though this isn’t entirely successful: the other accidentals end up too far away from the chord, and the result from either Product B or Product C would be preferable.3
Product A’s strategy for tucking accidentals in for back-notes and leger lines is more successful in the case of the fourth chord, where it produces the most compact result, positioning the sharp on G#4 in the first column, while Product B and Product C position this in the outermost third column. However, many engravers would find the placement of the sharp sign so close to the D5 immediately above it that they would choose not to tuck it in here.
For the second chord, Product C’s default rendering is the most conventional (and perhaps therefore the most desirable): the highest sharp, on D#4, is positioned in the first column, with the octave D#3 aligned in the same column; the lowest remaining accidental, the sharp on F#3, is positioned in the second column; and the remaining natural on A3 is positioned in the fourth column. Product A would presumably produce the same result if it did not attempt to tuck the natural in under the leger line, again an unconventional choice.
It’s a similar story for the fifth chord, where Product B unconventionally chooses to place the next highest accidental (the natural on A4) in the second column after correctly aligning the octave on C5 and C4 in the first column; Product C instead chooses the sharp on D#4 for the second column, which follows the standard convention more closely. Notice how the naturals on the octave C5-C4 are aligned precisely in Product B and Product C, but not quite in Product A: Product C subtly shortens the leger line on C4 to allow the natural to be positioned as closely as possible, while Product B moves the naturals on both C4 and C5 a little to the left to clear the normal-length leger line; Product A, on the other hand, only adjusts the position of the natural on C4, producing a sub-optimal result where the accidentals separated by an octave are not precisely aligned.4
The arrangement for the third chord is pretty uncontroversial: although there is an interval of a second in this chord, and it’s usually best to stack accidentals for seconds such that the accidental for the higher of the two notes is positioned immediately to the right of the accidental for the lower of the two notes, if there are other accidentals in the chord it’s often preferable to use the more standard zig-zag arrangement, as it occupies marginally less horizontal space.
You might well be asking how our in-development application handles these chords. It happens to produce the same results as Product B:
The above examples illustrate just how much variation there is in stacking accidentals even for quite straightforward chords. When things get more complicated, there is even greater possible variation in the arrangement of accidentals.
To test this out, we generated hundreds of random chords of increasing complexity using the music21 toolkit and exported them as MusicXML. The resulting MusicXML file was then imported into our own test harness and a variety of other commercial scoring products, and the default accidental arrangements were exported as PDF, with no editing. We examined the results by eye, and recorded a number of interesting characteristics. You can check out a subset of the results (32 chords, ranging from three to 12 notes) using a simple interactive tool5:
Click this image to view the interactive comparison tool.
By now you are familiar with Product A, Product B and Product C. Product D is a commercial scoring product no longer under development or indeed widely used, but still used by some top publishers; Product E is a popular open source scoring program with a graphical user interface; and Product F is a browser-based social composition product.
Using the comparison tool, you can zoom in to get a closer look at each chord, and then switch between the default results produced by each program. Click Show annotations to see various sub-optimal characteristics called out with coloured highlights (refer to the legend for the meaning of each different colour).
The point of this comparison is not to be critical of the results produced by different scoring programs, but instead to illustrate just how non-trivial the job of designing a fully general algorithm for accidental stacking is, even for mature and well-regarded applications.6 Experienced engravers would undoubtedly find much to disagree with in all of the results. However, we have worked hard to produce results that exhibit as few undesirable traits as possible.
The job of our accidental stacking engine, then, is to determine which accidentals should go in each column, and specify whether any of the columns can be tucked in to share the same space as a back-note elsewhere in the chord. It doesn’t concern itself with how those accidentals should actually be drawn and spaced relative to the note or chord and each other, so the rendering from our test application is rudimentary with regard to spacing. Its job is to pass the resulting columns on to the next engine in the chain, which can determine how best to lay out those columns in as compact a form as possible while maintaining legibility.
More to come
That’s probably (more than!) enough detail about the little engines at the heart of our application’s musical brain for the time being. In the next instalment of this series, I’ll describe some of the other things that have been going on, including an update on our music font, Bravura, and the standardisation effort for music fonts we’re leading, plus details on our progress in designing key parts of the application’s user experience.
- These conventions can be achieved to greater and lesser extent in the most mature commercial applications with the aid of plug-ins, but these have to be run and re-run after the music is edited to ensure that the display of accidentals is always correct. In the leading open-source music engraving program, of course, accidentals are calculated when the whole input file is processed, so changing the rules for accidental duration necessitates the re-processing of the whole input file, just like any other change to the input. ↩
- Think of each vertical slice containing one or more accidentals to the left of a chord as an individual column: a two-note chord describing an interval of a second, each note with its own accidental, would require two columns, because one accidental has to be positioned to the left of the other to avoid overprinting. ↩
- Product A has an option that prioritises the placement of the highest accidental in the first column, which produces an identical appearance to Product B and Product C for the first chord, but it has disadvantageous side-effects in other chords, and in any case this option is not enabled by default. ↩
- As ever, it seems only fair to point out that it is relatively quick and easy to adjust the position of individual accidentals in both of the most mature commercial scoring programs, while it is somewhat more involved in the text input-based Product C, and cannot be done in a graphical fashion at all, except perhaps with a separate graphical front-end, instead requiring tweaks to the input file and re-compilation to see the result of each attempted improvement. Fortunately, for these five chords at least, there is little to complain about in Product C’s default stacking arrangements. ↩
- Although the results have been manipulated in an illustration program in order to ensure that the notes and staves line up exactly, none of the accidentals have been moved relative to their corresponding notes, so they present an accurate depiction of how those chords are laid out by each application. ↩
- Indeed Product E also demonstrates that it’s hard to do the stem side calculation – described above and performed in our application as a prerequisite of the accidental stacking – for arbitrarily complex chords, as there are quite a few examples of back-notes on the wrong side of the stem, with subtle but discomfiting results. ↩
Very interesting, Daniel, as always!
One point on accidental duration. I’m in the habit of combining double ww and brass parts on to a single stave, and the orchestral parts have sometimes been published in this format. Occasionally a mistake slips through, where an accidental applying to one part – say 1st bassoon – has not been repeated later in the bar for the other voice – i.e. 2nd bassoon! I have been taken to task for this on more than one occasion… Presumably it would be easy enough to design things so that both voices on a stave had all necessary accidentals in their own right. I don’t think this problem exists in choral writing, because singers are used to taking note of accidentals in other vocal parts!
@Gordon: I can’t say much about the approach we will be taking to handling multiple instruments on the same staff, but you can rest assured that we will have solutions for the various cases of accidentals either being required or redundant for each instrument on the staff.
Daniel,
I actually preferred option C for reading (only for bars 1,2, and 4)
Program A: Look at the natural’s placement in bars 1 & 2. It’s inconsistently on the outside of the sharps, and inside of the sharps. To me, that’s more confusing to read quickly. Where Program C is easier to identify quickly what’s going on. Yet Program A gets the last bar right for me. And the third bar is an exception, I find that easy enough to read as there are only 3 things to read. Just some input.
Question: You want to allow flexibility with power. Well, is that just a “here’s different overall project options”? Or will you allow us flexibility on a specific chord’s spelling? On similar symbol issues… I disliked the Sib approach of having to hide things and put symbols in place for flexibility. Why not just allow someone to just move the existing symbol (which ties to playback) where one wanted.
Un-related question: I know we’ve expressed interest in Expression Maps from Cubase. I’m just wondering if you guys have thought more about using them or if you’re leaning on something else. Some friendly feedback: I loved Sib, but creating maps for midi instruments was a nightmare, truly. My suggestion is not to spend time re-inventing the wheel unless it needs it for your software. It’s one thing to have amazing software that’s very flexible and powerful. It’s another thing to make it easy to use. I loved when Sib changed to the ribbon. I may be alone in that, perhaps because I’m younger than the others who were used to the previous versions. Easy is better, every time. If it isn’t easy, it wastes time. I don’t like wasting time.
Thank you,
Sean
@Sean: Our current plan is to stand on the shoulders of the work done by our colleagues in Hamburg and to use VST Expression Maps as much as possible, and to try to give you as much direct control as possible over the way the assignment of sounds to playback techniques etc. is handled.
Daniel,
Sorry, another feature request: Micro-tuning
I believe I saw a notation program bundled with a library with micro-tuning options.
I’d like to utilize this with existing libraries instead. In Cubase, VST Note Expression allows for the customizing of individual notes, bypassing the 2-dimensional nature of the midi protocol.
The request: it may be useful to have an option to use a Quarter tone sharp, but to have the midi send an immediate pitch-wheel change. This would allow all libraries this functionality. And any sampler updating to the new VST Note Expression method would allow this to work with chords, release samples, etc.
Whether you like it or think it’s worth the time, does that make sense at least?
Thank you for your time! Some friendly feedback to Steinberg… I LOVE this blog. I’d love even more if it happened with Cubase. Alas, it probably won’t. I sure have feedback for that team too. 😉
-Sean
@Sean: Thanks for your comments. We definitely intend to support microtonal playback as best we can, not only using VST Note Expression (though we do intend to support that for VST3 playback devices like HALion) but using regular old MIDI as well, where possible.
Daniel,
Thanks. One last thing… no need to reply on this one.
Some feedback. One of the greatest things about the piano-roll in cubase is instant G#, no extra click for the #, shortcut, etc. 1 event = correct input of desired pitch. I’m not sure if it’s possible with notation. Keyboards are ideal, but not always available. If anything can be done to simplify the ease of fast/instant input with a mouse… it would be advisable.
Thanks again,
Sean
Gordon, even though the most of the choir singers are taking note of accidentals in case of divisi written on the same staff (or if other part is written on the same staff), the rule is so that we should repeat such accidental for another voice. However if that’s a piano part then another rule is to be used: not to repeat accidental for other voice! So the engine probably should take the purpose of the staff (single or multiple performers) into account when deciding either to repeat the accidental or not.
Typography nerd and software developer that I am, these posts have been among the most enjoyable reads of the last year for me—every time. Thanks for sharing.
Thanks for a very interesting post. Using the accidental-stacking-comparison-tool, I found myself mostly switching between “Steinberg” and the mysterious “Product C”, for some reason. One thing that came to mind was that Product C tends to visually group together accidentals of the same “type” a tad more often than the other ones (sometimes in columns, sometimes in small “islands” of only sharps/flats/naturals). Especially in chords with more than 8 notes (and often by paying the price of not having the top accidental closest to the chord). But in some cases, this visual grouping is very nice — when parsing a complex chord, you’re not just swimming in a sea of accidentals, but your brain can digest them in chunks.
It was only when I (half-successfully) reverse-engineered Product A’s accidental placing algorithm last year that I even noticed that those subtle differences from standard practice were not due to sub par implementation, but because of a slightly different focus of approach, namely to horizontally keep the stacks as tight as possible. And it’s great to see that instead of “just implementing the right rules” once and for all (as if that is possible), you take care to systematically look at the consequences of those rules. Although product A’s tucking in of accidentals often enough results in questionable stackings, there are also enough cases where it can be said that the tucking in is an obvious benefit. As so often in notation, context is everything.
Can you tell us anything about the ways in which users will be able to control and customize the default settings? Also, will your scripting interface allow to get into levels as deep as the finest details of accidental placing? (One reverse-engineering of inaccessible placing rules is quite enough for me…)
@Alex: There will be a couple of global options you can change (e.g. whether or not the algorithm should try to place accidentals on seconds in the same order as the notes, and so on), and you will also have control over things like the minimum distance between columns of accidentals, and between the rightmost column of accidentals and the note/chord to which they belong. You will be able to adjust the dx position of an individual accidental, and you’ll also be able to specify which column a given accidental should appear in, which will force the other accidentals to be re-stacked with that constraint taken into account (though this is not yet implemented). To make that kind of editing predictable, you’ll be able to force all accidentals into their current columns, so that moving one accidental to a different column can’t change the arrangement completely (though it will then allow accidentals to overprint, etc.). Although we haven’t yet implemented any scripting support specifically for accidental stacking, I would expect that you will have access to things like the column number, dx, whether or not the accidental should be shown in parentheses, and whether or not it should be hidden.
Wow. I didn’t realize Muse….er, I mean, Product E, had such terrible accidental placement. No more recommendations from me, that’s for sure (not that it had any before).
I agree it leaves a lot to be desired in this department; but see my response below. Also realize that until you get to chords with more than four accidentals, there really isn’t much difference. But I’ve actually rewritten this and other aspects of chord layout over the past couple of weeks to fix a number of glaring issues with chord layout when noteheads, accidentals, or dots conflict. Results should be *much* improved by the next release.
Marc, as a teacher I will recommend “Product E” for my pupils again and again. There have to be – and there may be (perhaps even: should be) differences between top-notch paid-for programs and open source freeware. I am coding myself and I really admire your work. I love the fact that you are reading this blog, because I think – even though there is of course competition in this field – there is a common goal: to simplify and beautify the necessity as well as the art of music notation in the various fields of musical life. I believe, that Daniel’s thoughts and considerations upon the Steinberg team’s work can and will influence music notation programming for the better.
Fascinating. I think I will definitely come back to that comparison tool to have a closer look next week!
I really like the way you deal with existing tools: treat them respectfully but try to learn from all of them, including what *not* to do.
Daniel: It’s just fascinating to follow all of the detail that goes into designing a new score writer from the ground up.
I, for one, am always grateful and impressed by your sense of detail, and your commitment to giving us the best possible tools for our work. Thanks.
Thank you for yet another interesting and thoroughly detailed look into the development process. It’s literally always a treat when you post a new update. 🙂 One question that you might have answered already in a comment somewhere, but haven’t found: do you have any plans (yet) to develop a companion app for tablets? Preferably, one with editing capabilities as well as reading/printing/playback. That would be worth a lot to me, and I’m sure to others as well. I understand that’s probably rather different a beast to tackle what with the touch screen interface and all, but it would be interesting to know what your thoughts are on this, so far.
@David: We definitely have ambitions to bring our new technology to mobile devices, but right now our focus is on building the core technology that will see the light of day first in Windows and Mac applications.
By sheer coincidence, I’ve spent the past week working on the stem side and accidental layout for what I imagine is probably your Product E. So thanks for posting this helpful if unintentionally timely article!
FWIW, I think the wrong stem side behaviors you are seeing (starting with the very first chord) in Product E may actually be artifacts of the MusicXML import, as I can’t reproduce that error starting from scratch. Let me know if I’m wrong about that. There were plenty of cases of bad stem side calculations (and even worse accidental stacking) when multiple voices are involved, but I think I’ve fixed them over the past week.
I had made a number of improvements to the accidental layout but wasn’t planning on changing from the basic “highest, lowest, then diagonal from second highest” stacking approach until seeing your comparison. I know it’s a contrived example, but it’s also hard to live with the results I see here!
Hi Daniel,
Having looked at the examples of accidental placement, I would go for product ‘B’
@Bev: Then maybe you’ve been using the wrong scoring program all these years. (Just kidding!)
Interestingly none of the examples shows chords with a unison note in it (say B flat and B natural).
For a keyboard player this isn’t much of a problem in which order the accidentals occur, but it cold be crucial if the stave is divided between two instruments and the composer/publisher was too lazy to provide separate stems. Even with separate stem the order of the accidentals is still very crucial.
For ‘cold’ read ‘could’ throughout.
Why must we coyly refer to “the most mature commercial applications”, “the leading open-source music engraving program”, instead of “Finale and Sibelius” and (presumably) “Lilypond”?
At this point I would argue that it should consistently be done just for the fun of it.
As Derek said below, I’d imagine this is for purely legal reasons. 😉
Yes it is quite fun 🙂
The leading open-source music engraving program looks the best, I would say!
We don’t have to, but it seems Daniel believes he has to. See my comment further down with my attack on secrecy.
They aren’t kept secret, otherwise the page sources would have been obfuscated. It’s probably a kind of “neutral presentation”, like if you’re doing a blind comparison of chocolate bars. I think it’s an appropriate presentation, although at least the afficionados of product X will surely recognize “their” favorite…
Urs: “They aren’t kept secret, […]”
From Steinberg’s point of view they seem to be; otherwise Daniel could have commented on the accuracy of my “attack”.
What is not neutral about using the real names?
Presumably it leaves no loophole for any legal action?
A VERY interesting post. Having decided to try to learn the scripting language with “Product A”, so that I could automate some of the many changes that I regularly make to accidental placement, and then discovering that it’s not easy/possible (I gave up before I found the definitive answer), I’m looking forward to seeing this in action when the product is released [or available for testing…]
I’m an avid (excuse the pun) reader of all of these posts and as someone who takes a lot of time tweaking the final design of my own labours it is very heartening to see that even the tiniest typographical details are being taken very seriously by Daniel and the team. I look forward to the next update.
“Each of the major texts on the finer points of engraving cover accidental stacking to some extent; Elaine Gould’s book Behind Bars is probably the most explicit and detailed in terms of both the general approach that should be taken and some key exceptions.”
I do not agree with a number of Elaine Gould’s recommendations. In a comment in the internet forum of Product E I once even wrote that Elaine really should be behind bars.
@Magnus: I have often joked that there are as many engraving rules as there are engravers. You certainly don’t have to agree with everything Elaine Gould writes in her book, but if you do disagree, you should make sure you can back up your disagreement with the same kind of research and experience that she has brought to bear on the field.
Thanks for your response, Daniel, but I don’t agree with you. Although I can back up my stance it is not mandatory to do so to have the right to disagree.
May I here in a comment guess the names of the programs A-F?
Here is my attack on secrecy:
A: Sibelius
B: Finale
C: Lilypond
D: SCORE
E: MuseScore
F: Noteflight
@Magnus: Don’t misunderstand me: what I meant was that as developers of a new professional-level scoring program, it makes sense for us to take the best-researched, most comprehensive and most up-to-date sources as the basis of our work, though of course Elaine’s book does not in any sense form a specification for how to build such a program! You are free to disagree with Elaine’s book, as is anybody, but we will generally use Elaine’s book as the starting point when tackling aspects of engraving, because it is the best available source.
Our goal, as I have said many times (including in this very post), is to produce a clear and unambiguous result that any musician will accept and read without question, but we cannot (and nor do we aim to) replace the judgement of experienced engravers. Our application will provide the tools, one way or another, for you to achieve the result you want.
There are no prizes for guessing the names of the programs, I’m afraid, and I won’t comment on whether or not your guesses are accurate.
It’s OK, Daniel. I have not read Behind Bars, but I saw a music example that was allegedly written according to rules from the book, and it was then I used the title of the book in a way Elaine herself perhaps had not expected. Behind Bars is maybe the best available source in English, but since I have not read it yet I can not say how well it stands against the books in German and Swedish (and English) I have read. Nevertheless, it is interesting that you are working on yet another score writer. Hopefully it will not be very much like Sibelius or Finale.
Thanks, Daniel – very interesting and educational, as always. You even managed to make this particularly post fun (although no less geeky!) via your interactive accidental stacking comparison chart! Keep ’em coming!
I’m curious: Is the layout of accidentals affected by the font characteristics? E.g. will a font with “fat” sharps but extra skinny naturals mean that the naturals might tuck-in where they wouldn’t be able to for another font? Or is all of this processing happen before the font metrics are even considered?
One reason I ask is I’m a fan of (generally) placing courtesy accidentals in parentheses, but, at least in Sibelius, results is a symbol that takes up a huge amount of horizontal space. (Of course it’d be nice if the typographical design was more compact…) But this got me wondering if such situations would affect the ordering of accidentals for these chords?
@Chris: The arrangement of accidentals into columns only concerns itself with the height of the glyphs, rather than the width: the tucking in of columns happens at a later stage.
Beautiful work as always, Daniel. Get going on the iPad app, though: tablets are the future.
Very Interesting Post, Having been a Sibelius user since the beginning and still use
7.3.1 , I hope your notation program will be out for release soon. Sibelius upgrade o 7.5
is full of issues now that your team is gone.
Interesting topic. I think the thing that matters to -me- is readability. I’m not sure which are ‘best’ because I’m not sure there is one ‘rule’ that applies to all cases… although I know I do NOT like the way that naturals are kinda ‘squished’ next to one another in many of the examples. IOW: I think they should get a -little- more space between them instead of being like ‘il’ in text processing. Is there a way that the user could control the ‘spacing’ in some way?
@JC: In most (all?) of these applications you can determine the minimum distance between accidentals, so you can always adjust that to your liking. What is shown in the comparison tool is the default settings in each application.
I meant more on a ‘case by case’ basis. To -me- computer ‘engraving’ looks weird sometimes because of this kind of spacing. A guy with a pen intuitively makes these little tweaks as he/she goes. I know you can do this in Lillypond… it’s definitely not a friendly process. I dunno about Cubase Score… which is the other program I use. Maybe I’m being too anal about this, but you seem like a detail-oriented guy for sure and it matters to -me- when reading… maybe everyone has certain ‘pet peeves’ in this regard and this is one of mine.
Maybe it’s the wrong term but the ‘kerning’ or ‘leading’ is often not what I would want. In good ‘english’ fonts, the rules for letter placement change a -lot- depending on their neighbours. In the case of accidentals, I dunno if this is the music font’s responsibility or the ‘program’ responsibility but I would like it to be both automatic -and- more ‘how I would do it’… if that makes sense. OK, I’m done. 😀
In the example showing how accidentals will be arranged in the new application, you have accidentally (sorry!) flipped the stem of the fourth chord, so we don’t see how it will handle the case where accidentals can be tucked under a back note.
Otherwise, an interesting article on this most arcane topic!
@Kim: That’s a good spot! In fact our application thinks that the chord in the fourth bar should have an upwards-pointing stem, and at present I don’t have the means to force its stem direction via our test harness (though that capability exists in the underlying model).
Could you transpose it up a bit (a fourth, say) so as to get a comparable chord that will be unquestionably a downstem?
I just wanted to post a general “Thank You” for continuing to post these updates on the progress of your new application. Like so many other Repliers, I eagerly look forward to them and enjoy reading them.
My engraving software history is a many-years-long use of Finale, then about 5-6 years ago switched to Sibelius when they came out with Magnetic Layout (I write large ensemble music), and now hanging on desperately to Sibelius until you guys have your public launch.
Like so many others who post here, I can’t wait!
Regarding the Accidental Stacking Comparison page, I believe there should be in the Steinberg example one purple circle for each chord 11-16, 19-22 and 29-32, and two circles for chord number 28.
@Magnus: No, those chords should not be annotated, because once there are more than a couple of adjacent notes in a chord all requiring accidentals, it is recommended to start using the conventional arrangement, i.e. to zig-zag through the accidentals rather than place the two accidentals on adjacent notes in adjacent columns in descending order. I refer you to pages 87 to 91 in Elaine Gould’s book, Behind Bars, which explains this specific aspect in particular on page 90, under the subheading Chords with adjacent notes. Inter alia, it says:
I have only annotated those chords, for all products, where Gould’s recommendation would be for the accidentals on adjacent notes to be arranged in descending order in adjacent columns. It is worth pointing out, too, that Gould expressly says that the conventional arrangement is acceptable in all cases, though she says that “it is visually helpful to place accidentals for adjacent notes in descending order, right to left, away from the chord” (ibid., page 90). I have only annotated some chords because it is my belief, based on my examination of the results given by each product, that there is some attempt being made to follow this recommendation, which by no means first appeared in Gould’s book.
I hope this helps to illuminate why not all chords are annotated in this fashion, and puts your mind at rest that this is not some kind of deception on my part to deliberately make the results of our algorithm appear superior to those of the other products.
Daniel: “No, those chords should not be annotated, because once there are more than a couple of adjacent notes in a chord all requiring accidentals, it is recommended to start using the conventional arrangement, i.e. to zig-zag through the accidentals […]”
That is according to Behind Bars, I guess. A more unbiased approach, I think, would be to annotate the reverse order of accidentals for notes at the interval of a second for all chords because that is a violation of the rule for accidentals at notes a second apart, a rule that actually can be preserved in several cases by using other, and sometimes even clearer, zig-zag patterns. I have made an example of chord number 21 I can show you.
Hi Daniel, any idea on what the computer keyboard input method would most likely resemble?
Although I learnt Finale’s speedy entry, and got very fast at it at uni, I generally now prefer Sibelius’s method (using the numeric keypad and alphabetic characters). Noteflight’s input method of changing note duration is pretty nifty and especially suitable for those without numeric keypads.
Perhaps input methods could be something you could cover in a future development diary, I’d be interested to hear your thoughts.
@Nik: We do have some pretty detailed ideas about how the input method will work, so perhaps I can share some information about it as we get closer to release. I can say that our method won’t require a numeric keypad. It won’t be especially similar to that used by either Finale, Sibelius or Noteflight, but of course there will be some superficial similarities (e.g. typing the letter A will produce a note of pitch A!).
“[…] (e.g. typing the letter A will produce a note of pitch A!).”
I think there are better methods.
Thank you Daniel for your posts. I hope your rhythm input system will still allow the placement of the hand in one sole area of the keyboard i.e. like in Sibelius, or improved. As a transcriber I really just want to keep my eyes on the original score and occasionally glance at the screen to check on progress. In “product X” every time I need to write a tuplet, a slur or an articulation not in the same keypad layer, you have to look at the keyboard. This really slows you down since then you lose your place in the score, etc. Hope you guys are thinking of these things…
As always, thank you for keeping us in the loop!
Though I’m not necessarily wild about entry cursors, I kind of hope that note-name keys (i.e., A key = A) is not the only method. For whatever reason, I find that kind of awkward… Perhaps it’s because the standard QWERTY map is configured for language, not music? (And I touch type, so my fingers want to go to words, not musical figures…) Anyway, I think Logic’s caps-lock keyboard (QWERTY keys laid out like piano keyboard) approach is quite clear and intuitive, and I’ve also always found the up/down arrows really quick and easy when using Finale’s Speedy Edit (but that requires a cursor). Of course, whatever method you decide to use, I’ll just learn it and get used to it! But for sure Sibelius’ reliance on the numkey pad is a problem… too much hassle for laptop use… and my main machine is a laptop now, so Sibelius feels a bit outmoded for my new laptop-only life! (A life I quite enjoy, btw, since I no longer have to “sync” data with a desktop, and juggle sessions around all the time.) On that note, some kind of integration for off-site backups would be kinda cool… I tend to copy current work to DropBox at regular intervals, but it might be nice to have something automatic and integrated. Presumably they’ll still be relatively small files(?).
James, do you have anything against entry cursors? Have you tried Igor Engraver’s computer keyboard note input?
Yes, I too find alphabetical note input on a QWERTY keyboard awkward. The QWERTY keyboard itself is horrendously anachronistic. It was designed to avoid the typebars of mechanical typewriters to jam during typing, and even the diagonal layout of the keys is an anachronistic rest from the construction of the mechanical typewriter. I have actually designed a computer keyboard for use with music notation software that avoids both of these unnecessities.
Hi Magnus.
Actually, I don’t personally have anything against cursors. I think they have to be implemented in a tasteful way, but they certainly can be clear and intuitive to use. Really, the Speedy Entry tool in Finale is quite good, I think, for being a fast a simple way to enter notes. The only thing that’s really annoying about it is the way the bar is visually highlighted/altered visually when using the tool. This seems totally unnecessary to me; why not just have the cursor appear in the normal bar? Very strange.
But I definitely find that I’m consciously “translating” all the time when trying to use the A=A approach. Sibelius is absolute torture to us on my laptop, partly for this reason, though also of course due to the dependence on the numkey pad.
I’m looking forward to a new post from Daniel on the input method, though! I’m sure they’ll come up with a good middle-ground. I think it’s actually a fairly difficult problem to solve nicely for a generic keyboard. I created an interactive composition program during my PhD that just used a cursor and arrow keys. Personally, I found that extremely fast an efficient (then again, I designed it!). It didn’t do Common Music Notation (mensural) mind you… Rather, it used a form of proportional notation, so I wasn’t dealing with explicit rhythmic values.
“[…] the aim is to arrange accidentals such that they appear to the left of a chord in notional “columns” in as compact an arrangement as possible, […]”
Steinberg seems to let these columns overlap, like in e.g. chord number 2, 3 and 12 in the Accidental Stacking Comparison. Is that an intended practice?
@Magnus: Yes, it is intentional. In general terms, the most compact arrangement is the most desirable, so if it is possible to make the columns interlock without reducing the clarity of the accidentals, it is good practice to do this.
OK. Yes, I agree on this good practice.
Very interesting read, @Daniel, as always.
You may be interested to now that one of the compared applications has gotten a major rewrite in it’s stacking algorithm:
http://musescore.org/en/node/25102
Can we please figure out a way to make this compatible with recording software? I use Logic Pro X to record and the notation software it uses is terrible! Awful! I have been using Sibelius 6, and then export the raw midi files, but their has to be a better way!
Maybe you could let me drag real audio into the notation software and edit it? It would be good to open yourself up for the electronic world to use your software. You would have a new market, and you would be giving composers a completely new platform.
I have lots more ideas…
I couldn’t agree more about the abomination that is Logic Pro X notation. And it’s been that way literally for decades! (I was a “Notator” user, back in the early ’90s, and it really isn’t all that different.) I was really hoping for some improvement when X came out. But alas, it didn’t happen… Having a DAW with great notation would be really amazing for me, as I tend to think differently when I have a score in front of me…
Avid, nimble-footed thugs that they are, completely botched Sibelius integration. I considered “switching” to Pro Tools when the whole Avid/Sibelius fiasco went down, so I downloaded the demo. What a travesty! They completely broke the note input routine, which completely defeated the purpose, in my opinion. I don’t want **beautiful** notation in a DAW, I want quick, flexible notation, that can handle a bit of musical complexity, beyond printing out pop tunes. All of the DAWs are sorely lacking in this area, imho. And don’t get me started on ReWire… That, to me, must be the longest-standing “workaround” in music software history. A great workaround, but not a solution. Composers deserve better! 😉
…okay, bit of a rant. Sorry.
That’s why we’re excited about the possibilities of the new notation program in the capable hands of Daniel Spreadbury’s development team. If anyone can figure out more effective integration of the Steinberg notation software program with DAW’s, they can– especially Cubase/Nuendo.
I have to throw in a comment regarding the “Accidental duration”. Having learned that the two major players don’t know about “accidental styles” was quite incredible for me. Your comment doesn’t explicitly say how you will deal with that issue (or if you’re yet decided about it), but I’m really convinced that the ability to have presets for accidental behaviour (rather than “patching” with plugins) is such an important feature. So I think you shouldn’t rely on any “superior” algorithm but give users the choice to preset the style.
Accidental handling isn’t (only) a matter of right or wrong but mainly of context and historical period. Right now we have added two more accidental styles to LilyPond to reflect common practices of contemporary notation (both modifying the “dodecaphonic” behaviour that places accidentals or naturals before each note): one that automatically suppresses accidentals for repeated pitches and one that will give each pitch an accidental/natural but remembers that for the measure so they won’t be printed twice in the measure.
I’ve very much enjoyed reading these posts. As someone actively engaged in new music and the challenges that presents for notation, I have a feature suggestion that would really open up the door to experimental notational approaches. I often find my work beginning in a traditional notation program and finishing in a vector graphics editor. The flexibility provided in the graphics editor is something that no notation program today can come close to emulating. A killer feature, in my opinion, would be the integration of vector graphics mode (ie. Adobe Illustrator, Inkscape) that would allow for the treatment of all elements on the page as freely editable elements that DO NOT follow conventional notation rules. For example, in this mode one might select a clef, now simply a font element, and copy it, paste it, move it, stretch it, distort it, etc.
Anyway, thanks for the info on the new product. Looking forward to more!
The Steinberg example certainly looks the neatest and most professional example there. If that’s an accurate example of how well, with no editing from the user, the output will appear – this is a very good sign indeed.
On that note; I realise the exercise here is to compare each product’s output with no intervention from the user (it’s ‘default’ arrangement, as it were), but I must make a small point:
Product D (SCORE, as Magnus Johansson rightly says) looks the most limited/untidy in this comparison. It is true – that is the result one will get by default. But SCORE is pretty much only used by professional engravers. The beauty of SCORE is that it doesn’t enforce anything upon the user, nor does it have any limitations (pretty much). So that is not how any SCORE user would leave it.
Daniel’s comment that “Product D is a commercial scoring product no longer under development or indeed widely used, but still used by some top publishers” begs for elaboration:
It’s fair to say SCORE is no longer being developed as it’s creator and sole-developer died in December 2013. But it is still (right now, in April 2014) used by many of the most regarded publishing houses, Boosey & Hawkes, Schott, Baerenreiter, Breitkopf & Haertel, Edition Wilhelm Hansen, Edition Peters, Schirmer (… the list goes on). These publishers continue to use SCORE for their most important projects because nothing else since then has rivaled it’s quality of output.
For a program that has been around for 30 years – that says a lot…
Just to clarify, this post is certainly *not* to undermine the Steinberg team’s work – which is obviously going well. It’s just to de-mystify ‘SCORE’ slightly, as I’m aware there are many people who might not have heard about it, and those that do probably don’t know much about it.
Hi Daniel,
This isn’t really relevant to this particular blog post, but I thought I’d post it while it’s on my mind: two things I’ve been using a lot this week (in the most recent version of a certain ubiquitous scoring program) are filters, and multiple voices on the same stave for writing drum parts. A few of things strike me that could be much improved:
1. Filters could be much more powerful by allowing accessing to selecting and deselecting (the latter is only available via a limited plug-in.
2. Many classes of objects are not available to filter with (e.g. tremolos, cue-sized objects – though the latter is again in a plug-in)
3. When you move notes from one voice to another some parameters stay (e.g. articulation) others don’t (e.g. tremolo, cue-size). They should all be bound to the note and carry through if you switch which voice it’s in.
I’m sure these are massively niche concerns, but I’ve just caused myself several hours of extra work by the need to alter the layout of some old transcriptions to achieve a consistent presentation and these three features would save most of this time.
All the best,
Will
I think I am ready for “Development Diary, Part Seven.”
Hey Daniel,
Curious as to how much of the literature and research on the topic of music notation software informs the development of this software? You mention the Gould book a few times, but there’s a lot of new research on this topic out there, just wondering if that influences your team’s decisions.
Also, I’m conducting my honours research into the link between notation method (handwritten or notation software) and creativity, and one of the research questions is whether or not notation software can ever reach the same level of intuitive design as word-processing software? What are your thoughts on this?
Cheers!
@Jared: I try to stay up-to-date with academic research related to music notation and software development, but if you know of any specific papers that you think we should be aware of, please point me in the right direction.
Regarding whether music notation software can ever be as intuitive as word processing software, I think I would challenge the assumption that word processing software is particularly intuitive!
There’s so little research out there that you probably know it all back to front, but just in case, this is probably one of the more interesting ones: Peterson, J and E. Schubert: ‘Music notation software: some observations on its effects on composer creativity’ (2007)
Anyway its great to know that research like this makes a difference! I’m waiting with bated breath for this new software…
what is this about ATOMIC notation? Do I need a geiger counter or something in order to be safe?