Menu

Development diary, part four

November 5, 2013 • Daniel Spreadbury

One year ago today, my colleagues and I began work on our new scoring application in our new home at Steinberg. To mark this anniversary, I thought I would bring you right up to date with our progress. My last update took us up to the end of July, so there are three whole months to catch you up on. We’ve been continuing to work hard on getting our application’s understanding of fundamental musical concepts to be really solid, so that we can build powerful and flexible features on top of those foundations. Read on.

August

When starting a new project from scratch, it’s wise to think carefully about every decision, even the deceptively simple ones. For example, there can be few things more fundamental to an application that works with music notation than how to determine the position on the staff to draw a given note. Such a simple concept actually depends on three or more factors: its sounding pitch, the prevailing clef, the instrument’s transposition, and potentially a further transposition modifier, such as an octave (ottava or 8va) line.

And even these three or four factors represent an over-simplification: how do you even know which staff a given note should appear on? In most scoring programs, there is a tightly defined relationship between an instrument (if such a concept even exists in the application’s model), its staff or staves, and the notes it plays. Aside from special cases like being able to cross a note to the staff above or below for keyboard music, notes stay put on the staff on which they were input.

Our new application works a little differently: the relationship between notes and staves is somewhat more flexible, which will allow a number of powerful features to be built. So before a note can be positioned on a staff, it first has to be assigned to the right staff, and such assignment can change over the course of a span of music.

By the time August rolled around, we were starting to get a handle on exactly how flexible the design of our application’s musical brain would really have to be, and the possibilities that this flexibility opens up are really exciting.

Another basic component of music notation is how key and tonality are represented. Most music notation programs present a simple choice of major and minor keys up to seven sharps and seven flats, which is flexible enough for lots of music, but of course there are other mode and key systems beyond the traditional western circle of fifths, and where existing applications address these requirements at all, they do so in a bafflingly complicated way.

Our goal is to make working with keys and modes as straightforward as possible, while retaining significant flexibility. This boils down to allowing you to define a tuning system – in terms of into how many equal divisions an octave should be divided, and how many and which of those divisions should be given a specific accidental symbol – and a set of keys or modes using that tuning system – in terms of which accidentals should be included in the key signature, if any, and how transposition should work.

As the month closed, our developers had pushed the number of unit tests (which are self-contained tests to verify that the program continues to behave as expected, even as more and more features and functions are added) to more than 500.

September

Our coffee machine, yesterday. It makes a great cup, but it’s very needy.

As the weather finally started to cool off, we were blessed with the arrival of a fancy coffee machine to keep our developers fully caffeinated as they continued to do battle with notation fundamentals.

We’re working hard to make our new program as efficient as possible. It’s going to be doing a lot of work to ensure that the resulting notation looks as good as possible after every input and edit, including laying the music out on the page and spacing it, ensuring accidentals appear as they should, making sure objects are positioned correctly, and so on.

One of the potential weaknesses of any application that has to do a lot of processing after every edit is that the program can get slower and slower as the size of the data it has to work on gets larger (like e.g. Sibelius). You can guard against this problem by doing less work for the user automatically, leaving them to fix engraving problems for themselves (like e.g. Finale), or you can sidestep the problem entirely by working slower than real time and processing the whole document in a single, non time-sensitive operation (like e.g. LilyPond).

Our approach, on the other hand, is to try to be as smart as possible about figuring out the extent of the effect of any given edit, so that the program is doing as little recalculation as possible each time, and to carry out as much of the resulting recalculation as possible in parallel, taking advantage of the multi-core CPUs in today’s computers.

So our application works like a series of interconnected small engines, each doing a specific small job and passing its output on. The end result should be a program that stays sprightly even as the size of the score increases, and still does more work on behalf of the user to produce a beautiful result than all of the other real-time scoring programs.

In September, the team designed how another class of these little engines would work, and finished building the first two: one to determine where on a staff a note should be positioned, and another to determine the stem direction for each note or chord (notwithstanding how that may be modified later as a result of being grouped together by a beam, etc.).

Stem direction is another deceptively simple decision: stems should point up if notes are below the middle line of the staff, or down if notes are above the middle line of the staff, with notes on the middle line of the staff having a neutral stem direction – i.e. they can point either up or down, depending on what looks right in the musical context. But even this simple rule is quite difficult for a computer to process in real time, since the stem direction of notes on the middle line (or for chords that are equally balanced either side of the middle line) should change according to notes on either side.

This is where our application’s careful design of small, self-contained engines that can perform specific jobs in parallel should come into its own. We may be dealing only with the most simple and fundamental concepts today, but this kind of architecture should make it possible to handle more complex concepts in the same way, each with only marginal impact on the performance of the whole program.

On the face of it, you might wonder why it should have taken so long to get to the point where our application’s musical brain can determine the position of notes on staves and their stem direction, but large-scale software development is very much analogous to an iceberg – only around 10% of its mass is visible above water. More exciting, but less visible, is establishing a design and architecture that will allow each subsequent notation feature to be developed more quickly and easily, and with marginal performance impact.

October

Over the summer, we continued working on prototypes to define the most important interactions with the program. As Autumn arrived, we started working on a more sophisticated prototype written in native code to model how you will set up a project to include multiple instruments, multiple spans of music (e.g. movements, songs, etc.), and then create score and part layouts to bring them together. Our application introduces several important new abstractions, to bridge the gap between how scoring programs typically work – with their fixed relationships between instruments and staves, and enforced hierarchy between full score as master and instrumental part as linked slave – and how music works in the real, more complicated world.

To make these relationships more flexible and powerful, we have to make them more indirect, which runs the risk of making the program hard to understand. As a result, we are iterating the design of this part of the program particularly intensively, so that the way the application presents these concepts to you is as easy as possible to understand.

Another important prototype is a means to visualise music on staves. Several months ago, a very simple visualiser was written that shows rhythms, but not pitches, of notes belonging to a single voice on a single-line staff. Since then, we’ve done work on determining staff position and stem direction for notes and chords, and also have the capability to assign multiple voices to the same staff, but we’ve had no way to visualise the result on a staff. Now our test application can optionally show music for multiple voices on a five-line staff, and can display multiple staves together.

It’s still very crude: notes are not beamed together, the spacing is pretty terrible, and things like ties are drawn very simplistically. This is not by any means the basis for how music will eventually appear in our application. But it is an important diagnostic tool as we continue to add more and more musical building blocks.

Two new building blocks are now in the process of being added: an engine to work out how to group notes and rests according to beat divisions, for example those provided by a time signature; and an engine to position rests in multiple voices according to engraving conventions.

Again, each of these problems is deceptively simple, but as many wise men have remarked, the individual rules of music notation are simple, but when used in combination they become as complex as any layout problem in the fields of text and mathematical layout, if not more so. There is still lots of work to do, but the end result will be a default appearance that goes far beyond that provided by other real-time scoring applications, with lots of control available for those users who want to take it.

Our ethos is that our application will be most useful if it does automatically what an experienced engraver or copyist would do anyway. If an engraver and copyist can trust the musical intelligence built in to our application to make the right decisions, it will become a truly fast and efficient tool, and hopefully the one they will come to prefer over and above the others at their disposal.

We still have a way to go before our application is ready for everybody to use, but one year in to our journey, we are making great strides, and are looking forward to making greater strides still as we get closer to unveiling the fruits of our labours.

mm …, I’m new to this kind of forum ..
I’m also using Corel Draw (X5) to rebuild (sic) scores. For me it takes a lot of time because I have to enter every decision manually although I made a lot of symbol libraries but for me it’s worth doing this. I explain why.
Why do I use Corel Draw? Well, time consuming decisions have the advantage that I can control everyhting, even the shape of the note, the height of the stem, the shape of the slur, the used font for typography or a personal sign that is not included in a software program and so on.
I’m a professional senior visual artist en typographer, for me the overall outlook of a score has an equal value to the music and sound it represents, although its’ not a graphic score like the ones made by Crumb or Cadwell …
It’s because I simply cannot work (and study or play) from a score that ennoys me, or that not has enough esthetic proportions of white and black, used and not used space, margins and so on. By making the overall look of a score to a look that satisfies me I study better and faster. Isn’t this a very important matter?
You can call this “be obsessed by esthetic proportions”, but personally I think that all software programs are not flexible enough to adapt the used forms in it to a very personal design of the individual elements. As a typographer I know that a “good” book exists out of 60% of the content of the book (the story) and 40 % of the design/typography. Isn’ it the same with music scores?
I wonder for the reasons why you use Corel Draw?
And I wonder if the new application will take into account the possibillities of adapting the musical forms integrated in it to a more personalized style?

Rest assured Steinberg will enable us to use all the different scoring systems described in the Notations 21 Project. After all, the scoring app development began in the 100th year of John Cage’s birthday. Q.E.D.

I think Daniel knows pretty well what LilyPond can do and what not. And – putting all ‘competition’ aside – I have the impression that they are drawing from its concepts what they find useful in their context. And it looks promising to become a really interesting mélange.

Yeah it odes sound very neat. I’m late in reading the blog, it looks like though a lot of progress is being made and I hope in the end it is all as accessible for voice over users on mac osx 10.4 and higher as it can be. I realize not everything will be but I’m hoping accessibility will be taken in to consideration.

Dude, those are all tangentially related to score notation and fall more under aural aids and synthesis, for which there are plenty of softwares being constantly developed. I think they’re focusing more on the core elements of entering notes and publishing a visual score, which is something much more valuable to who I believe their target consumers are.

It would first be interesting to include a special key-switch staff, for articulations. Better yet, to be able to easily assign key-switch articulations to musical symbols, like staccato and pizzicato so that a particular virtual instrument will be appropriately triggered by textual and symbolic score elements. To make this painless for the user to do would be a first.

@Abraham: It’s much too early to say. Our development machines today run Windows 7 and a mixture of OS X 10.8 and 10.9, so it seems likely that the minimum operating system requirements will be something like that. My guess is that our application will run just fine on any computer bought in the last couple of years. But don’t hold me to that — a lot can change between now and our eventual release.

Thanks for these updates – truly inspiring. My (it’s way too early to start mentioning wishlist features requests) request is for Linux compatibility (obviously not by releasing the source code of your proprietary program – but allow us to buy and run your software, perhaps thinking of it along the lines of the Steam gaming model). Anyways, keep up the good work – it’s great to know powerful minds are still at work developing music notation software!

@Steve: I’m afraid we won’t be targeting Linux for the foreseeable future. I don’t know whether any of Steinberg’s existing products can run under emulation in Linux, but it would surprise me, both because of their reliance on the eLicenser hardware license key and because they are written at a very low-level to maximise performance. Our new application will most likely both use the eLicenser and also share some audio/playback code with Cubase, so I would imagine similar challenges will exist to get our application running under Linux. It’s not something we will support or encourage in any case. Sorry!

Thank you for this thorough explanation Daniel. It saddens me somewhat, but the practical side of my mind can accept this reality even if it excludes me from participation. Supporting Windows (and not supporting Linux) made sense when these products were initially being developed and the legacy issues involved in swapping things around now would surely present formidable obstacles with dubious immediate potential for profit.

@Steve: The overhead in supporting each additional platform is enormous, regardless of whether you start with zero lines of code or millions. Supporting mobile operating systems like iOS and Android has to be a higher priority for us than supporting Linux. I’m sorry that you and other Linux users will not be able to use our new application, but that’s the way it will be.

Are you seriously saying that your product will use a hardware key? They are a TOTAL disaster. So few legitimate products use them any more. They are expensive, get lost, broken, drivers get updated that make them not work (I had a customer who updated an entire set of point-of-sale systems with a driver offered to them via Windows Updates that broke every hardware validation key they had and rolling back the driver was problematic at best), etc.. and to ask someone to travel with them on a laptop is just asking for trouble. I will gladly stay with Sibelius or reluctantly move to Finale (which I own too) BEFORE I use any product that requires a hardware key. There are plenty of software based systems out there for license management. Find them. Use them. Do not succumb to eLicenser’s marketing hype.

@Brian: Steinberg is fully committed to its eLicenser technology, and although you are correct that they can get lost or broken, Steinberg’s technical support team works hard to ensure that any potential downtime experienced by customers is minimised to the greatest extent possible. There are still a great many products that use hardware keys for licensing, particularly in the field of audio software and plug-ins, and I don’t think it’s likely to change in the very near future. Of course the company is aware that not everybody is in love with the idea of using hardware keys, but the calculation has already been made that it’s a trade-off worth making. I’m sorry if this will cause you, or anybody, to decide that you won’t use our new application before you have even seen what it can do, and I urge you not to be too hasty.

I don’t use my scoring program for scoring. I use it for composing. I’m sure I’m not the only one. Of course, score/parts layout is important to me, but I don’t obsess over it. Again, I’ve seen enough scores written by others to know that I’m not alone. As long as my scoring program enables me, somehow, to write anything I want and move anything I want, I’m satisfied. If esoteric functions take longer, so be it if 90% of what I want to do is relatively easy to do and learn (easy to memorize commands, readily available in menus, etc).

As it happens, my scoring program throws up numerous obstacles if you want to compose in it. While I work around most of them, these problems are patently obvious to anyone who has tried to write music in either Sib or Fin, and have never been addressed. They include needlessly complex midi implementation, poor midi transcription and tedious clean-up , inability to visualize effectively those musical parameters that cannot be expressed in traditional notation, difficult assignment of midi instruments to tracks, and incredibly cumbersome/primitive record and playback features.

Daniel, what concerns me here is that while what you are doing is surely laudable and necessary, I see no public acknowledgment that many of your potential users are using these programs not just to copy and prepare music, but to create it. Nested tuplets of the kind you displayed are absolutely impressive and I will find them useful. But multiple nested tuplet layout will likely be used far less often than the record button (except perhaps by Ferneyhough) . Neither Fin nor Sib make recording midi data easy to set up and use, and I come across that problem every day while properly notating 7:3:6:5:4 dotted sixteenths rarely rears its head.

I, for one, would like to see some serious effort taken to make your program as easy to compose in as non-notation-centric DAWS such as Performer, Logic, Cubase, and GarageBand (yes, I know some of them have notation, but they’re not very developed). Perhaps such development is going on behind the scenes? I certainly hope so. If not, please consider doing so.

Despite what sounds like criticism, I’m a huge fan of this project and wish you well. The current notation programs are ripe for disruption and I can’t think of a company better suited to do so than yours.

@Richard: Making a good environment for composition is definitely a strong goal of our application. I have often trotted out the analogy that for all of the things it does wonderfully, Sibelius is more like a musical typewriter than a musical word processor: inflexible, hard to correct mistakes, unwieldy to make large- or small-scale edits. Programs like Cubase are much more flexible, and we intend to try and bring the kind of freedom you have when editing in Cubase to our application, but working entirely in notation (which is not to say that we completely rule out having piano roll or event editors in our application, of course). It seems like real-time MIDI input is an important workflow for you, and obviously we have the benefit not only of the expertise of our colleagues in Hamburg, but we also have some good ideas of our own about how to improve transcription of real-time input.

Hey Daniel, Thanks for updating us regularly! I was wondering how the new program will work inside a DAW, especially for film scoring purposes. A lot of classically trained composers I know like to “write” music than to sequence it. The problem comes with exporting the MIDI files and then cleaning up to make sense of it! I know its hard for the notation program to translate the notation into a human performance and that can be achieved by actually performing everything physically with CC automation. However, will the program (functioning inside Cubase for example) be able to independently handle music notation and playback without affecting the MIDI tracks in the DAW? So that once we have the arrangement ready in the notation program, we can start “performing” and recording it using MIDI tracks and automation in the DAW.

Also, it would be great to have customizable key switching in the new notation program so we can manually assign articulations to third party samples. Thanks again.

@Richard: My take on this future program, from the first installment of this blog and some sporadic private communications with Daniel, is that the intended target are professionals who need something that will work quickly and flexibly when the chips are down and projects need to be completed by a deadline (they of course intend to make easy projects easy to accomplish as well). They will also combine this with advanced typography. This really tells me that using the program to compose will very likely be a priority. Doing simple things simply is of course massively important; but wasting time on a single, yet critical nested tuplet (to use the tuplet example) is exactly what wastes precious time when I have a deadline looming. Therefore, turning every notation stone is something I personally applaud. This is, as I know you realize it since you praise them, a very talented team and I doubt the user will feel overburdened once the initial “shock of the new” is overcome.

Agreed. I’m an arranger, that is I can take a melody and make it sound better. I hope this program will through midi and making sure rhythms are right via the computer’s key board, and a laptop (with out a number pad) keyboard will let me do. “m thinking along the lines of sabalius but better here to have me write and arrange my choral score to look good, and be understandable and singable.

Wow Daniel! Speaking as a long-time developer, I am impressed that they give you so much time for designing and prototyping. This will be the key to a good product. I like your tactic for parallelizing the edits. Sounds like you are not only making a cool product, but enjoying yourselves in the process. Keep us posted.

Very much enjoy the updates. Eager to see a product. But I realize that is not going to be soon.
All the best Daniel to you and the team. I always appreciated your involvement with the Sibelius forum. And I’m predicting this new contender is going to be knock your socks off spectacular.

Thanks for the update, it’s really exciting to see the progress.
I have a little suggestion – since we know people copy your music (paperwise) and it will be spread even where it shouldn’t be…Wouldn’t it be nice with the possibility to add your own watermark to your scores and parts?! Just a thought.

Very interesting. Really like the way of thinking you expose in this post. So true that simple things not designed perfectly at the beginning – even if they look all right at the start – can cause a lot of problems… and a lot of workaround for the user!

For my part, as a professional copyist, I am a full partisan of flexibility. I hate it when you want to add a symbol and the software forbids you to do it because it is not the «correct» or «standard» way to do it, although there is a lot of non-standard occasions in engraving. That you aim for a maximum of flexibility is just a pleasure to read for me.

Sibelius is more elegant than Finale and the others because it was born later and had predecessors to learn from. I have very high hopes for you and this program! You’re a music notation celebrity Daniel. Best of luck to you.

I came across that crazy piece framed on the wall at Gamelan Sekar Jaya (www.gsj.org) many years ago … and transcribed it using Sibelius! Not for looks (it doesn’t duplicate the MS) but for actual playback. (P.S. When GSJ moved to a new location, they didn’t want that score anymore, so I now possess it.)

I sent this comment on your September post earlier today-then saw that the new one is up! So this duplicates a comment on your previous blog-it probably makes more sense to answer this here:

I apologize if I have missed anything you have said on this subject, but I am very curious to know if you are working on (or intend to work on) touch screen applications. The dream for me and for many others would be a situation where we could “write” in music on the screen as we would on paper and then the software would read it and turn it into printed looking music. All the present computer music writing software encourages the use of two things: repetitive rhythmic patterns and excessively complex vertical rhythmic relationships. As someone who sees new scores all the time, I would be very happy to start seeing music that was less influenced by the software used to write it! Anyway, let me know if you are working on moving in that direction at all.

@Warren: Thanks for your comment. Have you see NotateMe from Neuratron? It’s worth checking it out: you can write music with your finger or a stylus on your iPhone, iPad or Android phone or tablet, and it works really remarkably well. We’re not currently working on this kind of interface ourselves at the moment — we have our work cut out building a flexible and powerful scoring application that will be driven by MIDI, keyboard and mouse — but we are definitely interested in integrating with programs like NotateMe, and that’s something we will consider as our application matures.

Thanks! Although I am sure you will do this, I think it is worth pointing out that for us who work with composing software every day, our most important question is: how does using this software in the form that you are mostly to do from the outset of your experience with it affect the way you are likely to write music? It is very easy for me to identify music that was “composed on the computer” and in the days before Sibelius and Finale became more alike (say, pre 2009 or so) it was even possible for me to tell which program they had been composed in. I know it is always a stated goal to become “more intuitive” but intuition varies. In general most people I know have found Sibelius more intuitive than Finale, but I know some anal-retentive types who have found Finale more intuitive (although, truthfully, they are all really paper and pencil composers who use the computer largely as an engraving tool). Nevertheless, I am struck all the time by the limitations in my own work and the work of others that the computer tends to suggest to us, from the sequencing of material to the choices we make because some things are easier than others.

don’t forget to enable importing from a scan in programme like photoscore. In the current import from Photoscore to Sibelius the whole thing repaginates so the lyrics which are positioned fine under the notes are all over the treble clef stave….. Also Sibelius 7 can’t cope with importing Capo chords…. please do something to make sure you can import and that both guitar chords and their counterpart capo chords also can be printed in the right place with the right Cm7 Gsus4 F#maj7
because at the moment it might just get the C right but certainly not that its a min7 or suspended4 in the capo brackets.

Daniel, this sounds (and looks) excellent. I hope that your team provides a burst of fresh thought in the notation software market. This may be the first notational program since a certain DOS program that values notation over playback. If you continue to focus on the visual side of notation, I see this program becoming an industry leader.

I just found out about this new development today. I’m excited to see where it goes. The current big two need more competition. If I may throw my two cents of requests into the mix, I’m a professional music engraver. It’s how I actually put food on the table. 95% of my engraving is in Finale, and I’ve seen no major upgrades or changes that benefit the engraving side of a notation program since linked parts in 2007, and who knows how long before that. It seems like over the past 5 years or so the focus is all on glomming on audio production the the program, which has just been really clunky. Since Steinberg already has the audio covered, I hope your notation program is a sleek, fast, clean, mean machine. And oh dear God please make the ties look nice. Finale’s default tie positioning has always been awful.

I love your brilliant description of the many engines approach. That approach makes great sense for current computing hardware. Is it possible to end up in a situation where you have a cyclical dependency, though? In other words, engine A is waiting on the output from engine B, which is waiting on engine A?

Also (and I apologize if this has been asked already), is there any consideration of heterogeneous hardware processing (e.g., GPGPU)?

@Ryan: The precise details of how the threading architecture of our application is designed are a bit above my head, but I am confident that the team is very much aware of those kinds of issues and will set things up carefully so as to avoid deadlocks. We aren’t currently using the GPU for any calculations, but I’m sure the team would never say never.

@Jeff: We still expect scripting to be possible via an embedded Lua interpreter, which will allow you to use an external development environment to write and debug scripts. It is our intention ultimately to allow scripts to do everything that you can do in the program’s user interface, so we hope to make a pretty complete API.

(Still) very excited about this new program being developed by a brilliant and experienced team. Really can’t wait… trying very hard to be patient. Thanks Daniel and your team for listening to us users! And thanks for keeping us up to date.

I think this will be a very mature software since you are collecting many ideas from others. I will like to suggest a possible sale point. A big percentage of musicians I know use standard notation. With the development of smartphones, I would love to have a android or iOS player/pdf/editor. This could be a great point of sale, because if I can send a score that can be played in a smartphone for an instrumentalist to practice with it at a fixed beat or a beat that can be tapped in somehow, than I can also send it to the choir members to learn/ practice their songs then I would surely use that kind of software. If it is a pdf then I can store all the songs for a concert electronically and use the money that I would use to pay for a printed copy to pay for the software instead and just add the royalty fee to it. An if it is “editable” so the person can make rehearsal notes, then I would be able to save on stands … and printed material !!!

Anyhow. I guess there will be a wide range of possible uses of a powerful notation software !!!

that is really exciting and sounds in a way professional which is deeply impressing. To be able to define microtonal scales – wow!!! And I am really thankful as well that your company seemingly lets you work with an very open timescale and cares for quality only! That is what our crazy times really need (have you read Steven R. Coveys “Seven Habits” and his “Eighth Habit”?)

I realise that many comments state the obvious, and I hope that I do not do the same. Have you considered to have a tool to define ones own spacing tables as a template for the spacing which your program does? I do not know Finale very well, but in Score and Sibelius are only very rudimental built-in possibilities to influence the spacing at all. It would be great to be able to use a spacing table built from scratch by the user or alternatively to use a few predefined values only (e. g. which are too complex and time consuming for the semi-professional music typesetter). Naturally, this would be one of the most important features to be a decision maker to buy the software for the major publishing companies – now I state the obvious – sorry!

I appreciate very much that you want to create a piece of art which is able to fulfill the needs of the many different people who use notation software. (When I look at me, I assume that every user will use and perhaps discover that he needs many features which seemed to be dispensable at first). Every sentence you write breathes that determination. Thank you!

This sounds great! It seems to imply that it will be possible to have three (say) trumpet parts but combine them for a single line in a conductor’s score. Similarly, for those working with choirs, it’s often necessary to have eight+ staves showing separate SSAATTBB parts, but then to take that down to two showing SA+TB when the rhythms line up. Being able to do this without defining all combinations as separate instruments would be a fantastic time saver for choral stuff.

I’m not sure if I asked this before, but can Steinberg consider buying/leasing some virtual singer technology so that we can hear words being sung from this program, please? This would be a great help when producing learning aids for singers, and I for one would buy the package like a shot.

I agree with Iain. I use Sib all the time in this way. I also plead for an easier way to create choral+keyboard final layout. For example, instead of a one-size-fits-all approach to staff spacing, I’d like to specify choose “all the same” or “custom” radio buttons. If I chose custom in a TTBB + keyboard layout where the rhythm of the parts is the same most of the time, I would have it do automatically for me what I must do manually now: specify more space between T1 and T2 staves to allow for lyrics, and possibly the same between B1 and B2. But I would want T2 and B1 to be closer together because lyrics would not be needed between them. Then I would define the space between B2 and the keyboard treble clef staff large enough to accommodate ledger lines, rehearsal letters, expression etc., and adjust the spacing between the two keyboard staves to look right. This would then adjust everything. If I observed collisions at some point, I could tweak the settings and still have a good-looking score without resorting to the relatively blunt instruments I now use in Sib. Having said that, I VASTLY prefer the way event the current Sib handles this sort of thing over Finale and other software I’ve used.

@CSMarshall: My guestimate (based on the progress reported here over the last year by Daniel, the thoughtful deliberate careful development nature and tendencies of the developers as described by Daniel, murphy’s law, my shiny crystal ball and my consultation with several top astrologers and top phychics)….I think the new program won’t be publically released until 2015. Perhaps a beta sometime after July 2014.
I think it would be wishful delusional thinking to project anything sooner. 🙂

Hi Daniel, like others I am following your progress.
Having just purchased an iPad Air, I was wondering if you are also considering notation readability for music performers like myself (violin). ForScore seems to be in the lead in this regard. Although the iPad Air is still not quite large enough to replace paper scores, the retina resolution makes it very readable. I do hope you are considering all this in the development.
Good luck and kindest regards to you and the development team.

If accessibility is incorporated into your application, these automatic intelligent spacing and layout features will be so so useful to users who are blind! (like Sibelius’s “magnetic layout” only much more robust) Thank you for posting these regular updates on your team’s progress.

It looks like you are moving in a comprehensive direction. I am the director of four Compline Choirs (ATBarB, SSAT, AATB, ATTB) and have composed and/or arranged nearly 1000 pieces for these groups. 12 yrs. ago I chose Sibelius as my platform because of it’s alleged ease-of-use, but this did not include working with 4-line, square note value, stemless, meterless, Medieval C clefs and notation or all the quirks I found using Sib3 and Sib6. Modern tenor clef will not transpose the playback octave. It stays in treble clef. I have a list of flaws that, it seems now will never be addressed. My position is that I wish that I had purchased Finale instead, as it has the features I need to bring music written in 1177 or 1403 into our century.
Do keep me abreast of your developmental conveyer belt. I personally have a lot to gain from your wisdom and steadfastness.
regards, as always, jeff reynolds

I am not able to judge the abilities of Finale or Sibelius to notate music written in the middle ages. Yet I just tried to get something out of makemusic support. It was one of my worst experiences with user “support” at all (comparable with adobe). Such an user hostility and arrogance…

Thanks for the update. I’m particularly happy about the August details concerning modes, non-standard key signatures etc. I’m less happy about the Linux issue though but I can see your reasoning.

I only stay on Windows for Sibelius and Cubase. I follow lots of Windows blogs and can see Microsoft’s intentions to work towards a unified OS across desktop, tablets through to smartphones. They seem to consider that desktops have just about had their day and I’m concerned that eventually we’ll end up with touch screen on desktop – which in my case would need a long arm and then I’d not like the streaky marks.

I’m all for the use of tablets (large models) on music stands for consuming music but I think I’m not alone in preferring a desktop environment for composing, arranging work.

Reading all the comments above makes one realise that there are so many different areas of interest for so many people. I’m looking forward to the outcome.

I´m wondering over the possibility of importing Sibelius 7 scores into your new software. With the new OSX Mavericks, my Sibelius is dead in the water… No more music until your upcoming software release!
Please hurry up;)

@Johan: You won’t be able to open Sibelius (or indeed Finale) files directly in our new application, but we will endeavour to make our MusicXML import and export support as good as possible so that you can bring your projects over from your existing scoring program. In the meantime, Sibelius 7 runs fine on Mavericks, though you do have to contend with a cosmetic bug due to Apple renaming the system UI font in OS X 10.9 and Sibelius’s underlying Qt framework not being aware of the change. It would be very simple to fix (in theory, just a single line of code) so hopefully Avid will fix that soon.

Thanks for your updates & amazing work so far. I look forward to using this software in the future. I have two major concerns about current computer scoring programs:

1) Pitch control on playback: Sibelius makes it extremely difficult to create realized microtonal playback. This involves translating the 0-127 range of the MIDI command into a +/- 100 cents reality. As someone who would love the opportunity the hear a relatively realistic playback of microtonal works, a simple method for altering a notes playback pitch would be greatly appreciated.

2) Rhythm and the Grid: In both Sibelius and Finale a note must have a position on a grid of sorts; this is true even if the work has no barlines or assigned time signature. Sibelius assigns a default time signature of 4/4 to all works, and if one wishes to compose or score without barlines, one must accept that a meter lives hidden beneath the surface. Will there be away to truly score without any meter or barlines?

I wonder what your team’s thoughts on these issues are. I know there’s a long way to go, but have you folks answered these questions yet?

@Jude: Flexibility is very important to us. Our application’s understanding of pitch is flexible enough to allow any number of equal divisions of the octave. Similarly, our application’s understanding of rhythms and duration is based more around how music sounds than how it is written, so bars will not constrain notes in the same way they do in other scoring applications. I can’t say any more at this stage.

As has been pointed out by another poster further below, arbitrary equal divisions are a great plus, but they are also limited. In your bibliography on SMuFL, you list several texts on alternative pitch notations, and you reported that you already included Sagittal notation in your new font. Great!

However, as you will likely have already read in the literature on Sagittal notation and similar notations, besides music traditions using equal divisions there are other traditions using different approaches, in particular just intonation. Note that in contrast to equal temperament, just intonation has an infinite number of pitches per octave: the repeated transposition by any just intonation interval always brings up new pitches. Another approach are various non-equal temperaments, such as meantone temperament. Of course, arbitrary equal divisions equal divisions are approximate just intonation and other temperaments (e.g., by using 1200-tone equal temperament you reach cent resolution), but this would be a work-around.

The good news is that all these approaches are related. Regular temperaments are a formal approach to tuning that unifies these three approaches. A regular temperament (Milne, Sethares, and Plamondon 2007) generates all pitches of a tuning with a finite number of intervals called generators.

The Sagittal notation is designed to support both arbitrary equal temperaments and just intonation, by introducing special symbols for each of these generators.

If you want to have a truly flexible notation system, then please consider going beyond arbitrary equal divisions. Regular temperaments (at least somehow under the hood) would be great. Free assignment of MIDI-floats as suggested below would also be great, but regular temperament would add a rich layer of symbolic information.

Folks have commented a lot on detailed features. Here’s a comment on overall objecctives and priorities:

Using any music notation software has three phases: entering the score, editing it, and generating a camera-ready final result. When I moved from Fin to Sib, I rated them as about equal for entering and editing scores,
but I rated Sib as several giant steps ahead on generating a camera-ready score. On one occasion using Fin I had a 150-page score where the publisher asked for a bunch of last-minute changes. It took me about 45 minutes to edit the changes, and then 28 hours (HOURS) to generate clean parts and score.

When Sib added mag layout, I could print a score with only a glance for red-highlighted glitches, but generating parts still takes a good bit of tweaking.

@Phil: This is the point I’m making when I say that it’s our aim to have our application do automatically things that a skilled copyist or engraver would do anyway, and thereby save them time. We’re spending a huge amount of time working on fundamental aspects of music notation so that our application gets these things right. (If a headline feature of a major new version of our application, years after its initial release, is that, for example, you now see the single, correct accidental on unison notes in two voices rather than two duplicated ones, then we will have failed.)

@John: We’re a long way away from beta testing at the moment. As and when there is information to share about how to get involved, I will post it on the blog. Be warned, though, I expect there will be many more willing beta testers than we will be able to accommodate in the testing programme.

@Gyorgy: It will be a brand new scoring program, separate from Cubase, though we hope that it will interoperate well with Cubase, and ultimately some of the technology developed by our team in London may find its way back into Cubase. We are certainly going to be using technology from Cubase in our scoring application.

Thanks for the update Daniel!
Two components that me and my SkyPrep crew would be greatly interested in would be:
1. Using the scripting tool to create accurate importing of MIDI data based on specific sample library patches. As you know, one of the most time-consuming aspects of orchestration/music prep is the deciphering process when we receive MIDI files from our composer clients. It’s most notable in percussion and solo instruments with lots of key switches for different articulations/embellishments. We’re currently doing this my memorizing the layouts of all these patches and/or transcription from audio files.
2. A suggestion to consider for the user interface would be a context sensitive pop-up window for inserting special characters and symbols. For example: In text this would be foreign language characters or symbols. In notation this could be a user preset of Polish school notation. The workflow benefits would be the ability to input in a keystroke+mouseclick function what would normally take many menus and mouseclicks to do in Sibelius or Finale.

@Snake: I’ve read your list of requests. I can’t provide individual feedback on whether or not certain features will be included, but I think what you really need is a DAW with good guitar tab features, rather than what we’re building.

While you are addressing basic layout questions, I hope you will also address what I consider to be the most serious issue that prevents Sibelius and other notation programs from turning out orchestral scores that are truly professional in quality. I am referring to the inability of these programs to vary the staffsize on some, but not all, of the pages in a large orchestral or operatic score. In a large, lengthy score, the number of instruments displayed on each printed page can vary greatly. With these programs, the typesetter is forced to choose a compromise staffsize that accomodates the maximum number of staffs displayed in a movement, even if that maximum number of staves may cover only one or two pages in a 100-page movement. That tiny staffsize may be completely inappropriate for let’s say 95% of the movement that displays far fewer staves per page.

The only way I have found to reset the staff size within a movement is to break the movement into several separate pieces. That is a terrible solution, since it may cause many unintended consequences later on. So, I am hoping that this new music typesetting program will permit the user to set the staffsize for each individual page (or groups of pages), depending on how many staves are displayed on each page.

@Mark: In fact, Finale can vary staff size from page to page, but you’re right that Sibelius cannot. We do intend to make it possible to change the staff size at page breaks in our new application, if the nature of the work calls for it.

Just wanted to mention Music XML 1.1 compatibility. This is because some people use IRCAM’s OpenMusic and its export as XML feature. Sibelius was always not very good at interpreting these files. For me, compatibility with older and present versions of Music XML would be a must….

@Bob: we @neoScores are working on an html version for the performing musician live on stage (http://demo.neoscores.com). We are following up as many online sources about digital sheet music as we can, in particular this one from Daniel. @Daniel: Thank you for being so open in your communication.

I have more than 25 years’ experience in systems analysis and application development and have been a Finale “power user” for more than 10 years. As such, I was quite excited to read this. I believe that you are taking the right design approach and am very interested in following these posts to see where it leads you.

In early music you often have to issue the same score with original C clefs and with modern suboctave treble clefs. This is extremely annoying and time-consuming with the Sibelius approach (that a tenor with a suboctave clef is a transposing instrument, like a double bass), where you have to define new instruments just for a clef change.

In general, there should be a possibily to operate with instrument changes (range and sound patch), staff type changes and transposition changes independently of each other.

You’re seriously including native microtonal support? That’s RIDICULOUSLY COOL. I’d like to mention one of the difficulties I’ve had with Sibelius, which is that notes on the staff are fixed (or at least I think they are); an A is an A on the staff, period. I wish I could get around sound sets’ limits on MIDI pitch bends by reassigning a note — make a particular written A actually play back as a B, say, without changing transposition. (It’s a kind of extreme example, but if you’re in 7edo, an Ex or Bx would need to be bent downwards more than a whole step.) This would also open the door to staves with arbitrary numbers of lines for more flexible microtonal notation.

Anyway, I’m really glad you guys are doing this. I’m looking forward to using the software when it comes out, even if you guys take as long as George R. R. Martin to finish something!

I am happy to read that the software development crew stayed together to build up a new application. My harps and I am wishing you the best outcome, we are staying standby for the features to come. As already mentioned multiple times, for doing composition it would be nice to have more time flexibility (moving the notes or groups of notes left/right) instead of the rigid timing frame being used by Sibelius until the last version.

Thanks, Danie,l for these updates; it’s incredibly exciting to hear how things are developing! I’m desperate for an alternative to Sibelius/Finale and very much look forward to what you guys manage to produce.
I just wanted to mention that I’ve been quite curious about Wallander’s “NotePerformer” package, and wonder whether something similar might be in the works for this new program? Specifically, I think it would be amazing if you could work something out with the SampleModeling people, since those instruments seem to be pretty much top-of-the-line, in terms of combining flexibility and expressivity with sound quality and realism (VSL is also great, but memory is an issue — though this could be worked around by rendering offline while the score is being created). Perhaps a similar approach to NotePerformer/Wallander Instruments could be devised, whereby a special, inexpensive version (i.e., without the live performance capability) of their library could be used as an addition to your new program? It sounds like they may have a fairly complete orchestra (with the exception of percussion – but Steinberg should have all that) around the same time that your new program is ready. As a composer who has, little-by-little, wound-up composing entirely in software, I think it would be really amazing to have 100% configuration-free, high-quality score playback in a notation/composition package. NotePerformer is good, but I think SampleModeling is pretty much unbeatable, so a similar concept with their content would be amazing. And since a proprietary, intelligent system like this could know all the details about the notation beforehand (i.e., “looking ahead” in the score), you could model all sorts of complex controller info, to really “interpret” the score, and come up with pretty amazing playback, I think, with no extra effort from the user – just compose as you’d want it played!
Just thinking out loud.

I just found out about the development of this new software. It all sounds fantastic! I am a long time Sibelius user, and I am sorry to say that my AVID experience has been pretty unsatisfactory. I will consider switching as soon as this is released. Please consider supporting not only “equal divisions of the octave” in your microtonal support. What about having internally something like MIDIfloat for pitch definition? Old MIDI gear would just be happy with the integer part and one could write some script to decide what to do with the float part. The issue with equal divisions is: most non western (or even old western -vicentino, etc-) use some sort of non-equal division. Of course you could divide the octave in so many equal parts that the differences did not matter anymore, but then would be quite cumbersome to “group” these divisions to represent the “non equal” steps you are aiming for. Really, for both early and contemporary music, non-equal divisions of the octave would be quite important. May be is it possible to implement the values as ratios for an octave (or other intervals of non-octaviant spaces) and then project that modulus to the whole useable range? I think “Scala” does something like this?. Again, MIDIfloat seems like a not so bad idea perhaps…

Thanks so much for the updates. I’m fascinated to see how this all turns out. I have no doubt (at all!) that the scoring facilities will be at the top of the top drawer in reasonably short order. It’s incredibly fortunate that this is happening at a time when Sibelius appears to be in such trouble.

The area that interests me most is how this development views and progresses the relationship between itself, Cubase and increasingly large, more complicated and more lifelike sample libraries. Personally, I think there’s a huge opportunity to make a Score Editor, and not the ubiquitous Key Editor, the basic default for music editing (can I have a hallelujah?). But as long as Key Editors have more detailed processes for how to get the best out of these sample libraries, that won’t be happening anytime soon. The answer, at least to this non-programmer, is surely to begin to incorporate those same processes…?

Anyway, in the meantime FWIW a couple of things to appear at some point that I’m crossing my fingers for:

1) Working in conjunction with Cubase, a basic solution, intelligently mindful of implemented articulations and complete with auto-mode / presets, that can automatically suggest and implement Modulation, Volume / Expression crossfading curves etc. that can subsequently be edited. Frankly, I’d sell my granny for this.

2) Sticking with the Cubase connection, *total* integration. By all means two programs but if you have both programs, this replaces the scoring facilities in Cubase. They need to work together as one – we should only need to open one program for them both to function. No need for importing / exporting. And rather than constantly switching between different windows, we should see panels of key editing facilities that allow us to (broadly) work with both at the same time.

David T….you pretty well voiced all of my wishes for score orientated development/integration with Cubase. However there seems to be trend with all the updates in Cubase, that the Steinberg developers are catering more for users who predominantly use the synth/loops and audio features more so than score/orchestral sample libraries/MIDI features….And gauging from the Cubase forums this seems to be their core market, based on feedback and feature requests at least.

Unfortunately,each new update tends to add a new synth or two and audio features, at the expensive of evolution within the score editing/composition department. Although version 7.5 (not yet released as I write), has added a new inspector in the score – which allows easy access to features found in the key editor.

If when any integration within Cubase were to be done by Daniel’s team, I’m not sure how adding plenty of sophisticated notation features will go down with those who don’t use the score editor at all (quite a large number I would imagine). Eventually maybe a split will occur – so two programs, each catering for their respective workflow orientation. If this ever happens I hope all the MIDI sequencing features are left intact in the notation orientated version. A purely linear compositional method (as with most notation programs) is nowhere near as flexible as having a sequencer with a dedicated arrange track, and now with v7.5 – track versioning within each Project track.

I haven’t read all the comments (just found this blog today) but on the topic of middle-line stem directions, my understanding is that for most instruments they usually are down, or perhaps either up or down depending on nearby notes, but for vocal music there is a preference for stems up to avoid interfering with the lyrics.

Re lyrics: I sure hope you can improve on Sibelius in your treatment of hyphens. In Sibelius they usually appear ok when they are input, but almost always need to be adjusted by hand if any change is made to the music after input. As someone who deals with lyrics all the time, I would appreciate some careful attention to this detail! Best of luck!

Hope you are in good health and things are going well. I presume it’s very early to think about what sounds to have in the new program? But, when the time comes please, please can we have some good British brass band sounds? It’s artificial I know but other sound sets never produce the warmth of a British brass band. I don’t know how it’s done but maybe samples taken from the guys at Black Dyke or Cory?

Since people seem to be using this blog for feature requests, I have two very small ones:

In Sibelius, “crossed” voices (e.g. voice 1 *below* voice 2) are notated “stem-to-stem” or “back-to-back” — a practice used in about 50% of published music. But the other 50% uses “head-to-head” spacing (i.e. the note heads are, roughly, vertically aligned). Sibelius requires a plug-in to change to this spacing. I’d like to see this instead as a option in Engraving Rules.

Also, when two voices share the same pitch but have different time values, it would be nice to have an Engraving Rules option for the noteheads to coincide.

I suspect that the flexibility you describe will probably make these easy.

@Dudley: In fact I think the default should actually be “head-to-head”, and in my experience rather more than 50% of music uses this arrangement of noteheads for opposing voices. Thanks for taking the time to make your suggestions!

@Krystal: You will certainly be able to use any third-party VST instrument or sound library with our application, yes. The exact level to which support for particular sound libraries is provided is yet to be decided.

The strongest hope your procect has brought up to me, is the perspective to close the gap between notation of music – I actually do in Finale + Sibelius- and producing reasonable renderings -I actually do in Cubase (in my opinion the playback options of the 35Gb Sibelius Sounds or Wallander Noteperformer or Finales GPO are nice for quick first impressions, but will never meet the demands of serious a musicproduction,possible in well developed Sequencer like Cubase.
So keep this inside the software which is developed for: That means before you are trying to invent your another pianoroll, midi, and Tempocurve-Editor presumably still less developed than that we already have in Cubase I would prefer that you should focus on the highest possible Integration with Cubase. Care for that Cubase benefits from your Scoringprogramm. For instance would it be pretty cool if it would be able to edit the Sequences of Cubaseprojects from the GUI of your Scoringprogramm.

With the Concept of VST-exppression-maps. Cubase already has made an important step.towards realising more detailed and precise what might be written in an score. Make sure that your scoring programm uses this potential as much as possible.

But still this need a serious reflection about the difference of a musical score and musical production. As even the most detailed “Urtext”-Edition of any Composition could not do more than to “indicate” the scope of what might be meant since it still leaves many important musical decisions and details open for the “interpretaion” of the “performer” (the producer in Cubase), the VST-Expression and the the way musical articulation is communicated between Score and DAW definitly must be open for different Variants. Let us take f.i. a certain articulation for instance a Violin-Staccato, Portato , etc. An actual high developed Orchestrasamplelibrary provide you with lots of different Protato or Staccato-patches. Thus for musical production the articulationmark of the score does not more than to narrows down a bit the variety of possible available sounds. It is nothing else with changes of dynamic or tempo intensity/velocity. Whatever the score might notate could never give the complete decision but just the scope of what might be the idea.

Those are just “classical” examples, but thinking about the communication of scoring and musicproductionsoftware it would be a huge step forward if you would think for all a scoringsoftware might allow to notate about, how this additional information might be comunicated to musical production helping to keep inside the scope of what is notated while being still open for detailed decisions for the realisation/production. The other way round take a look of what variety of possibilties the musical production has to define and think about if and how any of them could be described in the conventions of notation to communicate this to the musical production/sequncer = Cubase.

I know my ecpectations are quite idealistic, but whereelse is the place for “ideas” if not when you are developping somthing new. I still hope this Scoringsoftware will bridge the gap between scoring and production more than any other befor.
best
Steffen

Great to see such a flexible and powerful approach to microtonal music support! For what it’s worth, I would like to request the ability to also customize how pitches are arranged on the staff. This would provide support for alternative music notation systems like those documented by the Music Notation Project here: http://musicnotation.org

Thanks for the update and for all of this great work. I can’t wait to see the final product, but I’m glad you are taking the time to really do it right!

We are heading towards paperless music notation. I hope developers are keeping this in mind. For instance, turning the page through a wireless foot switch would be so ideal. Since Yamaha owns Steinberg, this should be in the offing. I would also recommend that color be incorporated into music notation finally. There could be many advantages to this extra information. Why be glued to the past? I would like a way to more precisely indicate velocity rather than the limited accent marks.

DANIEL Spreadbury: PLEASE DON’T FORGET…try your best to include the ability to simply move/click drag notes horizontally to another beat!!! It is so stupid that Sibelius does not allow this! I hope you will include this capability in your new app.

2) COPY NOTES 2:
Copy notes, then using a bar/beat transport, be able to click transport and input a specific bar bar/beat (1/4 note, 1/8th note, 16th note) and paste notes at that specific location (at paste location, one will have to the option to delete any notes present at paste location or to merge pasted notes with notes present at paste locations)

Hi. New notation program will be able to create advanced contemporary music scores as the Finale? It will be simple and intuitive to use as Sibelius? Pay attention to copy of tuplets. We cannot do this in Sibelius.

Regarding “Lead Sheets”: Often times one creates a lead sheet and at some point in the song, a modulation/key change occurs. Please include the ability to “transpose into another key” one or more selected chord symbols. It is such a pain in the butt that this can not be done in Sibelius 7, forcing one to have to reenter a whole bunch of new chord symbols for modulated song sections.

Is it true that Steinberg has postponed further development of this new app for at least 2 – 3 years due to the death of Daniel Spreadbury and 4 project engineers/developers teammates in a bungee jumping accident on Friday??????