Should Dorico be just part of Cubase?

Dorico
21

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.

22

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.

23

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.

24

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.

25

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.

26

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
27

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.

28

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
29

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.

30

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.

3 Likes
31

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.

32

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
33

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.

35 Likes