Should Dorico be just part of Cubase?

Well for one, a DAW, unlike Dorico, is actually made to work with audio files. Then MIDI came along and joined.
A DAW only knows a timeline, it doesn’t know pieces or flows. It doesn’t know players but rather tracks.
You can easily mix and combine audio and MIDI there, and there is no need to quantize anything, if not wanted.
But the perspective is always to have an audio file as output and to work towards this goal with editing, mixing and mastering tracks.
Dorico on the other hand thinks of quantized (notated) music, tries to apply the language of music notation (dynamics, playing techniques etc.) and go from there to tweak the output.

Your question is similar to “if Dorico wants in depth layout options, whats the point in distinction to a DTP program?”
And the answer is: it’s coming from the perspective of music notation. Are there things you should rather do in a DTP program? Sure! Is the implementation and expansion of features in that direction therefore unnecessary? Not at all.

1 Like

See the answer I posted to ebrooks above. I don’t know why Logic and Cubase implemented notation (in case of Logic it’s very bad…), probably to cover some fundamental need. But their capabilities are nowhere near Doricos.

That is exactly my point. And people publishing music in written form will chose Dorico, which is purpose built for that, and people publishing music in audio form will chose Cubase. Where’s the problem with that?

I think your comparison is flawed. I would rather compare Dorico to LaTex (or Lilypond, to be even closer) than Word or Open Office. There, compiling my thesis of only 70 pages took several seconds, too. Why? Because complex algorithms determine the most elegant way to layout the content.
The result was much more beautiful than I could’ve achieved with Word or OpenOffice.

Both programs - both Cubase and Dorico - are also loudly advertised by Steinberg as composition tools.
The requirements for such a tool are comprehensive and certainly very individual…

I compare to the text processors because the functionality is the same - if you edit text in page 5 (enlarge font, manage paragraph size - space before and after) it will move the whole text till the end of project. Virtually, not on screen. The same in Dorico. You don’t see all 70 pages of score at once. So both programs (text processor and notation software) have to calculate every page you select to show on screen.

LaTex is also a text processor. And again, the way its layout algorithms work is (IMO) much closer to how Dorico operates.
If I add something in one bar, it might lead to push a bar into another system, which in turn might lead to the previous systems having more space and therefore some other pervious bars landing on other pages, too. The calculating therefore needs to be done from the very beginning for the whole document every time. This also happens in LaTex, but not really in Word or OpenOffice, where maybe one or two lines are being moved to another page. The formatting of the previous pages stays intact.
(And to be clear: this behaviour of Dorico is not a bug, it’s a big feature!)

Sorry, this is incorrect. The original DAW didn’t have any audio, only MIDI. You say it’s easy to mix audio and MIDI in a DAW but the actual development to integrate audio with MIDI into the same program and make it easy was a massive and highly complicated process. MIDI is measured in PPQ, audio is measured in seconds. They had to be synced somehow and that combination is what gave rise to “the grid” and much of modern music. It is also the reason the “tempo track” has always been shown in a separate window and as a separate entity.

There are of course differences in the treatment of notational graphics, but both Dorico and Cubase rely on MIDI in the same exact way and there isn’t much difference between “Flute 1” and “MIDI Track 1” for playback purposes as opposed to display. Both programs accept “free-hand” recording and note input and then both programs quantize the recording itself as well as the “notated” result. Most playback features in Dorico are taken from Cubase. In some cases, they are improved, in some others they are used very creatively (independent voice playback) but in the majority of cases it’s hard not to think of them as anything other than porting existing Cubase functionality into its own development environment.

I use Dorico every day, and of course I want it to succeed. This is why I genuinely don’t understand the constant attempts on the forum to defend the developers by pretending there is some kind of unbridgeable gap between playback and notation. This is completely misguided in my opinion and ultimately misleading. My first DAW was Cakewalk and it supported both MIDI (no audio) and basic notation. This was in 1996.

The major difference between Dorico and Cubase is that one chose to specialize in engraving, and it naturally prioritized that capability over everything else including playback, at least for now. But there is absolutely no technical reason why Dorico cannot eventually provide Cubase-level playback - it’s the question of time, resources and commitment.

Which brings me to my original point: it would be great to know what ultimately is the level of playback Dorico developers want to provide? Something that’s merely “passable” or something that’s Cubase-quality even if a couple generations behind?

AFAIK we cannot compare Dorico with the LaTex. In LaTex you work more with a code. It would be like if you edit xml pieces in text editor and every melody would add like C6, D6, G6, A5 and so on. So forget about LaTex. I still stand on comparing Dorico with OpenOffice Writer.

To opposite to your comment, I would say imagine that you in OpenOffice Writer add a total page count field in the footer so it appears on all pages. If you add more text in page 5, it will calculate page count on every change you made. So it is the same as Dorico does. Right? It won’t change the look of pages that are before the position you have changed. I don’t believe that Dorico calculate the look of pages that are before the position you have made changes in. But if yes, then… haha! Probably it’s another fault.

I’m not aware of playback. It is good for me. I understand that it will never be like in Cubase when you press Spacebar and it plays instantly. But I’m talking about Dorico’s overall speed - on any move, on any note insert it is so slow that I lose the connection between notes in my orchestral idea in mind. While I’m fighting to input flute, my oboist is dead.

The algorithms for layout don’t care about the front end. And they are causing the biggest calculation time.

Also, updating a page number is something different than literally deciding the position and relation of every single item.
And try it yourself: Dorico does change the look of previous pages, if necessary. That’s because of the rules of how to layout music. For example: system breaks should appear at rehearsal marks, if possible.
Once you move a system into another page, the page before has more space, so the notespacing needs to stretch. The page is less filled and there could be a more optimal way to layout the pages before. Try inserting a system break somewhere and observe it.
It’s not a fault though. It’s how music notation works. And this goes again back to my initial point: coming from a DAW, that all doesn’t seem to make sense, but coming from music notation, it’s a big benefit of Dorico.

I don’t think anyone is pretending the gap is unbridgeable. The argument I am making is: both areas are incredibly complex by themselves, and involve an incredible amount of features to be successful in their respective fields.
To achieve that one needs:
a) a loooot of developing time
b) a huge (and probably bloated) final product.

I think it’s easier to have two programs do the best in their areas and make it easy to switch data between them.

I mean that says it right? Doing both right is incredibly hard, and pretending it isn’t is unfair towards the developers of both cubase and dorico.

Nope. Biggest calculation time is where visual representation is different from a code. This is in Writer and Dorico.

Okay. So if I don’t use system breaks or anything else that could have be represented in previous pages, the Dorico should run faster? I don’t believe.

Sorry, guys, but it seems that this night’s topic isn’t productive. Those who have i9 and 64 cores won’t understand those who have i5 and 4 cores. Excuse me that it took your time.

I am not sure what you mean here (and surprised that you seem to understand Dorico so well, while simultaneously not understanding it at all), and at this point it seems to me, that you are not even trying to understand the points I made.

The system break was just an example of how:
changing music in one spot…
… changes the layout before and after

A system break in Word doesn’t do that. That was the whole point of why your comparison doesn’t work.

1 Like

Dorico is slow constantly even I have one page or ten. Even it has one note or thousand. So there is nothing about system breaks and calculating previous pages or all pages till the end.

For me it’s quite responsive with little music and gets incredibly slow the more music (and Instruments, and Flows) I add.
If Dorico is already unbearably slow at the beginning, there seems to be some underlying issue with Dorico on your system.

1 Like

Really? And only Dorico? Not Cubase, not WaveLab, not VST Live, not huge Adobe pack, not Vegas 19, not 3D design programs, but only Dorico. It is so special that my spaceship falls in a category of worst systems.

Thank you! At last we can close this discussion.

Just taking your points out as I understand them:

1) Why is Dorico slow?

I don’t know what libraries Cubase use to program (and presumably over this amount of time they developed their own) but Dorico and Sibelius are both based on QT - a universal framework which is most likely dragging them down a bit - try to please everyone a bit, please nobody fully etc.

I believe the reason it’s written that way is because it’s the environment the team were used to writing in but I may be wrong. I do think it would be more efficient if the GUI was programmed from the ground up but I think it’s likely that the resources don’t exist at this time - it’s probably an expensive enough project as it is.

I do agree with you though - a more efficient and OS-specific programming environment would be much better. I wonder as well whether the engine that they use to update the screen could be multithreaded in such a way as to allow things to load in the background - how often do they need to render the full score when only editing a portion for example? I think it’s interesting comparing to a word processor, because editing something on page 20 very rarely affects something on page 3, and therefore the entirety of the layout. I’ve no idea what steps have been taken to optimise the refresh process, but this could potentially slow down Dorico significantly…

2) Why are Dorico’s notation features not part of Cubase?

I’ve always wondered - what is the difference between Cubase and Nuendo? I’ve used both - both are by the same company- why produce two different environments to do essentially the same job? As far as I see it - it’s the same reason I have a Mountain/Hybrid Bike, a Touring Bike, and a Road Bike (and am coveting an Electric Bike and a Gravel Bike). They are all basically the same idea, but each tool for their own job. They both sort of do each other’s jobs, but Dorico is written as a Notation-specialist, Cubase a DAW specialist.

Also - too many diverse features and any piece of software becomes bloatware - never a good option.


Yes? It’s not unheard of?
I had the situation, where on one (powerful) Windows machin, Pyramix (a DAW) worked like a charm, while on another (even more “powerful”) machine it basically crashed every 2-10 h randomly. Other programs worked like a charm there. These things happen on some systems, and it’s a pain to find out why.

At last and at least one understood what I’m about. Thank you! Now I can return to composing. This is my lucky moment. Thank you all!

1 Like

There are quite a few misconceptions being perpetuated in this thread.

First of all, why is Dorico a separate product to Cubase? Because it makes more business sense for Dorico to be a separate program, appealing to different (though overlapping, of course) customers than Cubase, and with a completely different focus. Dorico is a music notation and composition application with strong MIDI editing and virtual instrument features, while Cubase is a fully-fledged digital audio workstation with strong scoring features. Naturally we want to bring Dorico and Cubase closer together, and we will do so, but the two products will not merge into a single one. I can’t talk about the finer details of how the two applications will come closer together, but if you continue to be patient, you will see.

Secondly, any sluggishness in Dorico’s performance is not due to its choice of user interface framework. No UI framework is perfect, but Qt is exceptionally feature-rich and really well-suited to an application like Dorico that requires very precise typography, 2D drawing, printing, graphics export, and so on. Of course we evaluated the use of Steinberg’s existing GUI libraries, but they were not at the time (and are still not today) suitable for use in Dorico, and we made the decision to focus on building our application rather than spending a year or more iterating on the existing GUI library – time that we considered to be essentially reinventing the wheel.

It doesn’t make any appreciable difference to the performance of the application what colours you use, and whether buttons have rounded corners. (The assertion that it does suggests a lack of familiarity with modern GUI tools and their performance characteristics.) It is also very important that an application that thousands of users are using for many hours at a time is comfortable and pleasurable to work in, so even if it were the case that drawing a button in a particular colour or with rounded colours had any impact on the performance of the application, that trade-off would very likely still be worth making if it improved the user experience of the software.

In addition, the parts of the user interface added in Dorico 4 – the Mixer, the Key Editor, the Keyboard and Fretboard panels, etc. – are built using a newer user interface technology that is part of Qt that is designed to make use of hardware acceleration and which can be very performant indeed. At the present time, the actual score display is using an older, imperative drawing technique that cannot itself take advantage of hardware acceleration, so when it is redrawn while you are scrolling the score on a very large display (e.g. a 4K or 5K display) at a low zoom level, such that there are thousands of glyphs and primitives on-screen, you will experience a slower frame-rate, but each redraw never takes even 100ms, even on large displays. Redraw is a negligible part of the overall response time to making an edit in Dorico.

We do plan to migrate the whole application to use the newer, hardware accelerated GUI framework in the months and years to come, but this is a big job and will not be completed in one development cycle. And, in any case, although it will be great to have the score scrolling at 60fps regardless of zoom level and the number of pixels in the display, that on its own will not make inputting and editing music in Dorico faster and more performant.

Finally, the performance characteristics of music layout and of text layout could not be more different. Both domains are very complex, much more complex than might be apparent to the lay person. Indeed, I don’t have any direct experience of working on text layout, but since it is such a fundamental aspect of how information is presented to the user when computing, it is something for which there are very well-optimised approaches (including strong support at the platform level, in terms of rich text, font layout, typography, script support, etc.). Developers of word processors and text processing tools can build on top of this excellent support. (Dorico’s text handling itself relies on these very same technologies, of course.)

In short: no text processing or word processing software needs to implement text layout on its own (unless its developers really want to, and have a good reason to do so).

Music layout is a problem of comparable complexity to text layout, but since it is a much more niche requirement, there is no platform-level support for it. So any music notation software has to implement music layout on its own – and Dorico is doing it to a level of sophistication that has not been attempted by any previous application, with the possible exception of Lilypond, which can require multiple minutes to lay out a score. Dorico is attempting to do this in as close to real time as it can. And music layout is only one part of the computation that Dorico is performing when it responds to each edit triggered by the user.

We aren’t satisfied with Dorico’s overall level of performance, and there is plenty of scope for us to continue to improve its performance, as and when we can put in the required effort in these areas. As I often say, we have a small team (smaller than before, because some of our developers are also working on other projects within Steinberg), and so we have to choose what we work on carefully. Improving performance is just one of many things competing for our time and attention. However, please be assured that the use of Qt as the framework upon which the application is built is not a factor that is holding back improving Dorico’s performance.

I’m going to close this thread now, since I don’t think there is much to be gained by further back and forth on this topic.