As summer gives way to autumn here in London, it’s time for another update on our progress. As the photo above shows, there is great satisfaction to be gained from lining things up just so. In this post, I’m going to discuss two of the areas in which we have expended tremendous effort in ensuring our automatic engraving produces as many of these moments of satisfaction as possible.
Aligning voices
When music for multiple instruments or singers is written on the same stave, or when writing for instruments capable of polyphony, such as the piano or guitar, it’s sometimes necessary to write notes that sound at the same time on separate stems, rather than as simple chords; for example, when the durations of the notes are different, or when writing contrapuntal textures.
In Behind Bars, Elaine Gould calls this “double-stemmed writing”, while different applications have different terminology (for example, “voices” or “layers”). In our application, we are calling each individual stream of notes belonging to an instrument a voice, so two simultaneous voices result in double-stemmed writing.
A voice has a nominal stem direction, which it uses in the event that multiple voices are laid out on the same staff at the same time; when a voice appears on a staff on its own, it uses what we call its natural stem direction (if unbeamed, down if the note is above the middle stave line, up if it is below the middle stave line, and either up or down if it is on the middle stave line depending on the context of the surrounding notes; if beamed, then determined by the balance of the notes under the beam). The first voice belonging to an instrument has a nominal upward stem direction, the second a nominal downward stem direction, the third upward, the fourth downward, and so on. It’s very rare for a single instrument to require more than three voices simultaneously, but it’s not uncommon for three voices to be needed in complex piano and guitar music.
Working out how to position notes in multiple voices is a non-trivial problem. You can’t change the vertical positions of any of the notes (as that would obviously change their pitches), which means that you have to determine whether or not the voices fit directly above and below each other, or if they overlap or interlock, how they should be horizontally offset in order not to collide. If any of the voices have dotted note values, an additional complexity is introduced by determining where best to position all of the dots.
In our application, several little engines conspire together to solve all of these problems. Firstly, the stem directions are calculated; next, the notes in each voice are then positioned on the correct side of the stem (normally to the right of a down-stem, and to the left of an up-stem, unless there are notes in adjacent staff positions, in which case one of the notes must appear on the opposite side of the stem, with complex considerations about ensuring that the majority of notes appear on the normal side of the stem, and so on); next, the pitches of the notes in all of the voices are considered, and voices are assigned to columns. A voice column is exactly what its name suggests: a bunch of notes positioned at the same horizontal position, i.e. directly above or below each other.
The rules for whether or not two voices can occupy the same voice column are complicated: for example, if the notes in two voices are in unison, they can share the same column if their duration is the same, unless they are a whole note (semibreve) or longer; if the pitches of the notes do not overlap or are not adjacent, they can share the same column; and so on.
In music with only one voice, there can only ever be a single voice column at each rhythmic position; in music for two voices, there will often be a single voice column but may be two, if the voices cannot occupy the same horizontal position; in music for three voices, there will normally be at least two voice columns, unless the pitches of the notes are sufficiently widely spaced that they can all occupy the same horizontal position without any collisions. Where there are two or more columns, as important as which voices are assigned to which columns is which order those columns should appear.
Once all of this has been worked out, it’s finally the job of the voice positioner to work out how close together multiple voice columns can be positioned, and to position all of the rhythm dots carefully. Let’s take a look at a few simple cases, all of which involve two voice columns:
This is the default result from our application today. (There are two different default gaps in use here depending on the situation – 1/16 space, and 7/10 space – and both of them are editable.)
Update (2014-10-01): The image above has been updated today based on the feedback from my readers, who let me know (in the comments below) that they felt the default gaps were too large. I’m grateful for this feedback, and have updated the defaults used by our application to match the preferences expressed by the clear majority. The original image can still be found here if you want to see yesterday’s results.
By way of comparison, let’s take a look at the default results from a number of other scoring applications. We’ll stick with the same identifiers we used in our previous diary instalments, so here’s Product A:
The most obvious differences are found in the second chord, where a different decision about in which order the columns should be shown has been made; Product A prefers that notes are always positioned stem-to-stem when they are adjacent or overlap, which is indeed favoured by some publishers, but in cases where the notes are truly overlapping (i.e. the stem-down note is more than a second higher than the stem-up note), the stem-to-stem arrangement occupies more space than the head-to-head arrangement used by our application.
In the sixth, seventh and eighth chords, there is no offset at all between the voice columns, so the stems overprint, and it’s hard to figure out what is really going on.
Here’s the other main commercial scoring program, Product B:
Again, the voice columns in the second chord are arranged in the opposite order, but here the stems actually collide. In the third and fifth chords, the offset is too large; in the fourth and ninth, it is too small. In the sixth, seventh, and eighth chords, Product B produces the same unsatisfactory results as Product A.
Let’s look at the results from the leading open source music engraving program, Product C:
Update (2014-10-01): I’m grateful to readers with more experience than me in the use of this product for pointing out an error I had made in the way the seventh and eighth chords in the above example were input. Having corrected that input, the results in Product C are practically identical to the results in our own application.
Finally, let’s look at the most popular GUI-based open source scoring program, Product E:
The results are almost identical to those of Product C, with the exceptions of incorrectly superimposing the voices in the seventh and eighth chords, and of a larger gap between the unison noteheads of differing durations in the ninth chord.
Of course, all of these programs provide the means to adjust these results, typically on a case-by-case basis, but once again our focus is on producing excellent results by default, with simple means of adjusting those defaults, plus the ability to override those results as desired.
Tied up in knots
Much of the art in music engraving is in solving tricky graphical problems within a given set of constraints. This is true in the case of figuring out how to align voices, and it is also certainly true in the case of drawing ties between notes, which have many constraints: their ends should not start and stop directly on a stave line; the middle of their curvature should likewise not touch a stave line; when a chord has multiple ties, they should be spaced just so and not touch each other; the direction of the curvature is determined by the stem direction of the tied-from and tied-to notes; and on, and on, and on.
We are spending a lot of time on ensuring both that the default results of our automatic engraving algorithms are as good as possible, and that you as the user will have appropriate control over those algorithms, so that you can get the results you want with as little effort and time expended as possible. Although it will be possible to adjust the appearance of individual elements in the score, such as ties, our intention is that you should try changing the default settings first: most sensible options will be available as choices at the click of a couple of buttons, and will then apply from that point onwards. You will even be able to choose whether or not to make those choices apply to future projects, so you don’t have to review them again.
This effort to produce not only great default results but also to provide extensive options for customising those defaults has been particularly extensive with ties. In fact, there are currently 45 discrete options relating to ties alone… and there may well be more before we’re finished with them.
Ties are one of the most common graphical elements in music notation, so it’s important that their default appearance is as good as possible: if it isn’t, then an experienced engraver is going to need to spend a lot of time editing them, and a user with less experience may not even realise what needs to be changed, apart from perhaps having a subconscious feeling that something about the ties is not quite right. Getting the most common things right (accepting that there is no single, objective right solution to any given music engraving problem) is where some of the biggest time-savings for professional users will come from; and for those users who lack the experienced eye to be able to fix problems at all, it also ensures that the baseline graphical quality of the music being produced increases regardless.
Let’s take a look at some of the situations that can arise when working with ties, and how different applications handle them. We’ll start with something simple, such as determining correct tie direction for a tie on a single note, in a single voice. Provided the stem direction of the notes at either end of the tie is the same, the tie should curve away from the notehead. If the stem direction differs, however, there are two possible rules: the most common is that the tie should always curve upwards; the other, less common (but advocated in Behind Bars), is that the tie should curve away from the middle line of the staff.
Our application provides the option to use either rule, defaulting to the more common one:
Product B and Product E both follow the “always curve upwards” rule, Product C follows the “curve away from the middle stave line” rule, while Product A follows neither: the direction of the tie is determined solely by the stem direction of the tied-from note, which gives an incorrect result as often as not.
In chords, it’s recommended that ties be separated vertically, ideally by one stave space, so that it’s easy to read the chord. For chords with many tied notes in close position, this can be difficult to achieve, and even more so if one or more of the notes in the chord is not tied: a tie should never be positioned close to a notehead that is not tied, since it would create ambiguity about which notes should be held and which restruck.
Here is a slightly unlikely example of two chords in close position, with all noteheads tied except for a single moving note (B4 to C5):
You can see that our default appearance tries to keep the area around the middle stave line clear, to make it obvious that a note is moving there. Product A has the next best solution, but the tie for the D is positioned in the third space, and is a little ambiguous as a result. Product C positions the tie on the A4 too high, creating similar ambiguity. The results produced by Product B and Product E are far from ideal, each requiring substantial tweaking to produce something legible.
Just as important as unambiguous vertical positioning of ties is the positioning of the ends of ties horizontally. Generally speaking a tie should be positioned as close as possible to the notes it joins, but just how close it is appropriate for a tie to start and stop is highly contextual. For example, if necessary a tie can bisect the stem of a flat or even a natural, and if unavoidable a tie can also bisect the stem of a note (e.g. for another voice moving more quickly than the tied notes or chords), but ties should not collide with note flags or with the bowl of a flat, main void of a natural, or any part of a sharp. Here are two simple chords that demonstrate both potential problems:
Only our application and Product C produce default results that avoid collisions with flags and accidentals, including changing the direction of the tie in the first bar such that it curves upwards rather than downwards (because this situation is correctly treated like a chord, rather than like a single note). Each of the other applications fail to avoid either the flag at the start of the tie or the sharp at the end.
As ever, the results shown here are merely the defaults: all of the applications provide tools of various kinds to adjust the default results.
We could spend thousands more words looking at various problem cases with ties, but the foregoing is probably sufficient to illustrate the true depth of something as conceptually simple as drawing a curved line between two fixed points!
We continue to sweat these details because we want to make our application produce the best default appearance, and to provide flexible tools of the appropriate level of granularity to achieve different results, if that’s what you want.
More to come
That will have to do for this instalment of the diary. We are continuing to work hard towards getting our product into the hands of users as quickly as possible, but there remains a great deal to be done. I hope that these diary entries give you an insight into the level of detail required to produce a truly next-generation scoring program. I always enjoy reading your feedback on these posts, so please have at it.
I appreciate your care for detail, and realize that this is a thankless task that will sometimes involve controversial decisions. I am also sorry to disagree with your considered opinion; but I find some of the gaps in the first music example too wide. For instance, apart from dyads 6, 7 & 8, I find the gaps better in the second music example. Better, that is, because I find them more readable. With your chosen default, I look at the first dyad and wonder why there is such a large gap between the B and the A, and I am distracted from sight-reading the notes.
@David: As I said in my post, the gaps used in each situation are of course user-editable, and I am certainly not ruling out further revision of the defaults before we eventually ship our first version. I would be interested to hear whether others agree with you.
I’d agree with David that the spacing in that first dyad is slightly too large as presented in that image, though certainly preferable to collision. A truer impression would depend on the context, though.
Great diary, by the way. Much enjoyed. You really can’t get too detailed in these explanations. The considered fine points are a delight to ponder, as are the comparisons to competition.
It’s Jan 22, 2015. You should check out the growing thread on Barry Finnerty’s Facebook page about product support!
I agree with David on this point. It’s possible that the bigger gaps are provably “better” by some criterion, and that I could get used to them over time, but as someone who has been reading music set more like the Product A sample for decades, I do find the bigger gap distracting and I imagine it would slow me down when sight-reading.
More importantly, thanks for all these technical posts! I really enjoy them.
Hello Daniel
Interesting, as ever.
I find Product A the best, at least for the placement of noteheads and stems.
But, for my taste, I also find the shape of Product A’s noteheads much more attractive and easier to read than yours. I recommend you take another look at your notehead’s shape.
MS
Just seen the update and wish to thank you for revisiting this. It looks much more readable now. David
I second this. From a developer’s perspective one might be tempted to feel the modified version somewhat crowded, but from a music reader’s perspective that’s clearly superior because it displays the structural relations much more unambiguously. It’s good if you can easily fine-tune default settings.
I am so looking forward to the end product. It is going to be amazing. Can’t wait.
I would agree with David – I find the spacing in the first 5 ‘better’ in product A. The gap makes it less, rather than more readable. The later ones would really depend on context, but personally I would rather no.6 as back-to-back (like no.2 in product A).
I like the gap presented in the ties example which signifies where the note is moving, but I prefer the length of the ties in product A, as the length of them implies the same note length, if that makes any sense … having said that, the Steinberg placement over the stave lines is better.
Swings and roundabouts I guess, and without wishing to agree with everything David says, probably a thankless task!
The Steinberg solution is the best because it offers all the possibilities to the composer who is thinking about how musicians would actually have to read the music. I’ve been following this forum since the beginning and many of the comments I read seem to be from people who have not had to much experience in the real world of working musicians… I, personally, will be very happy when this software is ready to go!!
I feel David’s absolutely right – the first two examples as scored by Steinberg produce a sense of dissociation between the (simultaneously-sounding) notes. That was my first, and it is my lasting, impression. I don’t want to seem harsh, but I can’t imagine why anyone thought it looked right. The others are acceptable, but maybe not ideal. All show an excessive lateral displacement to some degree.
Agree, spaces like this are good just to analyze the song voicings, not for reading.
Please adjust the spacing in example 1! Agree with others, it just looks wrong. In some of the peculiar tying situations, not sure they are important, but the cluster with single moving note, I’d say, your top ‘tie’ is more like a slur, and thus incorrect.
@intonalist: Regarding the tie on the chord with the moving note, that placement is produced because the ties on the outermost notes in chords are permitted to be positioned outside (i.e. directly above or below) the noteheads. Ties are also allowed to be moved by up to one space away from the notehead end of the chord (and two spaces at the stem end) if doing so allows the other ties to be spaced out more equally. Both of these are options that you can change: you might want all ties in chords to be positioned between notes, and you may want to disallow ties moving further away from the notes to which they apply. I would certainly challenge your assertion that the tie placement is incorrect, but your objection also reinforces my point about the importance of providing sufficient flexibility in the options that you can easily achieve a result that is to your taste.
And, further, in the cluster tie: I’d think the correct result is 5 ties, three curved up and two curved down, with, as you propose, clear space in between. Scor4’s default places the lowest of the three upper ties very close to the middle of the three upper ties; maybe I’ve just gotten used to score’s slurs and ties, but that looks best to me.
Learning about the nitty-gritty of an application such as this is so interesting to me! One thing I have been wondering about for several diary entries now is how the different engines arrive at a global conclusion on the final layout. Is it always possible to accrete their input in a sequential fashion, or does there have to be a back-and-forth between the engines? Is there some kind of manager to direct each case, or do the engines know each other? How does one engine override the input of another if necessary? How does the localization of expertise to a single engine work out performance-wise, do you need a lot of overhead traffic to establish the final (global) outcome?
I feel like a whole diary entry could be spent fruitfully just talking about this alone, and I for one would be delighted to find some answers to these questions and maybe a couple more I didn’t even think of… but I guess I’ll be content with whatever you come up with next, everything’s just so fascinating 🙂
@Andi: I think I’ve alluded to this before, at least at a high level. The engines are designed to run in parallel as far as possible, though of course there are dependencies. In this post, for example, when aligning voices, we have to first determine stem direction and assign notes to the correct side of the stem, and work out whether or not voices can share the same column, before we can actually determine how close or otherwise the voices should be positioned. Each of these steps uses its own engine, and multiple pipelines can be running simultaneously to process music belonging to multiple instruments. The order in which each of the engines runs is globally determined, and will always be the same. As yet it’s not clear what the real-world performance implications will be for very large scores, but a core advantage of the approach we are taking is that a given edit does not require the whole score to be recalculated, so unless you do something like select the entire score and transpose it up a step (or some similarly high-impact, wide-area edit), even if lots of engines have to run in sequence and parallel, they don’t have to recalculate everything, so it should still be pretty quick.
Yes, the high-level picture is quite clear, I’m just hungry for details 😉
For example, the information that the engine order is determined globally is highly interesting to me, as it has implications on the interactions the engines are allowed to have. Basically I’m just wondering how “smart” an engine is from a software engineering standpoint, does it just have domain knowledge about its area of expertise, or does it incorporate process management and interaction with other engines as well? The first case would make arbitrary changes to the pipeline much easier (because you wouldn’t need to worry about maintaining a proper interaction process when domain rules change), but it would also be harder to implement because you would have to come up with viable general-case conflict resolution strategies. Hardcoding these strategies is simpler, but also harder to change if you decide on a different interaction process after the fact (e.g. when adding a new engine). Okay, maybe these questions aren’t that interesting to the general public, but as a computer scientist I can’t help but wonder.
In any case, thanks for your reply and the original post, it’s all very much appreciated!
@Andi: As I’m no computer scientist, I’m probably not best qualified to answer your questions, but I’ll take a stab at it. In general, as I understand it, one engine does not pass its output directly to another one; rather, each one does its little job and sets up whatever state it needs to, and if a later engine wants to know anything specific about that state it has to query the model to find it out. We have certainly encountered design challenges as we go along that have required us to change the scope of an engine, or to change the order in which they are run. For example, the engine that handles voice positioning and rhythm dots was originally also going to determine the pairing and ordering of voices, but it turned out that this wasn’t possible, because the ordering operation has to be able to operate across multiple instruments (e.g. in the case of chords with notes on different staves), whereas the positioning operation applies only to a single staff. I believe a similar situation arose with ties, as well: initially we expected to be able to handle all tie positioning early in the layout process, before the final music spacing has been performed, but because the height of ties varies proportional to their length, in order to ensure that the end- and mid-points did not abut a staff line, we have to wait until spacing has been performed before they can be fine-tuned. We are making these discoveries as we go along, and certainly some refactoring is required from time to time, but the encouraging news is that so far we haven’t encountered a situation that has suggested that the basic approach is wrong.
Awesome! Thank you so much for these details, this is wonderfully fascinating! As far as I can tell, your approach makes a lot of sense, even though it would necessitate more direct interaction than one where each engine delivered an “executive summary” of its findings along to the next engine in line. The fact though is that it’s a hugely complex problem, and while there probably is no single elegant approach, yours strikes me as a viable solution to managing that complexity. You’d just have to make sure that the amount of interdependency among the engines is kept as low as possible, but I am quite sure your fine engineers are well aware of that need.
Many thanks for providing us with real-world examples of your violated expectations, it’s absolutely encouraging to hear how even a team intimately familiar with the domain and well-versed in its modelling can run into unforeseen situations with the intricacies of an unfamiliar design approach. That’s something that most non-software people just don’t get, and just putting it out there is helping tremendously! Also good for you, acknowledging that these things happen is the first step to arriving at a manageable process (as you are probably quite aware since you are doing Scrum). Again, thanks for sharing, it makes for quite fascinating reading!
It’s positively heartwarming to see the degree of care and craftsmanship going into this – and fascinating to be given these “behind the scenes” glimpses. For what it’s worth, I tend to agree with David in feeling that gaps in the first example are a little too large. I found Product A to be the most “sight-readable”.
Regarding chord formatting, I’m not sure you are using product C correctly. The assumption is that downstems are voice 2 and 4, with the outer voices (3 and 4) being horizontally offset. When I put this example input into my copy of Product C 2.19.16, I get more or less the same as the new Steinberg.
As for the ties, your point on leaving the moving note clear of ties is well taken, but typographically, things could be improved. All but product C put the ties on top of the staff lines, which is very ugly.
Finally, here are some more extensive examples (look for “collisions.ly”)
@Han-Wen: I’m sure you’re right that I’m making some elementary errors in my use of Product C! Here is the exact input file I used to produce the result shown in the image. I try to represent all products fairly in these comparisons, and my purpose is to highlight complexities and to give examples of how those complexities are handled, rather than to cast aspersions at any product in particular.
Regarding the ties, of course there are always different conventions and preferences in use, but I believe there’s reasonably general agreement that ties should cross stave lines, i.e. neither their end points nor their middles should abut stave lines. In this regard, I personally find the lowest tie in Product C’s output undesirable. In our application, the default positioning of ties is such that the end points never abut stave lines (unless they are under extreme duress in terms of having to fit more ties than is desirable into a small number of staves spaces), and if the middle of a tie abuts a stave line, you can optionally choose to adjust the curvature of the tie such that the middle avoids the stave line by a threshold distance of your specification, or to nudge the tie in the direction of its curvature by the amount necessary to clear the stave line but without changing the curvature. (I personally prefer the latter approach, since it produces ties with identical curvature provided that the ends are at the same horizontal position, and, to my eye at least, changes in curvature are more obvious and draw more attention than small adjustments to the overall vertical position of the tie.)
OK, [here](http://pastebin.com/jH38q5N8) is the correct input for your example in product C.
But (and I’d say this is a big but) is the original example correct in the first place? If you have two-voice polyphony on a staff you expect the upper voice to have stems up, the lower voice to have the stems down. Wanting such deviations as having two parallel stems as in your example isn’t a “simple case” IMO. The “workaround” in my example code is simple enough in that it doesn’t apply any manual correction but is a semantically correct switch.
@Urs: Thanks for providing your improved input file; I have updated the image for Product C accordingly. I would agree that of course in a normal situation you would not have only two voices active and force both of them to have the same stem direction. Certainly our product will not produce this result without some coaxing! But you may have two up-stem voices if you also have a down-stem voice, so the situations shown in the seventh and eighth chords in the example can certainly occur in those cases.
@Daniel: No problem. I wouldn’t have made that comment publicly if it hadn’t been here in the comments already …
Of course the last unison is still wrong, sorry – but I don’t think it matters too much here. Of course these two-stem situations happen in music with more than two voices, but especially then it’s important to tell the program which voice has which role.
@Daniel: I must confess that I’ve probably read this post a dozen times and only now did I notice that only your product’s first example includes a low g in the second voice of the fifth chord. Not sure if that was intentional or just an oversight. I also noticed that the “correct” input file that Urs posted had a minor voicing syntax error which made both stems in the final chord point upwards. Here is the truly correct version, and it includes the same fifth chord as you have in your software:
http://pastebin.com/z1bw6GcT
Always exciting stuff you are up to! Thanks for sharing your experiences with all of us.
At this stage, I’m more interested in the fact that you’re identifying the right questions, rather than in the rightness of your interim solutions. Go for it!
I really like the general approach you’re taking: (1) awesome default behavior; (2) major tweakability of the default behavior; (3) ability to make one-off manual changes at any point in the music.
If I’m reading correctly, #1 and #2 will each be a major “step up” compared to a previous notation package you worked on (not to say that #3 won’t also be more flexible).
One question: You state “most sensible options will be available as choices at the click of a couple of buttons, and will then apply from that point onwards.” I find “from that point onwards” a bit ambiguous. Upon reflection, I’m guessing you’re simply stating that you can permanently change options to new values. On my first value I thought you meant “from that position in the score onwards”. I’m guessing “permanently change options” is the correct reading?
Do you have plans for some kind of House Styles like scheme to manage these various options?
I can’t wait to see how layout of lyrics plays with all of this–I be those engines will be fascinating! 😉
Thank you for the update–I can’t wait to dive into this program, especially since I’ve been writing quite a lot of music recently. “Go team, go!”
@Chris: You’re right that “from that point onwards” means “in time” rather than “in the project”, i.e. any changes to the default engraving options will affect the entire project retrospectively, and can optionally be made to affect any future projects you create (in other words, you can update your own global style sheet). We certainly anticipate that you will be able to import and export styles and settings from one project to another, though the exact mechanism has yet to be determined.
Thanks for the update Daniel! Your blogs are always an interesting read. I have a question on the UI. Have you already made progress with it? Is it going be more like Cubase with drag & drop or more like product F*n*le where everything has to be done through submenus? I prefer the Cubase interface because it speeds up the work tremendously.
Hope you can elaborate on this in a next blog.
Keep up the good work. Can’t wait to see a beta release.
@Rudie: I would love to discuss the UI on the blog. We’re quite excited about the approach we are taking, but we don’t want to tip our hand in that department too soon. I can perhaps give a few hints: we are aiming for a completely resolution-independent user interface; we are thinking hard about accessibility for users with visual impairments and other disabilities; we are very conscious of the challenges involved in working with complex document-based applications on computers with limited screen space (e.g. laptops with a single display); and we plan to make extensive use of keyboard shortcuts, though we will also of course allow mouse use. (One final thing I can say is that our application won’t use a ribbon-like toolbar.)
Daniel,
As far as UX is concerned, the ribbon in Office is a brilliant tool because MS implemented it well. Organizing things where [intelligent] people can find them, avoiding dialog boxes like the plague, and using conditionally-available tabs based on what users are editing. It was a genius move. The Sibelius ribbon wasn’t implemented half as well (no offense, but it wasn’t).
With that said- a lot of alternatives remain very complicated. So I only ask that you guys keep it simple. I’m sure you intend to. But I wanted to submit this friendly reminder that UX is of crucial importance! 🙂
Thanks for your hard work! I simply can’t wait! If I had a TARDIS, I wouldn’t wait.
Cheers from Utah! =)
-SRJ
Hallelujah!
No ribbon = joy.
Generous tie for chords, a single one for printouts are clearer. So musicians also in bad light know what is meant. Perhaps a toggle option for figure is worthwhile.
Another thought for the Making Notes software:
Separation of a voice in choir for a passage was never solved. When playing notes it sounds too loud, notwithstanding the number of singers remain constant.
The only example which did bother me was the Steinberg approach to the big chords. I would find product A more readable. In the Steinberg version I would tend to assume that the big tie on top was actually a slur. I had assumed product A was Sibelius until I tried it and got a result unlike any of the ones shown and which I thought was better than any shown.
Can I add my voice to the comments above saying that your default offsets between 2-voice dyads are too large? If I’m sight reading a piece of piano music there is a strong sense that – at least on the first pass – I don’t care too much what voice a note is in, but I do care that notes that need to be played together appear on the score as close together as possible, indeed I’d say ideally touching.
Of course it is also good that on closer, more careful, inspection one can identify which notes belong to which voices.
But I think a clear, immediate, instinctive recognition of the simultaneity of the notes is paramount,and I find this is difficult to achieve with some of the Steinberg examples.
FWIW I prefer Product B for chords 1 and 9; Product C for chords 2,3,4,5; and Steinberg for chords 6,7,8.
Thanks for the updates on this blog – the detail is fascinating!
@Steven: Thanks for taking the time to comment. We’ve revised the defaults now, and I have updated the image in the post accordingly. I hope you will find our new defaults more to your taste – but if not, fear not, since you will be able to adjust the defaults to your heart’s content.
I agree with David, too much space except for 6-8. Prod. A is much better for 1-5. I also think that stem-to-stem should be a general user-defined setting if one choose to use this. I also think that the tie for the bottom notes are wrong. The G-tie should extend to the middle of the note head, just as the top F-tie does (given treble clef…). Except from the middle ties Prod. B and C get that right. Apart from the current topic it would be most interesting to learn how settings are handled in the software. IMO they should be externally dynamically referenced style-sheets/definition tables, not something you import like in Sibelius. Perhaps we will enjoy a report on that soon.
@Mats: I anticipate that our application will provide the option to use stem-to-stem positioning in preference to head-to-head positioning if needed. We are certainly going to default to head-to-head positioning (in contrast to Product A, which always defaults to stem-to-stem positioning, and which probably consequently looks more correct, or at least more normal, to many readers of this blog), since it is almost always more economical with horizontal space.
The head-to-head is not bad at all, and widely used in high quality piano music. I agree that one have set a “new notation standard” in seeing stem-to-stem commonly used. It would be good if one could make a selection and select which method to apply, rather than to have “all or nothing” for a complete score. The default could be head-to-head with a context menu of alternating a selection to stem-to-stem.
Speaking as a 66-year-old player, composer, conductor, and perhaps most germane to this discussion, publisher, I was quite put off by your stem placement/voicing examples.
I don’t know if it’s my generation or what, but the head-to-head notes with the wide gaps just looked comically wrong to me.
And please understand that I’m not in the slightest degree skeptical of your efforts; quite the opposite—I can’t wait to see your product!
As so many others have said, thank you for these wonderful blog entries and for the careful, detailed work that is clearly going into the building of this new software.
@Lewis: I’m grateful for your feedback, and after reading your and others’ comments, I spent the morning today with Graham, the developer in our team who has done the majority of the work on aligning voices, and we have reviewed the defaults. I have updated the picture in the post above with the results that it is now producing, which I hope will be more to your taste, and to the taste of other readers of this blog.
excellent work with this .thanks 🙂
Thanks a lot Daniel for sharing these latest insights into the future Steinberg notation software.
Keep up the wonderful work and I am really looking forward to read and see more…
Best regards to the entire team,
Max
Dear Daniel Spreadbury I read all of yours with great interest. The questions you are dealing with here were dealt with by Leland Smith (Score) some 30 years back. Some users will say ‘successfully’; some others will say ‘ not so successfully’. The key point, though, is that Score is flexible, in that the user can tweak to arrive at what seems best in any problem. This is work, but can be done. Keep it flexible and as simple as possible, I say.
@Don: All developers of notation software end up wrestling with the same questions. Prof. Smith was certainly among the first to wrestle with them, and SCORE of course produces good defaults much of the time. I don’t have direct access to SCORE myself, so it’s awkward for me to include it in all of these comparisons. I hope that our application might one day be considered a worthy successor to SCORE, with comparable graphical quality and flexibility, but built on much more modern foundations.
Wow! I cannot emphasize how much automatic decision making about complex spacing decisions like this will be a boon to blind/visually-impaired users. It has been a dream of mine for years to produce things on paper that don’t have to then be carefully looked over by a sighted person. The more of this that can happen in the background the better! As we near GUI completion, will you be accepting applications for beta testers?
Anxiously waiting to try my hand(s) at this product – which is going to be amazing!! Thanks for all your hard work and also the diaries, though most of the technical stuff is totally beyond me, but I do appreciate the effort you put into these and also your replies, Daniel.
You wrote that two notes of the same duration can share a notehead if they have the same duration. That’s not “if and only if!”
Please don’t forget to handle the case, common in piano music, of two notes that have different durations, but both have solid noteheads (i.e. are both quarter notes or less). They can also share a notehead.
For example: https://innig.net/tmp/shared-noteheads.png
You’ve probably already accounted for this, but since you didn’t mention it, I thought I would!
@Paul: Yes, our application will happily allow unison noteheads to overprint, as in your example; it does not currently allow noteheads of different types (e.g. a black notehead and a void notehead for a half note or minim) to overprint, but I anticipate that we will eventually have an option for this, too.
Have not read through the reply section…..maybe I should?
Daniel, I hope you have dashed and dotted ties in this notation program you are working on. It is very important for editorial needs.
Also, natively handling Quarter tone key signatures and accidentals would be nice.
@Ralph: We will definitely support dashed and dotted ties and slurs in our application.
Daniel, which blog post has the name of the products in your examples? I don’t remember seeing them in previous posts. Alternatively, could you list them for me, please? Thanks, Aaron.
@Aaron: I’m afraid I can’t provide the names of the other products, sorry!
Hello Daniel,
Thank you for continuing this interesting dialog, and you willingness to communicate with all of us.
A problem I have with ties is when the tie(s) cross to two or more alternative measures as on repeats. At times it is impossible to get good looking ties at the beginning of a new line if that line is not continuous with the end of a prior measure.
Ian
@Ian: Do you mean ties that cross the boundary between e.g. a first and second ending line? We haven’t yet tackled repeats in our application, but we will certainly consider these kinds of issues when we do.
I’ve scanned the replies, but didn’t find a comment on two of your examples. In your dyads, I would like to see the stems align where possible, where in examples 3, 4 and 5, it is possible, but they don’t align. I can see some situations where the non-alignment clarifies stem connections, but they just feel a little odd here.
In addition, the chord ties look good, except for the outer tie at the top. I like them longer than the inner ones, but I think that one is too long. The ends should point to the centre of the notehead, if possible, not centre on the notehead like a slur. The top ties of products B and C are better (although the other ties aren’t as nice). These would tuck in better under slurs.
Generally, I think you are making good decisions on these. Make sure you also investigate ties that go over system breaks. Sibelius’ are unacceptable, but Finale’s are better, but not perfect. They need to be completely independent horizontally and vertically, even direction, although I don’t like them in different directions – sometimes they just have to be (voice changes/clef changes).
Great Blog, wonderful dialog I am very encouraged about the possibilities with this program. As a composer and arranger for a variety ensembles and instruments I know that musicians have different preferences for their printed page. As was mentioned lighting conditions, and there are others, sharing a score (different angles of sight) or as the violin sections I&II will do, upper notes vs lower notes on the same stem for the different sections. There seem to be endless requirements for usable notation.
When writing for the guitar, classical or finger finger picking, the musician often takes their cue as to what finger on what hand should be doing what from stem direction, ties, slurs and more. For these folks, I really support great flexibility.
Though I am not a software engineer I found those comments educational and interesting.
Thank you for the udate
I’ll admit to being slightly confused. Daniel, you said that your product is based on head-to-head alignment rather than stem-to-stem? My expectation then would be that the ‘A’ and ‘C’ note heads in chord 3 would be vertically aligned, as they are with product A? Yet they’re not. I think that has a lot to do with my preference for the outputs from products A, C, and E (to varying degrees) in this exercise. Having notes that are more than a second apart vertically stack looks much cleaner to my eye than having the gap offset, and seems much faster/easier to sight read. Part of my struggle may also be that I’m very ingrained into reading SATB choral scores, so my brain almost can’t comprehend wanting two voices with independent stems going the same direction in the same staff (chord 7,8). While this is the first time in this blog that I haven’t preferred the Steinberg output, I do find great comfort in your responses to all the feedback!
@Jeff: For what it’s worth, in Elaine Gould’s Behind Bars, she is quite clear about this, and I agree with her. In the subheading Double stems under Adjacent-note chords (page 49), she says:
I agree with Elaine on this point: if the stems were aligned at precisely the same horizontal position, it would be very difficult to judge which notes belong to which stem. Also, Products A and C do offset the lower voice to the right by default, merely to a lesser degree than our application. You will be able to adjust the defaults in our application to suit your own taste if you disagree with our choices.
Chords 7 and 8 are artificial constructs, of course: that situation would only arise if there were also a down-stem voice active at the same rhythmic position, or if you made the unusual choice to force the stem direction of a note in a normally opposing voice. The point of the demonstration is that our application will take your demands at face value and ensure that the voices don’t collide even when you make an unusual demand.
Hi Daniel,
Over the course of developing a new professional scoring application from the ground up, have you gained any insights about the limitations/constraints of traditional notation — and if so, has that led to ideas for advancing notation in ways that might obviate the need for so many, as you say, non-trivial engraving decisions? Put another way, if you could invent a completely new music notation/engraving system with the benefit of all you have learned, would it look exactly like the one we have?
@Matthew: Yikes, that’s a big question! I haven’t given that question a lot of thought, since we’re not setting out to create a new music notation system: we’re setting out to create the best tool yet for working with the system we have. In a way, I think trying to invent a new music notation system would be a lot like trying to invent a new spoken or written language from first principles, and it would be hard to see how such a thing could catch on, because everybody has such a huge investment (culturally and experientially) in the languages they already know.
Hi Daniel, thank you as always for keeping us in the loop. Here’s a suggestion on how to speed workflow, where all major notation softwares at the moment fail miserably.
Treat note input like a word processor. Just how you can press Ctrl+B and then it will make all text bold until you press again (and Ctrl+I & Ctrl+U, etc.) a great feature would be something similar for slur ties, hairpins, etc. So if I’m in the middle of inputting a phrase all I have to do is press say Ctrl+T and it will draw a slur above everything I type till I press Ctrl+T again. The same for hairpins or any other text notation that applies through several notes or bars.
It would also be a huge time saver if you could add dynamics and other text markings without having to exit the note input mode. At the moment the procedure takes two steps: 1.- input notes and articulations 2.- input text markings. A great step up for your software would be the ability to input everything in a bar/bars without ever having to leave the keyboard or grab the mouse. Sort of like a typewriter.
Thank you for your time!
Daniel, are there at this point any concrete approaches for the handling of open ties yet?
@Alex: No, not just yet. In general they will be somewhat distinct from normal ties that join notes together, but we haven’t yet done any work on them. There’s always more to do!
And here I was thinking that the image you selected was to advertise that your program was going to include extensive color options! Please let me add that as a request — as a teacher using, erm, “a previous product that you have worked on” on a projector in my classroom, it would be lovely to be able to easily color everything (i.e. notes, staff lines, clef, time signatures, etc) whatever color I want. Please throw that request in the hopper along with the many others that you are receiving 🙂
Aloha D,
Love the attention to detail.
What is most important to me as an engineer is anything that helps with the musicians ‘sight reading’ ability so as to reduce studio time and costs.
sending much Aloha.
{‘-‘}
Hello,
I’m a musician/musicologist and a music software user and I’d like to know to what email adress can I write some sugestions I have.
@Calebe: You can get in touch via the contact page on this very site. I look forward to hearing from you.
Daniel,
Not entirely related, but I’m wondering if there have been any plans on making it possible to have tuplets over barlines. Not having to work around with a bunch of hidden time signatures and fake barlines would be awesome.
Love what you’re doing.
@Stephen: One of the nice things about the flexible music model that underlies our application is that tuplets either crossing barlines or being split at barlines into two shorter tuplets is trivial.
Woot!
I’m happy to say Soundslice automatically renders these various multiple-voice special cases as expected: https://www.soundslice.com/scores/13126/
I have to say that the revised spacing still looks too big, the second especially would be mistaken for two notes in succession. I didn’t see any mention of spacing for the page, that is, squeezing or stretching a number of bars in order that the printed output be of constant width per page? If so, then either a squeeze or a stretch will introduce new difficulties with any except fully closed simultaneous notes. Even in the case of two notes with the stem going in the same direction, I would far rather see the default be overlap, with the possibility of change to spacing as you show it, rather than vice versa.
@intonalist: Thanks for your feedback. As I’ve said elsewhere, both in the post and in other comments, the default gaps are user-editable, so if you find the revised defaults too wide for your taste, you can certainly reduce them. The gaps shown here are not subject to expansion or compression by way of justification: each rhythmic item has its own solid width, calculated by looking at all the things that happen at that moment (e.g. to the left, key changes, clef changes, grace notes, accidentals; to the right, rhythm dots, ties, etc.), in all voices. The distances between all of these simultaneous elements are fixed (though editable, as I’ve said) and do not get larger or smaller as the spacing changes: instead, it’s the gaps in between these columns of items that can be justified.
Daniel, I keep throwing money at my screen, and nothing happens.
I’m looking forward to a release date, as I’m sure you are too. Artists never finish their work; they simply abandon it. Or in software, version up. 🙂
🙂
I like that… “throwing money at the screen.” My waiting is totally impatient, at this point!
Please think about selling this software on STEAM or Mac App Store ’cause of user-convenience. MacBooks have not enough USB ports; meanwhile, elicensers are much fragile than iLok (2nd-Gen). Using serial number, as what Sibelius and Finale did, could be a headache if you suddenly lose all data in your laptop without any backup available around you (that means you have lost one of your available license in your rest of life.).
Dear Daniel (from Simon Rodwell, Open University)
Reading your blog with great interest from time to time. Here we are working on our latest music module still relying on Sibelius Scorch for playback from our customised web delivery.
Poor us in some ways!! I am curious to know how your team is thinking through the issues of web playback and whether you are going down the lines of a music xml style player or some other route. And also whether any such player will still be solely reliant on midi data for score playback or whether there will be a way to finally integrate some rendering of sound libraries into the process. and also whether we are finally going to get a score player that plays across all platforms i.e desktop mac/pc/linux, android, ipad etc
I don’t doubt you cannot tell me anything as an answer on these for all sorts of reasons – but it would be good to hear if they are being thought about in the Yamaha/Steinberg camp!!! We would dearly love to dump Scorch in favour of something that will play our webpage materials equally well on all platforms.
Great to read all this stuff anyway,
Best wishes
Simon Rodwell
Open University UK.
Hello there! What kind of GUI are you planning to implement? My current notation-software in it´s latest version started using the ribbon, and I want to jump off the ship. Regards, Sven
@Sven: Although I can’t go into lots of detail about exactly how the UI of our application will work, I can say that we will not be using the ribbon UI. The ribbon UI has lots of good and useful features for a mature, document-based application (like Sibelius), but we don’t feel that it’s the right choice for our new application.
Relief!
I am eager to read about how your new product will handle slurs. Your previous product with that other company almost always positioned the end of a slur at the tip of a stem or flag, whereas I usually preferred to put the end of a slur at the note head — particularly in the dense choral scores with which I usually work. There was no way to change this behavior by default. When I use this product, I have to spend an inordinate amount of time manually re-positioning the end of most slurs, which takes multiple keystrokes per instance, and I never found a way to automate the process. I hope you take this situation into account with your new product, and provide a user-definable behavior for selecting where to put the end of a slur.
@Wheat: We’re in the early stages of working on slurs at the moment, and it’s certainly our intention that you should have plenty of control over where slur end points should go, whether they go on the notehead side (which tends to be reasonably straightforward) or on the stem side (which is a bit more complicated, since as you say you may want the slur’s end point to be positioned some way down the stem towards the notehead – though not too close, I hope). My expectation would be that you will be able to get the result you want automatically, without any need for manually repositioning individual slurs, through judicious setting of the options provided.