The parts have gone to the printers and I can finally breathe a sigh of relief! As some of you will have seen, I’ve posted about various specific issues over the last few weeks (and thank you to those who helped me get round them!).
A project of this complexity would of course have been much harder to get through in any of the competitor software - that goes without saying nowadays. Before Dorico, I was Sibelius user for about 20 years and, like everyone else, had got used to hacking round its inadequacies (N.B. I’m still going to be using Sibelius for a while, especially for choral music (my main area of expertise) as its handling of lyrics is still superior to Dorico I think.). So many of its frustrating limitations are effortless to achieve in Dorico, but my goals in this post are to highlight the things I still need to hack around, draw the team’s attention to a couple of bugs I noticed along the way, and reflect on the things I might have done differently had I known the software more intimately at the beginning.
Most have already been discussed here and are expected to be present/fixed in future releases of course. It bears repeating again here that Daniel and the team are really to be admired - their patience and responsiveness is exceptional. Special thanks to Andrew who worked out of hours to fix a last minute bug that had me pulling my hair out!
First, a little about the project and the direction from which I’m approaching the software:
This is an arrangement by Ryan Wigglesworth of Wagner’s Gotterdamerung for Soprano and orchestra (essentially the best bits of the opera stitched together), published by Schott. This is my first project of this scale for any major publisher, and I think the first of this size that Schott have commissioned knowing the work would be done in Dorico (if I’m wrong, I imagine someone on this forum will be able to correct me!). Screenshots below are uploaded with their permission!
I had been following Dorico’s progress for a while before it was released and had completed a few small projects in it already, mostly just for fun and to test the various features with a view to eventually moving over from Sibelius permanently for my aforementioned choral editions. When Dorico’s condensing feature was announced, the demonstration videos blew my mind and I was keen to find a project to put it through its paces.
I know Ryan very well anyway and work with him closely on many other things, so it was a good opportunity to test Dorico in a professional environment without fear of having a nervous breakdown if things went wrong. We’ve been working on this project in our spare time for about a year, and full time for the last week to get everything done in time for some October performances (though not sure how they’re going to manage an orchestra of this size while social distancing!).
Ryan was keen to keep as much of Wagner’s original notation intact, so I was working from his red-penned 2003 Eulenberg urtext edition, checking against the original Schott plates where necessary (which are on IMSLP), and of course referring to my trusty copy of Behind Bars. I was provided with MusicXMLs (of the whole opera) from the working files for the 2012 edition which were typeset in Finale.
The first task was to import everything, make the cuts and insert the stitching music. I immediately had problems with Dorico (at that point v2) crashing or hanging, simply because of the size of the files I was trying to open. After a few attempts, I requested the original Finale files instead and, using a free trial of Finale, cut some big sections and exported separate MusicXMLs for each stave.
The finale files were immaculate, but naturally the transfer via MusicXML left me with a lot of tidying up to do. Take this passage for example (from the 2012 edition):
The lack of condensing in Finale means that the file actually contained 7 staves for the oboes, 1 each for ob1, ob2, ob3, ob1&2, ob2&3, ob 1&3, and ob1-3: I pity the person who had to work out which stave to use, page by page, especially if there was a change of plan at any point! I’m not sure how Finale deals with concurrent simple and compound time signatures (see b1370) but the XML spat out the every note as its full value (i.e. quaver in 4/4 = quaver in 12/8) meaning the parts ended up different lengths, and the independent key signatures were not output in the xml.
I set up keyboard shortcuts for selecting top and bottom notes of chords in order to cut and paste each of the 3 oboes into their own part (not forgetting dynamics and tuplets where appropriate). For the simple/compound bit I switched on insert mode when creating tuplets to get the 12/8 bars in the right place before adding independent time signatures with a custom 8 quaver upbeat bar followed by a hidden return to 4/4. These are pretty easy things to rectify in Dorico, but it became a bit more complicated when the barlines didn’t join up:
I originally did this as 3 bars of literal 2/4 against 1 of literal 3/2, but when I realised that bar numbers weren’t going to line up I eventually decided to do this section with aggregate time signatures (hidden, with 2/4 and 6/8 text objects as appropriate). I’m not aware of an option to have solid rather than dashed barlines in aggregate time signatures, but Ryan was happy with the compromise.
Dynamics were a particular pain: gradual dynamics other than hairpins did not import and before I had a real handle on how the linking and grouping worked, I made a mess of re-inserting them. This came back to bite me when working on the condensed score as dashed lines often wouldn’t condense where I had them finishing in different places, even when they looked right in write mode owing to another dynamic marking butting up to them. There are still a few instances where, even though I think I have lined them up, the condensing doesn’t seem to work e.g. these 4 trombones:
Not sure what the issue is with these, but by the time I was noticing them, the project had got so large that in the time it took to switch between write and engrave modes I had time to make a cup of tea and walk around the block, so I often resorted to just turning the extra line invisible (i.e. setting colour with alpha channel = 0) in the score.
During this import and checking process, Ryan decided to simplify the brass and wind transpositions, partly to make the score consistent with modern standards and easier for sightreaders to manage, and partly to pacify me in my concerns with the then limitations of Dorico:
- Some instruments didn’t exist in these transpositions (e.g. Horns in Bb) - easy enough to get round by renaming another instrument that did work, but not ideal for faffing with bracketing and playback ranges etc) or didn’t match the octave transposition as per Wagner’s (inconsistent) usage (now fixed by the layout transposition options of course)
- Condensing can only manage the first instrument held by a player, meaning I’d have to have separate players for parts and score, manually keep them consistent with each other, keep track of all the right labelling, and make sure no instrument changes happened between page breaks. In my finished project, I have had to do this with Clarinets (Bb and A) and harps (which can’t condense as they’re grand staff instruments). These are quite straightforward to manage, but I baulked at the idea of having to do this for all transpositions of each of the 8 horns, 4 Wagner tubas and 4 trumpets (which all change basically every phrase in the urtext).
As the project grew, it became slower and slower (unsurprisingly), and in an effort to speed it up a bit, we also made the decision to split it into 5 flows at musically logical places. The idea was I could work on a chunk at a time, get it sent off for proofreading, then turn off that flow and start work on the next. That sort of worked, but in retrospect I wish I hadn’t done this. For one thing, it introduced a bug with bar numbering which I’m still unable to properly diagnose - I added a bar number change at the beginning of each flow so it would seamlessly continue from the previous one and was delighted to see that Dorico’s system bar numbers (i.e. the light blue ones) updated to match. Later in the process though, I noticed that flow 5 was restarting the system bar numbers at 1 - I think because I had introduced an independent time signature at that point to sort out some condensing issues (more on that later). This meant mental arithmetic when checking things in engrave mode against the same bar in write mode!
Most of all the problem with splitting the flows was that it didn’t really solve the speed problem and by the time I had realised that it was irreversible. Of course I would need to check all 5 flows together at some point eventually, but hoped that Dorico’s speed might improve in a new release or update before I got to that point. It didn’t. I figured my machine was the problem so turned off all the playback and bought some extra RAM (up from 8 to 16GB). A very slight improvement, but still frustrating to work with. In engrave mode especially, every time I selected anything, I’d have to wait a few minutes to be able to manipulate it. I managed to persuade Schott to advance some money so I could invest in a super-computer (8 core 10th gen i7, 128GB RAM) - This made a great improvement to the playback and audio exports, and a small improvement to engrave mode, but the problems got worse the more I worked. It wasn’t until the last weekend when things became absolutely unusable and I made a cry for help - within 24 hours Andrew had fixed the bug and Daniel had sent me a patched build. It is a revelation - Dorico now runs faster than it did on day one of the project, even with all VSTs loaded.
Going through every part, editing the transpositions, checking against the various sources and making sure everything was input in the way Dorico ‘wants me to do it’, took the best part of 10 months’ worth of evenings, but boy am I glad I did it. For one thing it was a crash course in using the software, getting used to shortcuts, where to find options, and discovering helpful little features etc. There is so much to love about Dorico, and I haven’t even touched many modules yet. But more importantly, having done the hard work, the score tidying and part extraction was a joy to do.
So now on to feature requests and bug reports. I’ve got many more in my notes, but these are just things specific to this project:
- Concurrent simple and compound time signatures (with the same base tempo i.e. crotchet = dotted crotchet)
This is definitely the thing that required the most hacking, and seems to me an established and common enough practice to be quite high on the list of priorities. Achieving e.g. 12/8 against 4/4 is relatively easy using the method mentioned above, but there are problems with this approach.
- Having a hidden time signature in the next bar means multirests are split at that point in parts.
- Independent time signatures disappear in condensed staves which means my score is dotted with floating text elements that I have to be careful to hide and show in the right places. This is especially annoying over a system break as I had to input 2 text elements (one for each side of the break) and in some instances add another time signature in an uncondensed part in order to get the space at the right hand side of the system in which to position the fake time signature text, and then delete the time signature in a pdf editor after export.
- I need to hide all the tuplets and brackets in the compound bars - musically correct of course, but a faff.
See example over the break in this image - the red circles are text objects carefully positioned, and the blue is a time signature I removed in a PDF editor after export:
- Option to have grace notes attached to previous rather than next note.
This music in particular is littered with trills that end with a grace note turn. The ‘grace notes before barline’ option is great in most cases, but where this is followed by a rest, a return to unison after divisi, before an instrument change, or at the end of a phrase I am using as a cue in another part, I have had to rewrite it as a tuplet in the bar before, and remember to change the its size etc. otherwise it would not show up. This turns from a faff into a problem when other instruments are playing something busy with lots of short notes as the fake grace notes gets stretched to line up with their ‘correct’ place in the bar.
e.g.:
- Add toggle to move individual components of Linked/Grouped dynamics in engrave mode.
This was more a of a problem for me because of the way I had imported XML and copied and pasted dynamics around, and in the end I just selected every dynamic and removed them all from groups/unlinked. The engrave mode auto aligning feature made tidying up relatively quick (though it’s a bit buggy - sometimes I have to switch to write mode and back before the changes are visible), but it’s a shame not to be able to take advantage of these features. The ideal solution (which I’ve seen suggested on the forum before) is to e.g. hold a key while clicking and dragging to move just the individual component of a dynamic group selected, and it will then stay in that position relative to the group.
- Allow layout specific clef changes.
In this project, trombones are in bass clef throughout in the score, and most of the time are condensed onto one or two staves. The first trombone is mostly playing up high, and it makes sense in the parts to use tenor clef. It doesn’t matter so much in the score, as it saves space to have ledger lines which are easy to read when all 4 trombones are playing a chord on a condensed stave. This wasn’t much of a problem for me as Ryan wanted a transposing conductors’ score. Therefore I just changed the trombone part layout to concert pitch (it’s in C anyway) and then put lots of clef changes in and set them to concert pitch only.
- Allow layout specific text object line wrapping.
I guess this could be achieved by using a bounding box for text objects with wrapping options. There are a couple of long instructions I input as tempo text which look great on the score (A3) but cause problems in the parts (B4) especially as they’re much more difficult to get to appear at the beginning of a system. I ended up inputting lots of text objects with line breaks in different places and hiding them in the score, then changing the alpha channel of the tempo text to zero in the parts.
- Feature to number repeated bars in parts.
Not difficult to achieve using text objects hidden in the score, but might be a nice quick way of doing this sort of thing:
- Hide/show labels for divsi and cues
In many cases I wanted to hide the text label associated with a specific div/unis or cue. This can be achieved by changing the alt text/start text to a space, but then I’ve lost the object altogether and have to delete and recreate the object altogether to get it back. It would be nice if these labels could be hidden (and replaced with a flag) as per player name labels in condensed staves.
- Option to have text associated with continuation lines (eg. cresc) bracketed at start of system over a break.
I didn’t bother editing this post export - it’s a huge job to do it that way, and I know this has been requested many times before and is in the pipeline.
Bugs spotted:
- Slurs, ties, and grace notes disappear when over a system break that includes a change of divisi or condensing.
- Multirests broken in parts when condensing turned on as reported here
This has been fixed in the latest build. But seems to have introduced a new problem:
- Superfluous accidentals shown in lower line of divisi parts.
Easy to hide, but easy to miss! e.g. viola:
- Key signatures at instrument changes clashing with next object.
e.g. Horn 5/Wagner tuba 1:
I had to fix this in a PDF editor after export. I see there are key signature spacing and x-offset properties but they don’t appear to do anything
- Extra/missing accidentals on export.
This is an odd one - as far as I can tell this can be fixed by simply opening the layout in question, clicking around a bit, and re-exporting. For example:
Rant over. I’m looking forward to doing many more projects in Dorico!
EDIT: apologies for some spidery text on those images - I’m limited to 700px wide…
