As the year draws to a close, thoughts naturally turn to the events of the past twelve months, and indeed to the promise of the year ahead. For us, the past year represents a lot of forward progress on our project, but the year ahead will bring more milestones on the road towards the release of our new application.
A year ago, we were around nine months into the development of the music engine at the heart of our application, but really had no functional application to speak of: we had a test harness that could display only (unbeamed) notes and rests imported from MusicXML, but nothing in the way of interaction. Over the past year, we have chosen and adopted a new application framework, introduced the basic editing loop, built the skeleton of a functional application, developed our step-time input method, added grace notes to our music model, added ties, articulations, ledger lines, time signatures, key signatures, clef changes, accidentals, beams, and so on, and so on.
We are still building up the core of our application’s functionality, but our approach remains to focus above all on quality, rather than speed. If our application is going to be worth the time and attention of professional composers, arrangers, engravers, copyists, and teachers, then it must not only have a critical mass of features, but it must also have both a more efficient workflow and a faster path to excellent results than the tools professionals are already using. That’s a high bar for us to meet, but we are determined to clear it.
Don’t get me wrong: we are going as fast as we can. But we are committed to developing an application that will redefine the state of the art in scoring software, and that can’t be done overnight.
Enough with the ghost of Christmas future. Let’s talk about the ghost of Christmas past – what we have been working on since the last instalment of this diary at the end of September.
Grace notes
Grace notes are tricky creatures, because they are arrhythmic, i.e. they do not follow the same rules for duration as normal, or rhythmic, notes. For a long time our application’s music model didn’t support them at all, because it wasn’t clear how best to support them in such a way that didn’t cause problems elsewhere.
The simplest, most fundamental representation of music in our application’s music model is analogous to how a human listener perceives it, i.e. a stream of notes with pitches and durations, in time. Considered in these terms, grace notes are just the same as other notes, and you could choose to write them either as grace notes or in the same way as all other rhythmic notes, using very short note values. So our initial thought was that grace notes should indeed just be the same as rhythmic notes, and that these very short notes could be rendered either as grace notes or as rhythmic notes of very short durations, as desired: in other words, it would be easy to convert to and from grace notes.
However, once we started considering this in earnest, a number of problems began to rear their heads. The most serious turned out to be that if you wanted to edit a grace note, you would also have to edit either the rhythmic note before or the note following the grace note: inserting, say, another grace note before a rhythmic note would require the duration of the rhythmic note to be reduced by the duration of the new grace note. And, furthermore, the rhythmic note would then have to be displayed using a note value longer than its played duration, since the played duration of the grace notes would have to be subtracted from its notated duration. In other words, it would be convenient for playback, but inconvenient for more or less everything else!
On balance, this no longer seemed like a good idea, so we came up with another approach: because grace notes always precede a rhythmic note1, they should be stored with that rhythmic note. We decided that the grace notes that precede a rhythmic note would be stored separately from the rhythmic notes, like their own little mini-score of all of the grace notes in all of the voices at a given rhythmic position. This was important to allow multiple simultaneous grace notes in different voices at the same rhythmic position to be spaced correctly relative to each other, and to the rhythmic notes they precede.
The real benefit of this approach turned out to be that, because grace notes are stored in their own mini-scores, the existing engines – that determine staff position, beaming, accidentals, voice ordering, etc. – could all be modified to work with runs of grace notes relatively easily, so that grace notes are, where possible, treated the same way as rhythmic notes throughout the application.
The major difference between grace notes and rhythmic notes, of course, is how they are drawn, and how they are spaced. Grace notes are drawn at two-thirds the size of rhythmic notes, and they are spaced more closely than rhythmic notes. Furthermore, the space between grace notes should not be justified (stretched) when the music is spread out to fill the width of a system.
Grace notes should also be positioned as close as possible to the rhythmic note they precede, which is surprisingly tricky in itself. Consider the following simple case, where there is space for a grace note to tuck in over an accidental belonging to the rhythmic note:
As a reminder, Product A and Product B are the leading commercial scoring programs, Product C is an open source music engraving program that uses text-based input files, and Product E is an open source scoring program. Only our application and Product C correctly tuck the grace note in here by default2.
Other situations also require manual adjustments in most other scoring programs. For example, to have one or more grace notes before a barline, and one or more grace notes after the barline and preceding the rhythmic note, is problematic: in Product A, a grace note can be dragged before a barline and will in general stay put, while in Product B and Product E it’s not obvious how to achieve this at all. Placing a clef change in the middle of a run of grace notes is even more problematic: neither Product A, Product B, nor Product E support this at all.
Our application does its best to handle all of these situations with grace (if you’ll pardon the pun), so that even the most demanding use of grace notes, as found in particular in keyboard literature of the 19th century onwards, is accommodated3.
We still have more work to do on grace notes: at the moment, we are not drawing the slash across the flag or beam that denotes an acciaccatura rather than an appoggiatura, and a couple of the existing engines that run on rhythmic notes have not yet been updated to run on grace notes too, but in general we are satisfied that our approach to handling grace notes is sound, and above all will produce stable, well-spaced music that requires a minimal amount of manual adjustment to achieve excellent results.
Articulations
In other applications, the term articulation is used to cover a multitude of things, spanning ornaments (turns, mordents, and the like), holds and pauses (fermatas, caesuras, etc.), playing techniques (harmonics, snap pizzicato, etc.), as well as actual articulations.
Those other applications presumably group these disparate elements together because they nominally share characteristics, such as how they are positioned relative to notes and chords, and perhaps how they are drawn by the software (typically using one or more glyphs or symbols from a music font). In our application, by contrast, we are trying to keep musical concepts (which are in the domain of the user) separate from implementation details (which should remain fully in the domain of our engineers, and not leak out such that the user needs to understand how the program works).
When we say articulation, we mean the following definition, taken from Gerou and Lusk’s excellent pocket-sized Essential Dictionary of Music Notation4:
Articulations are symbols used to indicate how a note or chord is played, alone or in relation to other notes and chords.
There are articulations of duration (from shortest to longest, staccatissimo, staccato, tenuto-staccato, tenuto), articulations of force (accent, marcato5), and, less commonly, articulations of stress (stress, unstress).
A given note can only have one of each of these kinds of articulations (e.g. it can have staccato and stress, but not staccato and staccatissimo, or stress and unstress), so if a note or chord already has an accent and you specify that it should have a marcato, the accent is removed and replaced with the marcato:
Editing articulations on notes
This also extends to chains of tied notes. In our application, tied notes are treated as single events, regardless of their duration. This means that when you edit the pitch of one note in a chain of tied notes, the pitch of the entire tie chain is changed; likewise, adding, removing or changing the accidental on a chain of tied notes affects the whole tie chain. Indeed, when you select any note or chord in a tie chain, the whole chain is selected, to reinforce that this really is a single event. Most other scoring programs store each tied note as a separate entity, which means that as you edit the pitch, accidental, or articulation of one of those notes, odd things can happen to other notes in the tie chain (e.g. changing the pitch of the first note in a tie chain will not change the pitch of other notes in the tie chain). The particular benefit that this gives in the case of articulations is that you can select any note or chord in a tie chain, and when you add or remove an articulation, it will automatically appear on the correct note in the tie chain (by default, articulations of force and stress appear at the start of the tie chain, i.e. at the attack of the note, while articulations of duration appear at the end of the tie chain, though you can of course change which end of the tie chain each type of articulation should appear). Our application makes sure that the notation always makes sense to a human reader.
Taken in isolation, articulation positioning is relatively straightforward to handle: articulations of duration go closest to the note or chord, followed by articulations of force, with articulations of stress furthest away. In single-voice situations, articulations go as close as possible to the notehead (except for marcato, which can optionally be made to always be positioned above the stave), which means they are allowed to go inside the stave if they fit between the stave lines. In multi-voice situations, articulations go to the stem side of the note or chord instead, and are centred on the notehead (unless the only articulation present is a staccato dot, in which case that can be centred on the stem instead).
Where things get interesting is when articulations are in the mix with tuplet brackets, slurs, and octave lines. The rules for how these four distinct types of notation interact are complex, to say the least: for example, articulations of duration should be positioned inside slurs, while articulations of force should be positioned outside slurs if they are located on the note or chord where the slur starts or ends, but may go inside the curve of the slur on intervening notes, if there’s sufficient room; articulations generally go inside tuplet brackets if they are positioned on the same side of the notes and chords, but tuplet brackets are allowed to nest inside slurs, if the duration of the tuplet is completely encompassed by the slur, and so on.
Our application draws tuplets, but does not yet draw slurs or octave lines, though both of those notations are currently in development. Once all of them are supported, the fun of figuring out how to position them correctly in relation to each other will be able to begin.
Rhythmic spacing
The tucking behaviour I described earlier on concerning grace notes is part of the more general approach to spacing used in our application.
The first step in spacing music is to create what Ross6 calls punctuation, which involves creating a rhythmic condensation of the music, as illustrated here:
In the above image, the single-line stave represents the rhythmic condensation of the music (I use the term loosely) on the lower two staves. The condensation provides the list of all of the columns that must be spaced. The minimum amount of space allocated to a given column is determined by its rhythmic value, but this space can be increased if required, e.g. taking into account the width of accidentals to the left of a note, and flags and rhythm dots to its right.
Most scoring programs treat each column as if it is made up of a rectangular block that extends the height of the stave, almost as if each column is on its own piece of movable type (as indeed once upon a time it would have been). Two adjacent columns cannot overlap, so if there is something to the left or right of those columns, they are pushed further apart, regardless of whether the elements causing the additional space to either side are likely to collide. The grace notes image above illustrates this quite clearly – the grace note can tuck in above the accidental on the rhythmic note, but most scoring programs do not do this, because the grace note and accidental are in separate columns that cannot overlap – and the image below illustrates the same principle:
The areas shaded in green show where two successive columns are allowed to be separated only by the minimum space required for their rhythmic durations, despite the presence of accidentals to the left of the next column. Only our application and Product C7 allocate only the minimum space to each column: all the other applications effectively draw a vertical line extending the height of the stave between the columns, and only allow the edges of those columns to abut, not to overlap, as shown by the areas shaded in red.
This approach to spacing has some parallels with kerning in typography, whereby the spacing between characters is adjusted to ensure a pleasing appearance. Our application similarly kerns adjacent spacing columns to eliminate rhythmic distortion, producing an even, pleasing result automatically and removing the need for time-consuming adjustment of rhythmic spacing.
I will undoubtedly return to rhythmic spacing again in future instalments of this diary, since there is a lot more to say about it.
What’s next?
If you’re still with me after all of that nerdy detail, thank you for reading, and thank you for taking an interest in the development of our application. There are lots of other things going on in areas like the visual design of the application, key interactions in setting up new projects, and inputting and editing music. No doubt I will cover some or all of these things in future instalments.
In the meantime, on behalf of all of us in the scoring team here at Steinberg, I wish you a very merry Christmas and a happy and prosperous New Year.
- You might be asking yourself about grace notes at the ends of trills or glissandi, or grace notes at the end of a bar (arguably terminal notes at the end of ornaments are not grace notes, but let’s not quibble). These grace notes can still be considered as belonging to the next rhythmic position, but they steal their played duration from the notes they follow, rather than the notes they precede. This distinction is necessary for playback, but not for drawing and spacing the grace notes. ↩
- Of course, it’s possible to adjust the spacing of the grace note relative to the rhythmic note in all of these programs, but, for example, in Product A there is always extra space to the left of the grace note’s tucked position that can only be closed manually, and everything will be undone if the user has to reset the note spacing for any reason, e.g. by changing the time signature at that location. ↩
- Admittedly, you cannot insert a key change in the middle of a run of grace notes in the middle of a bar in our application, but we have not yet found such an example in real music; it is, in any case, very rare to change key in the middle of a bar, let alone happening to have grace notes at exactly the same spot. You can, however, insert a change of key at a barline and have grace notes both before and after that barline, and they will show the correct accidentals as required. ↩
- In Behind Bars, Elaine Gould includes slurs in her definition of articulation, which is definitely a reasonable thing to do, since slurs certainly fit Gerou and Lusk’s definition. However, slurs are also used as phrase-markings, which denote how a longer span of music than a single note or chord should be played, and as such we felt they are sufficiently distinct to be considered separately to note- or chord-bound articulations. ↩
- Tenuto is sometimes considered to be an articulation of force, rather than articulation of duration, but we decided to come down on the side of duration, because it is possible to mark a note with e.g. tenuto-accent, which would not be possible in our application if tenuto and accent were both considered articulations of force, unless we included a specific combined tenuto-accent articulation, as we have done for tenuto-staccato. ↩
- Ted Ross, Teach yourself the Art and Practice of Music Engraving, 3rd edition, 1987; these days, only available to buy on CD-ROM from NPC Imaging. His section on punctuation begins on page 73. ↩
- I believe that Product D, not represented in the images here, but discussed in a previous diary entry, is also capable of this kind of tucking, provided you have the right third-party utility available to you. ↩
Daniel, I hope when you start work on your audio engine that it is separable from the notation engine. Composers and engravers may not have as great a need for more than a basic playback. This might save on resources in starting up the program (quicker starts)?
@Ralph: There’s no reason why having an integrated audio engine itself should consume more resources. What makes a substantial difference to resource usage is what virtual instruments and effects you choose to use. As yet we haven’t determined what sounds will be included in the (virtual) box with our application, but it should be possible to use anything from the most lightweight single-sound player (e.g. a piano) right up to the top professional sound libraries.
I guess that is my issue. Finale does not load the chosen sounds until play is activated. Sibelius pre loads sounds on startup which affects the speed with loading the notation engine.
I would rather just the notation engine loads to begin work and when or if playback is desired the chosen sounds load at that time.
This is certainly a function I would utilize i.e. a score editor only mode. I can think of many different situations where one would just want to open the score to edit without having all the extras starting up too e.g. if you already have a software running that’s having exclusive use of the sound card (Cubase), or if you have a particular large playback device loaded and you need to do a quick correction of a different score without closing a whole orchestra down. It could be like Firefox’s safe mode or normal, you could have Steinberg’s full and editor mode… Just a thought.
Hi Daniel
As always, your Steinberg blog makes for fascinating and thought-provoking reading for anyone who cares about professional digital music typesetting.
I don’t agree, however, with one comment you made about the nachschlag at the end of trills and glissandi: “These grace notes can still be considered as belonging to the next rhythmic position, but they steal their played duration from the notes they follow, rather than the notes they precede. This distinction is necessary for playback, but not for drawing and spacing the grace notes.” My quibble is with the second part of your second sentence.
If you follow that logic, you will end up with the same nightmare-ish problems one encounters in SIbelius when attempting to notate a nachschlag in front of a barline. Not only will the nachslag be pushed behind the barline by the program, the spacing of all of the other lines in a score will be misaligned after the barline when compared to the line with the “vor-” schlag. When I’ve attempted in Sibelius to drag the gracenotes in a nachschlag to a position in front of a barline, Sibelius “corrects” my changes to the incorrect position after the barline. The notational problem of a nachschlag preceeding a barline is an important one. Hopefully you will address it in Steinberg.
Mark Starr
@Mark: You’ll have to trust me that we have thought about this issue very carefully, and that we will not be consigning users of our program to nightmarish problems in this regard.
When I’ve attempted in Sibelius to drag the gracenotes in a nachschlag to a position in front of a barline, Sibelius “corrects” my changes to the incorrect position after the barline. The notational problem of a nachschlag preceeding a barline is an important one. Hopefully you will address it in Steinberg.
However Mark, I think this is finding a problem where there is not one. I think you refer to an ornamentation between notes, which no matter how tricky should be written out in full, not as grace notes. This removes any problem re the next or previous barline because the intention is clear.I’m sure you have played Bach keyboard music and you’ll see what I mean. Even the fastest sight readers have to stop and work them out before executing their beauty. Hate to do that with grace notes and my eyes!
Nevertheless, I have many times needed to deal with grace notes which composers or arrangers have placed before a bar line. Never mind what they “should” have wanted, this is what they do want. Either I “correct” them and thereby disappoint them (and confirm their feelings about the inflexibility of notation programs), or I break my neck with existing programs trying to do something that the program basically doesn’t want to do. If Daniel et al really have thought about this and done something to make it possible, that is very good news indeed.
Daniel, everything I’ve read about the upcoming notation software is great, but in my personal opinion, you should think about giving the ability to the composers to write notes manually by using, let say, score writing tablet /like those the people are using to paint in Photoshop, or to draw in AutoCAD/ this would save so much time, if you are able to write the notes and everything else by hand /and of course to look printable, not as manuscript/
Greetings and keep working, guys!
Each article of your blog proves your intelligent understanding of the complex problems of musical notation. Thank you for sharing your progress for future software I’m anxious to test it, but as you say, take your time to make us the best of music notation programs. You are on the right path.
Godspeed, gentlemen! I’ll be waiting at the end of the path with my wallet open.
Ditto!
Great stuff. Merry Christmas to you and your family, Daniel, and everyone at team Steinberg!
Daniel, many thanks for this update. Best wishes and Season’s Greetings to you and all the Steinberg Scoring Team. Your dedicated work ethic carries a spirit of excellence that will yield high dividends when the product is released.
Daniel,
From lil’ ol’ Red Deer in far away Canada, I wish you and your family the greatest of holiday seasons. I also extend these wishes to your colleagues who work with you on this exciting project.
Thank you so much for giving us these fascinating updates. Despite my meager knowledge, I was keenly aware of the complexities involved in creating a professional music notation software, but by helping us dig further in this treacherous minefield, you have deepened my appreciation of the labour involved. We are all very patient here, and I certainly have no doubt in the future success of this yet-to-be software. Thank you for sharing this exciting ride with us!
Claude Lapalme
Music Director
Red Deer Symphony
As always, I’m thrilled to see product C do well, and especially this time. While its representation of grace notes is flexible and amenable to good typesetting, I have never been completely satisfied with it. The code that synchronizes the grace notes between voices is a rare piece of programming in that I don’t fully understand it (although I did write it).
Thanks for this update Daniel, it’s very interesting to see this product unfold.
I know it’s early days with the articulation markings but will you be including a way to override the system so that it is possible to have say multiple markings of force or duration if desired, I’m thinking here from a playback perspective and the way some sample libraries respond to multiple key switches or controllers.
For instance in one of the other scoring applications available you can put a marcato mark above a note and this will trigger a corresponding key switch in a sample library and you can also place an accent mark on the same note (which you would probably hide manually) this would then trigger a CC message to bump up the volume or perform a similar function in the sample library or even from within the scoring application itself.
@David: As I indicated in another reply to Mark elsewhere in this thread, we anticipate that the playback effect of each articulation type will be possible to customise independently for each instrument type, including specifying things like MIDI controller values, keyswitches, and the like. We haven’t implemented any of this yet (our application doesn’t play back at all just yet), but it’s all in the plan.
While customisation of playback per insrument is great, it is not enough in my opinion: Will customisation of articulation playback be availble also per score, per selected segment, and per note? (with the option of making a bulk choice for a selection of notes)
I ask this because any good musician knows that while there are some general rules, there is never a “one size fits all” rule in almost any articualtion.
Forget about notes over Xmas Daniel. Try not to dream about them too. A holiday would be great to recharge your very active battery!
I mentioned this several times on the wish list when you were at the helm; that is, to somehow programme articulations be a separate identity rather than a fixed one on a note. Then they can be treated as such in the filtering mode, and I could select them from one stave and copy to similar staves on a score that need them too.
Massive respect and admiration for your continued work on these “difficult” aspects.
I sincerely hope you ALL will have happy and restful time over Christmas with those you care about – and who care about you.
Best Regards
Chris N Miller
Since you stated you are working on slurs and ties presently, I thought I would make a request.:
Both of the leading notation products which you commonly use for your examples lack functionality for a dashed tie. They both include dashed slurs, but in those cases where a dashed tie is indicated, a lot manual adjustment is required, and yet the simple solution is out of our reach.
Forgive me if this seems esoteric, but I’ve been working on vocal music recently…
@Nathanael: It’s not esoteric at all! We already have support for both dashed and dotted ties in our application. To make a tie dashed or dotted, you will right-click the tied note and choose the dashed style from somewhere in the context menu. We will also, of course, have dashed and dotted slurs, too. Indeed, we even have half-dashed ties and slurs (with the left half dashed and the right half solid, or vice versa), which are sometimes used as editorial markings in critical editions.
I’m very impressed that ‘half-dashed’ ties and slurs will be available! I have wanted these when a composer has forgotten the second half of a tie or slur across a system or page break. (Flighty, forgetful creatures, composers 😉
I’m also very impressed with the care and thoroughness with which you are analysing the conventions of music notation and the task of interfacing between human and machine.
All the best to you and the development team for the coming year!
Great !
How about the ability to flatten ties, slurs, and phrases (à la SCORE)? This feature, to my knowledge, is not available in any other scoring applications . . . where the structure of curved elements seem to follow the same basic model using only one Bézier curve. Along with all of these wonderful features you’ve revealed to the world so far, the ability to truly flatten a curved element would elevate your product into further superiority.
Hi Daniel,
frankly speaking, I found your blog very accidentally and must say that your serious approach make me believe, that there will be a nice alternative as a notation software to A and B, ironically to say.
The reason for my hope is based on the expectation to be created an application, that has to meet the needs of all dedicated engravers, who are tired from long-lasting obstinacy of a companies like Makemusic to avoid fixing painful problems of their software – bugs and inadequate slowness, no matter on what powerful machine it runs.
For a time being, I would suggest only one thing: let you enduser to feel free. To be free to stop for i.e. your automatic allotment/music spacing, to move accidentals, to make its own library and to have an easy access.
I am pretty sure I’ve got the picture, that I am Finale and Cubase user (for more than 22 years). And therefore I will not make any comparisons with Sib, because I apply to it with condescension because of its limitation of a controls and lack of embedded graphical editor. For sake of this treat, I would be happy to see in your software possibility to create graphics from scratch.
The richness of Bravura is very positive milestone, however for contemporary scoring the custom drawing of composers are considered mandatory as ability of the software.
I observed the glyphs and admire the effort for having such enormous library with a numbers of quasi soft edges elements too.
(Personally, in my daily work, I use only my own fonts base on hand crafted scores that but only for German customers)
It is matter of aesthetics, nonetheless.
There is no need to mention your perfection and attention to details. However in this respect I would like to spot a few things, you mentioned about spacing in this Part 9. Steinber, A B and so on.
Please, have a look at sharps on notes with ledger lines. Within “Lilypond” sample, supposedly C, this has been addressed the best way. Namely – a little mask has been applied to the first most line so that the collision between accidental and ledger line has been avoided. In my daily work I use third party plugin, but it would be very such option to be set as default.
Second, beaming – it is very delicate subject. I suppose, it would be positive idea to leave options to be decided from. The same applies to the brackets and tuplets. Limited tuplet option as it is in Sib. makes this software impossible to maintain sophisticated scores from one of the most critically acclaimed composers like Brian Ferneyhough, Chaya Czernowin, Heinz Holliger, Philippe Manoury, Lorin Maazel, Aribert Reimann, Bernhardt Gander, Cristóbal Halffter etc.
I would be very pleased if you would accept my kindest request to might contact you via E-mail regarding music fonts.
Thank you for your attention.
Best regards,
Wess
____________
@Manuel,
Hi,
“flatten ties, slurs, and phrases (à la SCORE)? This feature, to my knowledge, is not available in any other scoring applications . . .”
Flatten slurs and dashed slurs are hardly needed for every serious engraver, indeed.
Therefor I developed “simple” technique with IMHO convincing results and posted under nickname “Wess”or “Wess-music” on these links:
http://forum.makemusic.com/default.aspx?f=6&m=371620
http://forum.makemusic.com/default.aspx?f=6&m=141041
http://forum.makemusic.com/default.aspx?f=6&m=323141&g=323309#m323309
http://forum.makemusic.com/default.aspx?f=6&p=2&m=323141
(inc. screen shots and instructions)
…
https://www.youtube.com/watch?v=1ENKvf9hkbE&feature=youtu.be
https://www.youtube.com/watch?v=7QiR9dcI888
http://forum.makemusic.com/default.aspx?f=6&m=350186&g=350194
Actually, Mr. Wess, I’d read previously some of your posts on the MakeMusic Forum, and I truly admire your work. Your approach to flattened slurs is phenomenal! And your reply here is an honor. But wouldn’t it be nice if a software package, such as the one being presented here, enabled the user to effortlessly handle such kinds of slurs? In SCORE, this is achieved by simply changing one parameter (per single object, or globally).
The Steinberg team seems to be tackling a great number of possible problems, particularly typographical ones, and providing brilliant solutions. Their goal is excitingly ambitious. Mr. Spreadbury: I would simply love to see this as a feature (or at least, as an option) in this great product. Here’s an example of what Thomas Broadhead, another master of music engraving, has achieved in SCORE to draw beautiful flattened slurs.
http://home.comcast.net/~tom.brodhead/Ives–SymphonyNo4–CriticalEdition–SamplePages–ThomasBrodhead.pdf
See pg. 37, m. 87, percussion; pg. 71, m. 189, woodwinds; pg. 108, m. 24, bassoons.
Not only do they serve to economize vertical spacing in complex scores, but to also direct the reader in a pleasing horizontal flow, avoiding the distraction of what overly round slurs or ties might cause.
…and flattened slurs implemented! Thank you Team Dorico!!
I hope that tenuto will be able to be defined as an articulation of force at least for playback purposes.
Although, I think marcato – an articulation of force – shares its sign with tenuto?
@Mark: I must be misunderstanding you, but a marcato is typically indicated by something that looks like an inverted V, while a tenuto is typically indicated by a horizontal line of roughly a notehead’s width.
Yes Daniel, my mistake. I’ve now reset my brain as to what a tenuto sign and marcato sign are, and they are of course two different signs in the way you say.
@Mark: I expect the playback effect of articulations to be customisable independently for each type of instrument, so if you want staccato to make the note longer when played on a violin or louder when played on a tuba, you’ll be able to do that.
That’s great Daniel. Of course my concern with tenutos doesn’t equate to the facility to do idiosyncratic things, since I understand the standard definition of tenuto is twofold, either duration or force. All best wishes for Christmas and the New Year.
Mark is correct in pointing out the two-fold function of the “tenuto” mark: it can mean either full duration or a kind of accent. Or, possibly both. Composers are often confusing, confused, and/or inconsistent about what they mean when they write this dash, though I believe most of them are indicating quality of attack (accent) and weight even more than duration.
Another engaging post, Daniel! Thanks for allowing us to ride along in your pocket during the development of your software to catch a glimpse of what it’s like to be part of such a complex undertaking. It’s a unique point of view that helps me appreciate everything that each one of the products you compare can do. Merry Christmas to all of you! Hope your holidays are joyful and relaxing.
So are we still looking years ahead for a usable product?
@australiancomposer: It’s very difficult to predict how long everything will take to implement. Hopefully you can see from the examples I am posting that we are committed to producing something of only the highest quality, and we are fortunate to have the support of the team at Steinberg HQ in building something truly state-of-the-art.
Daniel,
Always wonderful to hear about the new progress you’re making with this application. As ever, please don’t forget those of us in the blind and visually impaired community Who fervently hope that you will integrate accessibility into this product.
@Kevin: Don’t worry. We remain committed to accessibility support, and I am still working as part of an expert group under the auspices of the UK Association for Accessible Formats (UKAAF), in association with the RNIB, more broadly on issues of providing accessible solutions for blind and visually impaired musicians at every stage of music-making. We have already reported a couple of bugs relating to Voice Over accessibility in the Qt application framework we are using to its developers, and we expect the program to be pretty well fully screen-reader accessible at the time of release.
Each update is more fascinating than the last! I’m as excited as the rest to see the final product, but even if there WAS no final product, the periodic insight into conceptual programming logic and notation insight would still be well worth it. Thanks for that.
One very minor question. On grace notes, I can follow the argument about storing them with the next rhythmic note. But are you confident that they can never stand alone? Admittedly I can’t recall ever seeing, for instance, a grace note as the last note of a score, but that doesn’t seem conceptually impossible. (I can understand what it might mean and imagine a composer wanting to write it.) And I think I probably have seen free-floating grace notes, for instance representing vocal “wobbles” in the middle of a long held note, separated from one another and not directly attached to a terminal note.
Of course, any notation program has to draw the line somewhere and decide that anything beyond that line has to be fudged — but given that your aim seems to be to draw the line as far as possible away from ‘standard’ functionality, I wonder whether you’ve considered the above case?
@Toby: We certainly did consider the issues you raised with grace notes. Grace notes floating apparently freely anywhere in the music shouldn’t pose a problem: the only requirement for a grace note’s existence is the existence of a main rhythmic position with at least a rest in it, and of course that rest could be hidden if desired (though we don’t have that hiding functionality just yet). There’s also no limitation on the number of voices you can use on a given stave, nor where those voices should start and stop, so you should never have any problem creating the opportunity for a grace note to exist at any location, even in the most arbitrarily complex cases you can imagine.
However, a score ending with a grace note is a problem! You will need to employ some kind of fudge in this very unlikely situation, e.g. creating a hidden rest in a new voice at the very end of the bar, and attaching the grace note to that rest.
I wouldn’t dream of telling you how you should design your application, so treat this as a vagrant thought…
Sibelius allows you to attach certain things to the end of the bar. E.g. in a 4/4 bar, you can attach symbols to the fifth beat, even though there isn’t such a beat, unless we regard it as equivalent to the barline. So fermatas and commas, for example, can be positioned in relation to the barline (perhaps with an offset), and they remain stable when so positioned.
Grace notes are not among the objects that can be so positioned in Sibelius. But if they could be attached to the barline in Steinberg’s application, that would solve the problem of having a grace note before the final barline. (Perhaps also the problem of a grace note before the last barline in a system—if that were a problem at present.)
@Kim: I agree that it’s important items should be able to be attached directly to barlines, rather than in the nether regions of either one bar or the next, with the attendant problems caused by changes in system layout.
Thank you, Daniel, and your team, for all your hard work, your passion and your dedication. We are all waiting, patiently (at least trying!) for Steinberg’s new product. Here’s wishing you and your team, as well as your family, a blessed Christmas and a very prosperous 2015. Will be watching this space of course!!!
Hi Daniel
Always a good read, these diary entries. Thanks for keeping at ’em.
I think the approach to articulation is a good one, efficient to manipulate and sensible, but I would like to see a modicum of flexibility: if there were one empty space in each of the two main categories (duration and force) for which users could define sign(s) and playback, I think you would minimise the howls of outrage from the articulation fiends.
all the best and merry christmas to you and the team…
@Jeremy: I’m curious to know what kind of use you envisage custom slots might be used for? Would it be because people disagree over whether tenuto is an articulation of force or duration, or would it be because they want to use different symbols altogether? We will have other semantic types in the application covering the broader swathes of playing techniques that will allow a variety of positioning options (though there would be some limitations, e.g. you would not be able to define one of these that would e.g. appear closer to a notehead than a staccato dot, if both were present on the same note).
Thanks for the update, Daniel. Merry Christmas – hope you get a decent break (especially now you’re not having to answer blog posts at 6.30 on a Sunday morning!)
Hi Daniel,
Great work on the application.
I’m a bit concerned about the limitations you put in there: ‘A given note can only have one of each of these kinds of articulations’. I don’t understand why such a limitation would be serving a good application. Take a look at Behind Bars page 115-117 which has multiple examples for tenuto combined with staccatissimo, both articulations of duration. I did a quick search for an example in a musical score but didn’t find one. But I think there will be one out there as well as other combinations that can’t be done with this limitation.
Another thought on the horizontal positioning of articulations: ‘In multi-voice situations, articulations go to the stem side of the note or chord instead, and are centred on the notehead (unless the only articulation present is a staccato dot, in which case that can be centred on the stem instead).’
Depending on which book you read about music engraving the staccatissimo and tenuto sign needs to be centered on the stem while on stem side alone.
Merry Xmas
Hans
@Hans: You may be right that in addition to staccato-tenuto, we need to have staccatissimo-tenuto as a preset articulation of duration; however, we’ve not yet come across this in any published scores. I’m sure Elaine had her reasons for using it on page 116 of Behind Bars, so one of these days I’ll ask her if she used that combination because it has been used in a specific work.
Regarding horizontal positioning of articulations, I haven’t covered in full detail all of the engraving options we have included for any of the notations we have yet supported in these blog posts, but you can be assured that all reasonably common use cases will be supported by some combination of the options we have included.
Daniel. Thank you for all this, it means a lot to us to be kept in the loop in this way and it is so exciting to have such a brilliant product to look forward to. I was quite happy with Sibelius 6.2, and to be honest, for me I simply want the best notation program, not something with reams of school worksheets and mid-range sounds. It seems to me that Sibelius was much quicker before we had to spend time loading all the sounds.
Essentially, I’d like a pure notation program with some good basic sounds, but which could then be directly loaded into another program if I wanted to take it to another level in terms of playback. In which case, I’d need a really really good soundset program, far above that which Sibelius 7.5 offers.
Hope you have a great Christmas. Dare we hope for a beta version in 2015?
I’m really enjoying the effort and dedication you are giving to this state of the art music notation software. It is very always very interesting to see how simple subjects are receive a huge attention from your team in order to keep it simple for the user. I’m really looking forward for the the further developments and the final product.
Wish you and your team a merry christmas and a 2015 full of good things!
Fascinating Daniel! Some useful tips for my orchestration and composition students here at Edinburgh, as well.
Really great news about ties being a single entity! I’ve wasted so much time fiddling with incorrectly accidentalled ties it’s maddening.
Will it be easy with grace notes to adjust their rhythmic meaning for playback, e.g. How far in front they are of their parent note?
@Will: Although it’s a clever idea, I don’t think the way Product A uses the graphical offset of a grace note from its rhythmic note to determine its playback duration is actually the most useful way to do it. We haven’t decided exactly what we’ll do in this area just yet, but it’s a safe bet that it won’t involve dragging the grace note left or right to change its played duration.
Relief to hear! Always good to be able to draw some distinction between visual layout and playback interpretation. With the all effort you’re putting into intelligent layout, here’s hoping RSI-inducing note-dragging sessions will be consigned to a painful memory.
Merry Christmas to you and your family, Daniel, and everyone at team Steinberg!…from Belgium . Eddy Wery (composer) .
Rhythmic Spacing. Can i put in a plea for consideration of lyrics spacing. I spend most of my time preparing scores for our choir or for myself and while it is always possible to reduce the font size, trying to make it clear for those with visual imparements means a larger font is often more preferable but this then does mean that spacing is not ideal as the software gives priority to note spacing and little to the actual size of the word.
@Fraser: Ideally rhythmic spacing should take priority over lyric spacing: that is to say, if it’s possible to nudge a lyric left or right a little bit in order to avoid distorting the ideal rhythmic space between two adjacent columns, that’s what should be done. Only if the lyric is too wide to fit and would require nudging too far away from its note should the rhythmic spacing be widened. We haven’t done any work on lyrics yet, but we have plenty of ideas about how to get this working satisfactorily with minimal input from the user.
Hi Daniel, on the subject of lyrics… in an ideal world, the application would know how to hyphenate properly. When I’m entering lyrics in Finale, I must from time to time look up a word to hyphenate it correctly – sometimes I have to then make a judgement call on whether to hyphenate based on the dictionary’s syllabalization, or something that looks more like what I’d like to see as a singer. How often I’ve wished the program would just hyphenate as I go along, allowing me to adjust for melismas as necessary.
Of course, that would mean having downloadable dictionaries in as many languages as there are users… sigh… which is almost certainly unacceptable bloat. But I can dream!
@Michael: There are of course two big problems with your idea. Firstly, the music would have to be very unambiguously marked up in advance so that it’s clear where any melismas should occur, and secondly, the lyrics themselves would have to be very unambiguous too, so that any words that could conceivably be set using a variable number of syllables are all sorted out in advance.
Thanks Daniel, keeping it seasonal, i have set out silent night with three bars per stave in a well known product and while the bars are well spaced, the lyrics could do with a bit more white space which wouldn’t detract from the rhythm, i accept i could reduce the font size but that spaces the notes even more. As with all things, it is a compromise but any additional help to minimise manual tweaking would help as some words in lyrics can still be quite long, especially if its a single sylable.
Going really deep into details… and still with you after the nerdy stuff 🙂
Merry Christmas to you all the hard-working team!
Hello Daniel,
As usual I enjoy your detailed discussion in Development Diary 9.
Two comments.
The articulation box should indicate by different colors which articulation can be added, versus which will act as a substitution.
While I understand reason to consider tied notes as a single event, there should be a way to “un-tie” notes so they can be handled individually if so chosen.
Best wishes for the holidays
Ian
Vero Beach, Florida, USA
Thanks for another fascinating read, Daniel!
One area that I have always struggled with in notation programs is percussion. For example, I have never seen an application with a playback engine capable of properly performing snare drum rolls, diddles, etc. Is this something on your team’s radar?
@Scott: It’s certainly on our radar, but I can’t predict when we might have this done.
Will the scoring engine be integrated in a future version of Cubase Pro? It would be a shame if it would be stuck with a lower quality score editor while Steinberg developed better code.
@Dominique: In the long term we hope to be able to bring some of our new technology into Steinberg’s other products, but for the foreseeable future our focus is on delivering a stand-alone application.
Thanks for answering. I kind of expected this to be the case. In that case, I hope the application is at least easy to use alongside Cubase.
It looks you are making significant progress. I sincerely hope that users who specialise in Jazz and other non classical music will have their needs supported to the same extent and I would be keen to know to whom you have consulted in regard to this genre.
Half- and sostenuto pedal. Will either (or both) be supported?
@Richard: As notations you can create in the score, absolutely. We already have the necessary glyphs in Bravura, our music font. Exactly what effect they will have on playback remains to be seen, but in principle there’s no reason why they shouldn’t be made to play back if you have a virtual instrument capable of producing those effects.
Thanks to the team for all the thoughtful complex work demonstated here. Looking forward.
Thrilled with your progress!
One thing: I hope that there’s no plan to implement a Sibelius-style “Ribbon” menu in your new product, or at least if there is, that is savors much differently then the one in Sibelius. I’ve never been happy with the usability or appearance of that ribbon interface.
Thanks!
Randy Steffens
@Randy: Read my lips: “No more ribbons.”
Ah yeah! “And I did- not- have- sex with that woman!!”
Hallelujah!
Daniel,
Tied notes editing together is exactly what it should do. Good to see smart thinking here.
Sibelius had a sort of ‘idea-saver’ to save score snippets for use later.
Digital Performer has a ‘cue selector’ which hides all events not relevant to your cue. This way none of your edits affect other cues.
These two things are brilliant for the creative process and scoring to picture. I just want to know if these (or alternatives) have been on your radar. If not, here they are… remember them… think of them… these are the droids you are looking for.
Remember me when you think of words like ‘beta’ and ‘testing’. I’d be happy to provide documentation, replication steps, screenshots, and thorough testing. I have experience with black-box testing and would happily test various features on my AMD & Intel machines, with Vienna Ensemble, without it, and a mobile app if there will be one.
Again, brilliant work. Keep it up! Steinberg rocks. You guys rock! The hard work will be worth it in the end.
-Sean
@Sean: Over time I am sure we will add lots of interesting workflow features like the ones you describe, though we won’t be able to add all of them in our first version. Our focus is presently on coming up with a solid set of fundamental workflows that will enable you to get the job done quickly and easily, and we’ll be able to build on those in future versions.
I read your development diary with great interest, especially today on grace notes and spacing. I understand that this is just a shortcut to problems that you see. However, I would like to remind of two things.
In music before the 19th C. a grace note was in most cases associated rhythmically with the note at which it’s written and in performance was “stealing” its value from it. As an extreme example lets take a dotted crotchet note and a quaver where the grace note standing in front of the crotchet note could take even the entire value of the crotchet note, resolving on the dot. Most often, however, in common time, the grace note would take half the value of the note at which it’s writen. Of course these things, as all pre-romantic ornamentation, are much more complicated, I’d just remind that the issue of grace notes (apogiaturas) and their implementation is extremaly veried depending on the era and style, even an instrument. I don’t expact your software will realize all the theories concerning historical music prformance practice, nevertheless it’s worth to keep it in mind.
As for spacing, writing a lot of polyphonic music, often trying to place it all on one staff (like say in classical guitar/ lute music or one of the piano/ harpsichord hands) I’m increasingly inclined to proportional spacing. In my view, it makes it easier to read and understand the rhythmic proportions, but perhaps with less balanced visual appearance. Then I think the spacing engine should be fully under the control of the editor, rather than as a default and „the best” offering. I understand the thing gets complicated with texted music, then a kind of compromise is understandable.
In most other cases, however, your depth of understanding and a desire to find a solution is impressive. I sincerely congratulate you and I look forward to version 1.0.
Kindest regards,
Jerzy
@Jerzy: Of course we plan to make the distinction between appoggiaturas and acciaccaturas in our application. Regarding proportional spacing, we intend to provide an appropriate amount of control to the end user regarding the default values for each rhythmic value, which would allow you to define strictly proportional values for spacing. However, I would personally not go so far as to recommend proportional spacing of this kind!
Hi Daniel & Co.
As everyone in this thread has already mentioned, it sounds like you’re doing some great work on the new application – I’m looking forward to seeing it just like everyone else!
Just one question, have the marketing folks at Steinberg given any consideration as to the possible selling price yet? Lots of us are waiting with a view to buying it -but how deep must our pockets be?
Nigel Gray
@Nigel: We haven’t set pricing yet, but you should expect the price to be set appropriately for a product that aims to redefine professional scoring software. I expect we will have special pricing for people in education (as Steinberg does for all its software products) and I also expect there will be crossgrade pricing of some description, for people who use certain other scoring programs.
Very interesting post about grace notes, thank you. I’ve recently been having problems with S******s where there is a grace note in voice one, up-stem and also in voice 2 down-stem – it doesn’t work, and the lower voice shifts to the right – will this concept be addressed? It’s not an easy one to fudge.
Happy Christmas to all at Steinberg – and here’s to the future.
@Jenny: Yes, the spacing of grace notes in opposing voices works beautifully in our application. No fudging or editing required!
Hi Daniel; am just reading this stuff- hope you guys are going to do some things for Jazz folks- like chord symbol realization in various styles to go along with either a lead sheet and a larger arrangement.
What an interesting lot of comments from this latest,interesting and welcome post from Daniel.
To all here have a very Peaceful and Happy Christmas and look forward to the next “instalment” from Daniel.
Graham
Useless, time-wasting question : why Silent Night in Norwegian on the blog-photo … just askin’ …
I will say this again, since I have already left a similar comment on Steinberg’s web-site, that in development of your new product, please do not discount the role of music theorists in the development of your new software-to-be product. Specifically, I am speaking about the need for some sort of software which will adequately address the issues of making Schenkerian diagrams realizable with ease of effort.
Your main retail base will most likely be composers. However, there is the “de”-composer, namely those who figure out how a piece works, crowd who call themselves music theorists. The notational software which is currently available do not address the issue of Schenkerian notation adequately. i.e., there is no market base for these companies to produce Schenkerian notation software. However, “we” are out there, and Schenkerian notation can be used for educational purposes along with helping professional music theorists make appropriate graphs for both publication and presentation. I, for one, would certainly like to see the development of a software package for Schenkerian notation become realizable one day. Indeed, the market is wide open for its development and implementation. Will Steinberg meet the need? We ARE OUT THERE, waiting . . .
I visited the Adobe conference in Los Angeles this past October. They have shown an interest in the development of this software, albeit perhaps remote from their immediate market place. Can Steinberg fill the need where perhaps Adobe may not be able to do so? Finale shows disparate interest, also, but perhaps they will come aboard some day, regardless of perceived market share.
C’mon, Steinberg! Can you make us music theorists happy by giving us a Schenkerian notation program somewhat akin to what you are trying to accomplish with your music notation program? Check out some Schenkerian diagrams on the web. Can a software program be designed to make ease of production of these diagrams feasible?
Steinberg, we are waiting! Go for it in 2015!
Bradley, in response to your question “Can a software program be designed to make ease of production of these diagrams feasible?” –
GNU LilyPond has been able to produce high quality Schenkerian diagrams for at least 10 years. And best of all, it’s Free Software! Here is an article explaining how to do it: http://www.linuxjournal.com/article/8364
Hope that helps!
I can only echo what other people have said about these posts – I find them so interesting and I really look forward to new diary entries.
I know it’s early days but not much has been said about guitar notation – and for me that does include tablature and not just things like circular string markers in classical and jazz scores (although I want them too of course!). I would strongly hope that there will be support for tab with stems – an area I am very busy in.
It’s probably true that the fretted instrument components in Finale and Sibelius were not at the forefront of the developers minds when they created their programs, (though I do understand that most users are not working in this field), but nevertheless I am anxious to see my needs met in the new application.
Have you given any thought yet about how your app will improve upon the guitar-based elements of Finale and Sibelius?
Regarding an estimation of when Steinberg’s app will be released: “good things come to those who wait”!
To Daniel and all the team have a great Christmas and happy, successful, New Year.
@Paul: Over time we absolutely intend to cover the special notations used in guitar music and that for other fretted instruments, though it’s possible that not everything will be included in the very first version. We have a lot of ground to cover and there are certainly special requirements for guitar music that are not found in other kinds of music. As you say, though, good things come to those who wait, and we have every intention of supporting these notations to a high standard.
Great that you’re all thinking of it.
Please have a look at Guitar Pro, both versions 5 and 6. It is severely limited in terms of traditional scoring, but it’s wonderful for writing out guitar music. Drum editing in version 5 was also very handy, it was unconventional, but extremely quick once you got to know it. I’m hoping you can come up with a creative idea to quickly input drum notation in your software. I always found Sibelius to be a pain when inputting drums, although perhaps it just takes getting used to.
Differences between performance and notation of performance.
My view is that Cubase handles this much better than Sibelius
Sometimes one wants a legible score only
Sometimes one wants a mock up MIDI performance of a score which simply reflects the score (but sounds neutered)
Sometimes one wants a score and a realistic performance.
There are frequent differences between what a performer plays and what is written.
Two examples:
when notating for a classical guitar often notes resonate and sustain for much longer than is notated, this depends on factors such as if the string is open, whether the string is a bass string or a treble… These things are frequently instrument specific.
I once transcribed a solo for a sax, the player had come in early on a run of triplets. In order to get an accurate representation I was left with a mess of semiquavers tied over. Moving the whole phrase to be on the beat, cleared the mess but neutered the playback in MIDI.
Display quantise in Cubase often did a great job of this, but sometimes I wanted to get into a specific note and notate it in a way that belied the performance. Sometimes composers will have one score for notation printing and another for mock up – this seems unsatisfactory.
I do hope that we can retain the display quantise feature and let it be possible to see both the ‘ideal notation’ and the actual and have it fully editable in both.
Thank you for your work Daniel – looking forward to Cubase Score II
This issue of grace notes is EXACTLY related to the issues described in my above post – notes that do not function as part of the written time, the problem is wider than simply satisfying the grace note requirement, its about performance versus legibility
I’m curious about how this will integrate with Cubase! Excited!
Very interesting… Thanks.
Daniel talked a lot about articulations this time. From a musical point of view (not only regarding music notation): Are there any differences in term between dynamic/tonic/agogic “accents” and “articulation”?
“Ornaments” concern mostly pitch and rhythm. But in the end, it’s also kind of an articulation mark, right!?
And how do we differ, if musical expression is applied locally, regionally or globally to the opus?
*** In my (unproved) opinion, interpretation is global, phrasing is regional, and accents are local, the term “articulations” is for me just an engraving term, sticking all kind of musical expression together… ***
I’m just asking that stuff, because to my opinion, a proper GUI should be based on clear musical rubrics, with as little overlap as possible. Unfortunatly, (at least my experience is that) they mostly do overlap.
So I’m curious to read further blog posts, talking about the interface design… 🙂
merry christmas!
Merry Christmas to everyone.!! Great work !
Just a question:
Is it going to be ALL menus? No “icon select” oriented?
Could it be a combination of both?
Just a thought.
@Bashkii: The user interface will use a pretty familiar mix of menus and buttons, but there is a focus on making optimal use of the keyboard, because that’s the most efficient method. If you prefer to use the mouse, though, you will of course be able to.
Grace notes are a real problem in the well-known notation program I use … The grace notes at the end of trills is the big issue – getting them before the barline, even across system breaks is one probglem but also getting slurs attached correctly and attaching dynamics – all possible but extremely tricky and nearly always destroyed by a simple re-space! If Steinberg can solve this reliably then this is really good news, but I must admit I feel that these grace notes belong to the trill not to the following note and rhythmically finish the previous note – and even if this means 2 classes of grace notes (attached backwards, and attached forwards) – surely it would solve so many of the problems at a stroke!
Curious why you are referring to products A-E rather than their actual names? I guess there might be legal reasons for avoiding direct mentions of your commercial competitors, and maybe an element of professional courtesy too, to avoid the risk of being misconstrued as making unconstructive or biased criticism (although AFAICS you have succeeded in staying objective and sticking to the facts). But I see no good reason to avoid explicitly referring to LilyPond and MuseScore. The Free Software world thrives on constructive criticism, and it hardly requires detective skills to figure out which is which, especially given some of the comments on recent posts.
It could be wonderful if this pending-develop product will support roman numerals used by those harmony textbooks written by Tokyo University of Arts. (You could ask YAMAHA for assistance on showing you the example of that kind of Roman Numeral)
Dear Daniel, s
sorry it is not about grace notes, but just opinion in general about some features I am thinking about already a long time. I am SIbelius user since 4th version and I would like to mention some most important things for me as a conductor, composer and arranger, as you are working on this great brand new software:
1. I am not able to write tuplets over one bar. It is possible to do it inside of one bar, but it is not, when this figure takes more them one bar. Already writing down an quite old composition of 20th century for example Charles Ives…It is unfortunately impossible without fake lines..
2. I would love to have a possibility to write lets say 3/4 and 4/4 in different voices, where 3/4 and 4/4 bar takes exactly the same time, and other option – where barlines come not together in separate voices – where for example 4 bars of 3/4 take the same time as 3 bars of 4/4. Would be so great if it would available as a native option – without hiding and drawing, making fake lines and so..Just simple example – Dvorak Melody – 4/4 and 6/8 together. I know, it is possible to write in 4/4 tuplets, to hide them, to fake 4/4..but why not just to be able to write it like it is? computers are able to count very complex things..why not in music?
3. writing cadenzas without counting exact amount of notes..it is so inconvenient to count them and to make something like fake 234/4, hide, fake it..
I wich you all the best and appreciate very much your work
Mindaugas
Of course I know this isn’t the place for advertising. But there are occasions where I think exceptions are justified.
For your questions 1. and 2. I suggest you have a look at http://lilypondblog.org/2014/05/independent-meters/ and http://lilypondblog.org/2014/06/polymetrics-in-sibelius-vs-lilypond/
And while we’re at it, for 3. you might have a look at http://lilypond.org/doc/v2.18/Documentation/notation/displaying-rhythms.html#unmetered-music
(I’m sorry, Daniel, just had to write this …)
Daniel, you have a phrase:
“all the other applications effectively draw a horizontal line extending the height of the stave”
I wonder if you mean “vertical” rather than “horizontal”?
@Robin: You are, of course, correct. Thanks for spotting this: I’ve corrected it now.
Daniel, thank you so much for keeping us posted. I can’t wait for this product to come out.
It might be too early, but I have a few things that I would love to see.
1. Lines that can have pivots added to them in order to manipulate their angles and positions more flexibly.
For instance, let’s say I want to illustrate (like you would find in many contemporary pieces) how the vibrato should be played by drawing a wavy line where you can control the depth and space between each steep and hill, indicating a narrow rapid vibrato, gradually becoming very slow and wide. like so: http://www.derek-hasted.co.uk/faqs/vibrato/vibrato.gif or like so: http://forum.makemusic.com/attach.aspx/13482/Vibrato%20Graphic.jpg
2. It would be wonderful is graphics could be drawn for bow pressure and things like that. (see image: http://forum.makemusic.com/attach.aspx/17932/Bow%20Pressure%20example.png)
As a contemporary composer in many cases I have to resort to writing by hand on paper. I would love to have software that allows more support for extended techniques.
3. This one is more basic. Implementing an ability to name a “Group name” and “Staff name” separately. like so: http://www.rpmseattle.com/of_note/wp-content/uploads/2012/12/inst-name-split-staves-centered.png
4. Having the ability to easily re-bracket or re-brace a staff if they are separated into multiple staves (divisi) mid-page.
5. Having the ability to have flexible staff size independent in every page. In Sibelius for instance, you have 1 size that will effect the entire score, and If I have one page where I want everything to be a little smaller (because not all the staves fit), I have to apply this new size to the whole score or work with multiple files.
Thanks again for keeping this blog, and sorry for the cluttered ransom note.
All the best,
Michael
@Michael: Thank you for your “ransom note”! We have plans to cover all of the issues you have raised, though of course I can’t promise that every one of them will be addressed in our first released version. However, these are exactly the kinds of details that can be awkward to handle in other scoring programs that we are working hard to make easy to handle in our new application.
Thanks again!
Hello Daniel,
Great to read of your progress!
Some points, as a violinist who writes music for bowed stringed instruments:
When placing articulations, I ask: What is most essential to the notation, and in what descending order of importance are the others I intend to use? I then stack them up in order, from most essential to least essential.
First and foremost: Please understand that a harmonic o is not an ‘articulation’. It defines pitch, and therefore is part of the notehead. It does not ‘modify’ the sound; it IS the sound. Therefore, it must be placed closest to the note; head or stem.
When a harmonic o is considered an articulation (such as in Sib), the simple and essential o becomes mired in a maze of placement attachments and rules that must be tediously overcome to place the o where it can be read and understood. It must be rearranged (with trouble) to appear near the note. Even when it has been finally placed correctly, its vertical position is attached to articulation symbols, so it cannot be separated from those symbols or stay in place when those symbols are moved vertically. Much wasted frustrating up-and-down trial and error time results to get legible placement of articulations above a harmonic o.
A harmonic o should be an entirely separate entity that automatically goes nearest the notehead or stem.
For my string notation, duration and ‘force’ symbols are more essential than a slur (bowing) line. Bowings are least essential because players, teachers, and concertmasters change slurs to their whims. Therefore, I place slurs outside articulations, not next to the noteheads as it seems necessary to you in your post above. I usually place downbow and upbow symbols (again: bowings, which are least essential to the music) outside slur lines, especially when the line starts and if there is no space inside the middle of the slur line.
I hope it will be possible to set up custom ranking for signs and symbols associated with notes and staves, so they are automatically placed as each user deems most useful, so we needn’t wrestle with predetermined rules and constant time-consuming readjustment troubles.
All articulations will be necessary on Any notes under slurs, not just the first and last notes. Example: For strings, ‘portato’ is notated with a tenuto line next to a notehead under a slur. When portato is used, the notes under the slur can all the same pitch, but not always. The tenuto line may be on any one or more of the notes under the slur. I have today notated 3 noteheads under a slur: the initial note (no articulation), a second note with tenuto line (portato) which for duration is tied to a third note (no articulation).
I suggest 2 thicknesses for articulation lines: the usual thin line for tenuto (duration); a thicker line for ‘force’ indication. The thinner tenuto line may be a bit longer, and the thicker emphasis line at bit shorter.
Organs:
Pedalboard fundamental pitch must be 16′. If an organ has only one pedal rank, that rank sounds one octave below written pitch. As a Contrebass, Organ Pedal is a transposing ‘instrument’ that sounds one octave below where it is notated.
I hope that in this program, as many organ voices (stops) as are necessary can be specified for each staff, and all played back correctly. Organs are created to be synthesizers — putting together various sounds — and they should be allowed to serve this function in playback. If not, organ music cannot be heard with the program.
Because you allow numerous voices per staff, each voice could be a separate instrument (Flute 8′ + Octave 4′ + Sesquialtera; or “all the stops”), even tho all are notated and play in unison (at different pitch levels per their definitions). Thus the intended organ ‘synthesizer’ effect would be heard.
This organ multi-voice playback function would also be useful for playback when strings divide on one staff (same or different notes) to play different simultaneous articulations such as arco and pizz. Currently, to hear these, I must create a separate Audio Score with additional staves that are empty except for a few measures of arco+pizz playing.
Multi-voice playback would be useful to many people in diverse applications.
Other:
“This cannot be copied because it intersects a tuplet” will hopefully not be part of your program.
It would be very useful if rests could be repeated like everything else with one keystroke (such as: R).
Also very useful would be Reverse Repeat (such as: Shift+R), so the highlighted note or area would be placed directly before itself. Rests, alone or with notes, should be allowed to reverse repeat.
Most Important!!
As I have previously mentioned about Sib: I hope that in your new program, whatever automatic note-input protocols or modes are supplied and intended to be used, these can be easily, entirely, and permanently disabled. Then I can just type B or something, and not afterward have to undo a protocol that expects me to create another note of the same type and duration or whatever. I don’t want to spend awhile for each note deciding what duration, accidental, articulation, etc I must have, and how to type all these, before I create a note, and then back arrow to redo it because I forgot something or changed my mind. I don’t always want to create another note, and if I do, it’s not always going to be in the spot right after my previous note. Let Me decide when I’m ready to go to the next thing, and where, without the program prepping for anything. Let it be this way Every time. All the time. All this back arrow and esc. key stuff is hell.
Note-input protocols make incorrect assumptions about the way I think and the way I work. Designers do not know everything, tho they try to be helpful. Why should we be forced to suffer such big brothering? The protocols are very frustrating, and slow me down to a crawl and often a standstill. Their rules cause much stress and unnecessary trouble. I type and nothing happens, or the wrong thing happens. So I must search the screen and discover if the program expects another note of what type, etc, and worry about my next keystroke, and decide if I must now type a back arrow or esc to continue. Huge hassle, and this is only a small part of the trouble it causes. Sib 7 is a bit better than 6, but I could notate Much faster and calmer if I were allowed to be free of the dmnd note input modes and protocols.
Even if you deem them the best, or I choose to occasionally use them, allow us to completely and permanently disable the well-meaning modes and protocols if and when we so choose. Without fear of them surreptitiously jumping back in if we type ‘the wrong thing’. This is not too much to ask. I am not the only person who thinks or feels this way.
I would like to be interested in your notation program. Just let me create notes my way, forever without the program’s interference. Or I, for one, cannot be interested in the program, because it will not be an improvement from what I currently use.
Thank you, and best wishes.
I have subscribed.
Ned Phoenix
Hey there Daniel,
Coming from a choral and vocal music background I would very much wish for a convenient and flexible automatic handling of lyric spacing and positioning. The notation software I am working with now is terribly awkward in this perspective. Getting the different form parts and font styles to look great and go together with the general layout is extremely time consuming and a lot has to be done manually. Thank you for thinking of us vocal arrangers and choral composers!
Is there going to be a way to copy notes from the Cubase key editor, into the steinberg notation software? This would be a GREAT GREAT GREAT feature, because, us film composers, when we need to orchestrate a piece that we have done in Cubase, it is time consuming. I usually look at the key editor, and type notes into Sibelius. But my hope is that you guys come up with a way to select notes on the Cubase key editor, and paste then onto a stave in the Steinberg notation Software. Daniel, do you see this as a possibility? Please, everyone else weight in as I would love to know everyone’s opinion on this. Any other ideas on how the Cubase could be integrated?
@John: Over time we hope to build up powerful interchange features with Cubase. It would certainly be great to be able to copy and paste data from a project in our application directly into Cubase, and vice versa. There may be some big technical challenges to overcome in making this possible, however, so I can’t promise that it will be implemented in any specific version of either product (both of which would need special coding done in order to make this possible).
Hi Daniel,our
whilst I’m waiting for your application to be ready I’m still having to use Sibelius 7.1.
Could I put i a feature request? That is to be able to have a ‘read-only’ option for staves/ systems/ bars/ notes?
I would have this very helpful in the teaching context I operate in.
Many thanks, I’m really looking forward to having a play once you’re done!
Good luck keep up the good work!
Ian
@Ian: We hope to have some locking features of this kind in our application. I can’t promise they will be in the very first version, but down the line I’m sure we will add them.
Hi Daniel,
I’ve recently had some frustrations with page turns when formatting parts for a recent piece, and a possible feature occurred to me. It would be nice if we could specify how many pages “up” on the music stand we wanted (i.e., visible at any one time), as a default. I’ve noticed that the default behaviour in Sibelius seems to be to assume that page 1 will be a single, right-hand page, and the rest will be open 2 pages at a time. But honestly, in my experience as a contemporary music composer, primarily of chamber music, this is almost never the case. Often times players will have 3 pages up, and in some cases even 4 pages over 2 music stands. It would be nice if we could set a default that the auto-formatting algorithm could strive for when it updates the layout. So, for example, I could tell the program that I want 3 pages open, and it could consider this when laying out pages.
Just a thought.
Check out “An Interview with Daniel Spreadbury” on the current Sibelius Blog. You rock, Daniel. http://www.sibeliusblog.com/
– OT, regarding Daniel’s interview at Sibelius Blog –
I wish to THANK YOU, Daniel, for these words:
“So we have a huge responsibility in terms of upholding a craft that is centuries old […] if those of us who are in a position to make sure that we uphold those traditions — and see the value in those traditions — can do something about ensuring that they are preserved, then we absolutely should.”
Thank you
Francesco (still proud owner of Sibelius 6.2)
Speaking of grace notes, will you handle this Lilypond bug correctly? https://code.google.com/p/lilypond/issues/detail?id=34 I’ve even seen this behavior in music that wasn’t set in Lilypond, so I know it’s not trivial.
@Garrett: I’ve done my best to read through that discussion, but unfortunately none of the little snippets of LilyPond input syntax that are shown there compile without errors in the version I have (2.18), so I’m unable to really see exactly what is going on, but it seems as if the problems in LilyPond may be a consequence of the fact that the music for each voice/stave is input and parsed separately, and keeping track of where the grace notes should go is therefore non-trivial. I believe that the design we have settled on for grace notes is sufficient to avoid these kinds of synchronisation problems. Certainly the presence of grace notes in one voice doesn’t cause any problems with time signatures etc. on other staves getting moved to the wrong place.
First of all, I think it’s really cool that you’re running this blog and allowing people to provide input on this program! As long as people are giving feature requests, here’s mine:
The one thing that’s kept me on Finale rather than Sibelius is its Speedy Entry mode. When connected to a MIDI keyboard, this mode lets the user hold down a note or chord on the MIDI keyboard, and then type a key on the computer keyboard corresponding to the duration (whole note, half note, quarter note, etc.). Sibelius, on the other hand, stays in a “mode” which specifies the duration of the note, and then every note played on the MIDI keyboard immediately enters a note of the current duration on the score. The reason I prefer Finale’s Speedy Entry is because it allows you to noodle around on the keyboard, experimenting with different chords until you find the one you want, without actually entering anything on the score until you tell it to. It would be great if your new notation program could offer this feature as an option, because other than this one feature, Finale has a lot of things that could be improved on, and I wouldn’t mind trying out an alternative if it proved to be substantially better, as it looks like this program may prove to be in a lot of ways.
This “Finale-like” note entry functionality is available in Sibelius 7 under the preferences menu.
Regarding note entry, Daniel has said this in a comment in the past: “I think it’s important up-front to know that our new application won’t work like either Sibelius or Finale, and folks who are using either of those applications (or indeed any other scoring application) had better expect a certain amount of retraining if they want to use our new application. We have the freedom to come up with a new, and hopefully better, way of handling note input and indeed practically every other aspect of a scoring application, and in my view we should have the courage of our convictions and follow that through to its fullest extent — which means no compatibility options to make our new application work like another old application.”
Point of clarification: Daniel and his team implemented this equivalent feature back in Sibelius 7 inside the Note Input Preferences.
This is actually one of the most interesting blog posts on music notation I’ve ever read, thank you!
When we write a crescendo under the bar and press the play button ; will play the player automaticly the crescendo(without plug-in)?
we are using for that a plug-in in sibelius.
“We’ll be able to expose editing operations that don’t inflict a penalty if you want to insert another note, or to change one kind of tuplet into another kind of tuplet, or even to insert a barline wherever you like. We want to remove these kinds of limitations that exist in current notation software.”
YES!!!!
Great post, as always, Daniel. It’s an odd corner case, but when you’re talking about tie chains and manipulating their pitches as a group, will your program have consideration of “enharmonic ties” — I’ve posted about this somewhere, but I first encountered them in a Clara Schumann Piano trio and have seen them a number of times since. Where, due to changing harmonies/keys/etc. (in other parts), a D# can be tied to an Eb. Musically, there’s no contradiction to tying the two notes, but from an engraving perspective, it can be a nightmare unless the code can quickly switch to slur code in this case. Other more common issues are tied notes that cross a clef change or 8va mark change. (in these cases, I prefer two broken ties, one leading out of the first note and the second leading in, as if it’s a tie over a system break, rather than using a slur mark). Thanks!
@Myke: Yes, our application can cope with ties that cross changes in enharmonic spelling, or clef changes, or indeed ties that start on one stave and end on another, because the destination note or chord is on a different stave, as occasionally happens in complex piano music.
There is the question of invisibility. I’m thinking of Beethoven’s first movement of the Moonlight Sonata where in my Henle edition the triplets are visibly shown in the first measure only, the player expected to understand that they continue throughout the movement. This invisibility cleans up the score immensely.
I’m wondering about ossia staves, which provide alternatives or suggested elaboration of an ornament.
@Jim: You can easily select a bunch of triplets and specify by way of the Properties panel that their number and/or bracket should not appear.
Dorico does not yet have support for ossia staves, but that will come as soon as possible.