A couple of Playback bugs

I take issue with the description of Steinberg as a “mega corporation”, for what it’s worth. Yamaha, our parent company, probably does fit the bill of a “mega corporation”, but Steinberg certainly doesn’t. And it’s worth remembering that the number of people working full time on Dorico constitutes a tiny proportion of the total employees at Steinberg, too. I say this not as justification for us missing any features or having specific bugs – I would pit our development and testing teams against any other team in any industry and feel that our team would stack up pretty well – but just to point out that it is not the case that Dorico benefits from having infinite money and people thrown at it. Notation software is a niche within the niche of music software, and we are incredibly lucky to have a supportive corporate parent who believes in what we are building and in the long-term viability of both the Dorico product and the market for notation software.

This week marks Dorico’s second birthday. I think we’ve come an astonishingly long way since the first public release in October 2016. We still have a very long way to go, to be sure, but we didn’t really have any option but to first work on notations that are used in 19th century music because, guess what, all of that same notation is used in contemporary art music as well, plus a load of other stuff. If we’d prioritised working on, say, advanced notation for wind multiphonics or variable pitch shifting on brass instruments before we had implemented, say, slurs or beams, we’d have a piece of software that is useful to precisely nobody. The difference between Dorico and other programs is that we will implement these things and implement them properly, rather than relying on workarounds. For example, the forthcoming update will include support for jazz articulations (for printing, not for playback, initially) that provides really exceptional placement, fast and efficient input, tweakable appearance, and so on. The tedious workarounds you have to employ today for those symbols will be completely eradicated when the new update arrives.

I know that your concern about ossias not playing back reflects your need for driving playback in a more direct way than Dorico currently allows: Paul and I have discussed the desire to have a convenient way to create MIDI events that won’t appear in Write mode, and we have a number of ideas about how to make this possible. It’s not likely that this will make its way into the next update – Paul is currently focused on things like MIDI recording, click track, and so on – but we definitely want to address this as soon as we can.

As for collision avoidance, you should see no collisions when you’re in page view. In galley view there will be some collisions because Dorico doesn’t move staves apart automatically in galley view, but in page view this shouldn’t be a problem.

I concede, but it’s actually page 51 and that’s partly one of the problems of the documentation, there’s too many scattered sources. I’ve read all of the manual, seen the YouTube videos and I try to read every new post on the forum concerning how to do something and now it turns out there’s also this other document… Where did you find it?

Hi Daniel, yes I was referring to Yamaha and as a social/political activist I cannot separate the two. But don’t misunderstand the context, this was not an attack on you lovely people, but in fact the opposite since you were probably pressured to start selling copies before you felt the program was ready for “Pro” time. Also, I’m heavily invested in the development of Dorico and trying to help make it better by almost exclusively tracing bugs (as Ulf can testify) and occasionally making a feature requests to make Dorico more workable. Aside from my rant more than half a year ago about brass articulations, I have not complained, but there are lot people in this forum that are incredibly defensive and make this, completely voluntary, activity quite tedious. For example in this exact same thread where I simply posted what to me appeared to be bugs and I get all this hassle about how wonderful Dorico is and weird things about hurting yourself with scissors and still no one has answered my question regarding CC lanes and expression maps compatibility, are you meant to use one and not the other?

I’m glad to hear about so-called jazz articulations coming in the next update, finally I’ll at least be able to make Big Band arrangements with Dorico.

Ossias not playing is not an issue, I was just asking.

Re playback, if you gave us the ability to hide a staff but still have playback I’m sure we could all work with that as a workaround till the day you implement something new and cool. The problem as it stands is that Dorico doesn’t do either right, the maps don’t play half the stuff and the DAW part doesn’t do enough things (e.g. pitch bend, keyswitches, etc) so we can’t get playback one way or the other… snif!

Re galley view, I really don’t understand this design decision. If Dorico doesn’t have to calculate page layouts and spacing what’s so processing intense that it can’t simply move the staves apart? It’s not just text that ends up on top of other staves, but also notes on ledger lines… it’s quite odd.

Re: Version History - you were given the option to download it when you installed whatever version of Dorico you’re running. It’s available from the Steinberg Download Assistant and on the general Dorico download page (here https://www.steinberg.net/en/support/downloads/dorico_pro_2.html).

The “manual” only covers features that exist in Dorico 1. It’ll eventually be turned into a Dorico 2 manual, covering all the additional bits, but it doesn’t yet. It’s thus crucial that you refer to the Version History when working with features that have only existed since Dorico 2.

I am guessing from the same standpoint as you, i.e. an outside user, but I would imagine that the necessity to adjust intra-staff spacing according to a potentially infinitely long series of objects might be a bit processor-intensive. Not to mention the annoyance that would result from the entirety of the flow having its staff spacing distorted by, for instance, an unusually high note in the very last bar.

But whatever. One thing I’m sure of is that this design decision, like all the others in Dorico, will have been taken ‘reverently, responsibly, and after serious thought’.

The Version History PDF has been linked to in every announcement post we’ve made about an update (e.g. this one), and everywhere you can download the software itself – for example, it’s on the download page in the support pages of the web site (e.g. here), and indeed it’s also these days provided as a separate download inside Steinberg Download Assistant. We definitely consider it an important resource for users to learn about the things we’ve added in each new update. I’m sorry that you haven’t managed to catch on to it before now – do let me know if you think there’s anything more we could do to make it more obvious. (One thing that is a bit awkward for us to do is actually install it along with the software itself, since it tends to be finished after the software itself is finished and has been built.)

I don’t think we’re trying to pretend that the expression map functionality is as well-developed as it needs to be or as we intend it to be. In the specific case of written dynamics in the score that you set via expression map to play back using e.g. CC11, and then write automation data into the lane for CC11 in Play mode, the issue here is that we actually intend to expose a special lane specifically for dynamics, which will show the effect of the written dynamics in Play mode using whatever controller is used to realise them, and allowing you to adjust the profile in a more consistent and predictable way. This isn’t possible now: you won’t see the written dynamics in the CC11 controller lane, and the presence of your own data in that lane won’t completely replace the generated dynamics, so as you have found you will get interference between the two conflicting sets of data.

As Toby has already rightly surmised, the reason Dorico can’t do collision avoidance in galley view is that it would have to process the entire flow in order to determine the positions of all items and all staves. This would be too computationally expensive to be practical. We would definitely like to make it easier to adjust the positions of staves in galley view so that you can manage some of these collisions yourself.

Wow! Just wow… This program is going to be pretty amazing by the time you guys get everything you want in. I’ll say it again, happy to be on board.

And in terms of the documentation, no I’m afraid I have no suggestions. We’ll all just have to wait for the manual.

Well, you don’t have to wait for the manual. Between the Dorico 1 and Dorico 2 Version History PDFs there is around 150 pages of useful documentation that supplements the documentation already available online. So I hope you will take the time to at least flip through those two PDFs so that enough of it might be retained that you might remember where to look if you’re looking for answers in the future. (They’re also searchable in most/all PDF readers.)

Sweetie you! Well I have certainly read the whole manual that’s accessible via the Help menu and I saw every video on the YouTube channel. Now thanks to you and pianoleo I realise that there are also these other sources to read… I’m getting pretty familiar with it and starting to customise it to my needs, which brings me to this other request:

Could we have more customisable options added to the key commands? I really wanted to change how to access hairpins the other day and found it was not possible. I have moved most basic inputs to the NUMPAD, including articulations, and I have changed the dynamics to simply D, so I can get everything in with one simple keystroke, but I still need to press SHIFT for the hairpins which slows me down.

Ah! And also, could we get a simple command for re-spell accidentals? I appreciate the value that re-spell using note below/above might have, but when you’re proofreading a large score I find it best if you just have the great majority of these commands directly (one key press) accessible e.g. re-spell note, break system, page break, make into system, etc. This way you can get the required layout for rehearsals in no time… Pretty please?

Thank you!

You can respell a selected note enharmonically by pressing Alt-minus or Alt-equals.

You can also filter all notes by a particular pitch and bulk-respell them.

You can set any preferred key commands for “Make Into System” and “Make Into Frame,” as well as most other important commands.

  • Ctrl-comma for Preferences
  • Key Commands
  • type into the search bar to quickly find the command you want to assign.

I also feel I could use a simpler, uncompounded key command for enharmonic respelling, just one that rotates through the (most common) enharmonics.
And, for that matter, is it possible to exclude the abominations of triple sharps and flats from anything I would ever notate, please? (I know they have been seriously written down by some, but I’ve not encountered them ever IRL). Or maybe even exclude double sharps and flats (and E#/Fb/B#/Cb) when I’m notating early music?

Thank you dankreider, I always appreciate your contributions but you don’t seem to read the posts correctly. I said I appreciate the respell not below/above which is the alt -/+ you mention, but like PjotrB I’m requesting a simple respell as in one key press changes Bb to A# or viceversa. Thank you anyway.

Ha, ha, ha, ha! Abominable sounds hilarious and yes I too found it weird, but I think they’re highly used in atonal serialism. I personally never, ever used them in a part because they just slow down the sight reading of the player, but simple ones like E# are very useful when you’re for example in F# or C# major… it’s actually easier to read E#-F# than it is to read F natural- F sharp. It makes more musical and visual sense. Especially if they are repeated a lot in the same bar…

You’re right, I misread your request for a single enharmonic keypress (in Finale I think it was 9), and I agree with that.

The other commands you mentioned (frame break, system break, make into frame) can be assigned to keystrokes, so that bit is ok. Although you have to switch to Engrave mode for those, and I think I remember Daniel saying that wasn’t going to change, so Write mode wouldn’t access them with a single keystroke. Although score formatting seems more suited to Engrave mode anyways.

Dear Dan,
IIRC Daniel gave a workaround (I have not tried it because I’m not fond of messing into json files) to use the breaks commands in write mode in a thread last month or so…

I have to say, I really do like the Engrave mode conceptually and have no complaints about how it works. It’s mostly Write and Play modes that need a bit more work.