Will Cubase 13 have an improved Score Editor?

Cubase
23

I think it will happen, but it will likely take time. However, they certainly realize that they don’t have that much time to make it happen. Consider that each of the various apps in the Steinberg catalog use different frameworks and have had different developers/teams since they were started and/or acquired, and that kind of long-term legacy code and institutional knowledge is really hard (and expensive) to adapt and change. But people move on in life and retire, and the guy who is primarily responsible for the score editor isn’t getting any younger. Steinberg is being smart to be thinking long-term here.

I’m guessing that they’ve been discussing how to build their apps on a common framework for years, but that kind of investment is very expensive, not to mention the time needed to refactor old code. They also have to balance maintenance and new features against such deep refactoring to meet their product lifecycles.

So my guess is that there will be a new scaled down engine from Dorico that will be added in time, but some very hard decisions will have to be made about the legacy score editor, when to drop it, and which features won’t make it over to the Dorico engine. I predict that at some point Steinberg will have to rip the band-aid off and it will be a rough couple of years for the devoted users of the current score editor, especially those who rely on the nuances of the current score editor. They’ll need to build a translation layer for the old score data, and there will no doubt be many bugs and minor translation issues.

If I were managing things at Steinberg, I’d have the current score editor developer – who is reportedly a really great guy and quite brilliant – work hand in hand with the Dorico team to “transition” to the new score engine. I would think that 90%+ of his time should be spent on this transition process to make it as seamless as possible for Cubase 14 or 15. It will likely take him a couple of years collaborating with the Dorico team IMO.

In the end, doing that will be the right decision, though. Sometimes you have to let go of legacy code altogether, despite the frustration that will cause for some users. When you have one main guy at Steinberg who has been devoting his career to one aspect of Cubase, and he’s obviously reaching retirement in the coming years, you need a transition plan.

All this is an opinion. I could be completely wrong.

3 Likes
24

Yes. In many cases, it is easier to build a new product from the ground up than to retrofit the old code. That worked for Dorico, in part, because of the existence of MusicXML. This allowed a reasonable migration path from the older products. It isn’t perfect, but I’ve used it on a half-dozen Finale projects where I found it was faster to XML it to Dorico and fix any problems in Dorico.

It is too bad there isn’t an XML standard that encompasses the things a DAW does. I wonder if it would make any sense to try to extend MusicXML to cover more things that a DAW does. I know there are many difference between products, but all of them have a collection of tracks, which contain clips, which in turn may contain envelopes and comp lanes. And the channel strip contains routing directions and effects chains, with each effect having its own family of settings.

2 Likes
25

A decent/robust in-house built ‘syncing technology’ between the two engines in the meantime, would go a long way…

1 Like
26

I believe not quite so different as you might think. Dorico works much more similar to a DAW, by basically looking at the notes on the timeline and deciding on the fly how to render them (ex. if it is a long note that starts off-beat, or goes to the next bar, it will need to be tied etc.) and dynamically displaying rests where there is an absence of notes.

Because Dorico basically works by looking at the note on the piano roll and deciding how to render it based on the point where it starts and ends, its already a lot closer to working like the integrated notation component of a DAW than most notation programs are. In this way, it has a really good shot at achieving an excellent integration in the long term.

Where the difference comes in, and this is probably one of the things holding things up, is that Dorico’s master representation of the note is the note MIDI event representing the way the score should be displayed on the printed page. What I mean by that is you have a certain sounding note (where the actual note sound starts and ends) and that corresponds with a certain written note (which will be quantized to the grid so that you don’t end up with things looking insane). In Dorico, the written note is stored as the master, and the sounding note is stored by having “note start offset” and “note end offset” attributes under the written note. In Cubase, the sounding note is used as the master, and the Display Quantize process is used to decide how to render those and simplify those to certain written notes. They’ll need to reconcile that somehow in order to achieve integration, such as by having every single note in Cubase have a “display representation” rather than relying on Display Quantize (which only affects the display in the score view and doesn’t get written back to the note itself).

1 Like
27

Are you sure about this @mducharme? When Dorico was introduced I learned that it evaluates the notation, dynamics, expression marking etc., in the notated score first, and then renders the midi playback. @PaulWalmsley has discussed this, though I can’t find the post presently.

28

Yes, both what I said and what you just said are true, to the best of my knowledge. I should clarify that I obviously don’t have visibility into the internals, but I speak as someone who has used both programs for many years, and I have previous development experience as well, although nothing related to notation or DAW.

To clarify, Dorico does not store rests - they are the absence of notes and are auto generated, and Dorico stores notes by basically storing what bar/beat/subbeat it starts on and what bar/beat/subbeat it ends on the timeline and choosing how to render it based on that. So the internal representation is similar to what you would have in a DAW piano roll, except it is always fully quantized for correct notation. Because the note might be offset (de-quantized) a bit in terms of actual performance for humanization, Dorico stores a note start and note end offset as attributes of each note, and these are used for playback.

In Dorico, you can go into the piano roll and drag rectangles to enter notes like in Cubase and they automatically get rendered properly. You can also shift notes sideways or make them longer or shorter and everything is automatically rerendered correctly, because it gets rendered on the fly, similar to the way DAWs render notation from a piano roll and this updates as you shift notes around and adjust their lengths. Similarly, you can change time signatures and things like that, and the bar lines move around the existing notation with all notes still arriving at the same position in the timeline as before (and still syncing to picture in the case of film scoring), the same as how they would in a DAW. It is obvious, based on all of this, that the way that the data must be stored underneath on a basic level would have to be very similar to a DAW, but obviously with additional fields as it would have to store information on articulation, dynamic, other text on the score, etc.

At the same time, Dorico takes this “idealized” piano-roll-like representation used to generate the written score, incorporates any additional symbols added, and constructs a “playback” piano roll representation that incorporates the note start offset and end offset and this other information, and this is what actually drives the MIDI playback.

These are not things that the developers have communicated in exactly this way, but are instead things that are readily apparent just based on observation of behavior from extensive use of the software. So in my case, I am deducing how it must work underneath based on my personal experience using the software, as well as my many years of IT and development experience. The actual implementation is almost certainly more complicated than this, but I am fairly confident in my interpretation of the big picture.

30

Since he got mentioned here several times: In case you have a good translator for your web browser or your German is good here is the link of his web page. Michael is a great guy and an interesting person. Amongst other things there are also some interesting stories to past Cubase development.
https://www.michael-michaelis.de/index.php

5 Likes
31

If you know something to be factual, please state it. However, just for the record, everything you say here (as you point out) is simply conjecture about how the program works.

For the record.

32

No, I don’t know anything to be factual for 100% certain. It’s not like they explain how it actually works underneath. Most people don’t really care how it works underneath as long as it does what they want.

But it always struck me as a very smart design because it actually would allow it to be integrated with a DAW later (with a fair amount of work, of course), whereas it would be nearly impossible to do the same with competing programs (Sibelius, Finale, MuseScore).

The thing I can state is factual is that it is the only major notation program that behaves similar to the notation components of DAWs as far as edits, interpretation, handling of rests, etc. (Even that of course is an opinion though, which others may disagree with, but I can provide ample supporting evidence for that.)

1 Like
33

I’ve removed a couple posts that were off topic.

Going forward, please keep this about Cubase and the Score Editor.

1 Like
34

I think there is an alternative approach Steinberg could use. Take the current Score Editor and turn it into an add-on module, kind of like ARA for Audio. That would allow folks to access their old scores as needed without concerns over translation issues.

3 Likes
35

Being an user of both Dorico and Nuendo (this one similar to cubase, hence my post), I’m amazed at the quality of score output in Dorico, but the actual “mechanical” work in Nuendo’s editors (score and MIDI) is vastly superior in speed. Daniel has replied in the past in the Dorico’s forum that the foundational platform for both programs is at a different MIDI level, hence the apparent sluggish Dorico’s behavior, in face of the instantaneous editing in Cubendo. That time he refered the Cubase guy, with much appraise! But both softwares don’t operate at the same MIDI level. I would love to see the next Cubendo iterations to import Dorico’s engraving options and score layout setup, but to maintain the Cubendo scheme of things.

4 Likes
36

A lot of the reason for the seemingly sluggish behavior is all of the automated CC writing Dorico does for the dynamics etc as part of the expression map changes, and making edits impacts the phrasing which causes it to rewrite CC’s. In Cubase this would not be an issue because you’re probably not going to want auto generated dynamic CC’s like you have in Dorico to begin with. You can largely prevent Dorico from becoming sluggish by changing it to the silence template, then you it won’t have to rewrite CC’s (but then of course you can’t hear anything).

37

Hmm, do you think so? I don’t need to listen while I’m writing in Dorico, I can “hear” the music on the score, so most often than not I use it in silent mode, and it never is as responsive as cubase key or score editors.
Maybe I can forward Daniel’s response, if I can find it :slight_smile:

38

It might not be quite as responsive, but it should be very close when you are using “Silence” and when you have condensing turned off for all layouts. Make sure condensing is off for all layouts as it will have to recalculate condensing even if you aren’t looking at the layout at the time.

For me the responsiveness is quite close to this even without using silence, but I have a reasonably new system (built it myself just before the pandemic with top of the line hardware at the time).

1 Like
39

If the integrated Score editor was removed I would use it as an opportunity to ditch Cubase.

Pro12, Pro24, almost every version of Cubase on both Atari and Windows … but v12 would be my last should this happen.

It’s one of the few key differentiators that makes me tolerate the less-than-ergonomic user interface(s) elsewhere in the app. Overly-dark, claustrophobic and all-but-impenetrable to new or casual users … but the Score editor helps compensate for this.

The MIDI Remote controller integration was a great idea but one Steinberg themselves seem to have abandoned, left to scant few developer types who muscle on through with partial integration solutions.

Why can Steinberg seemingly not forge synergistic relationships with other manufacturers, relying instead on goodwill or half-@$$€d community implementations!? Is it a consequence of their tuning fork parent, I wonder!? :thinking:

1 Like
40

Those of us who use Dorico and regularly read the forum know it, but those not using it may not know :
The Dorico team has said recently in a reply to a post in the Dorico forum that of course they are planning on a Dorico integration, however they said something along the line of “out of respect” they can’t really make a move as long as the original score editor creator is around, although he does plan to retire, and that’s most likely when we’ll get a better score editor (honestly, I can’t wait as I find the Cubase score editor horrendous and way outdated compared to what some competitors do even though they don’t have a dedicated score notation software)

41

For fullness and accuracy of info, here is the post I presume @AMazedBrane refers to

42

thanks, that’s the one I was referring to :slight_smile:

43

Interesting…that’s be amazing if it’s possible.

No clue what they’ll end up doing but:
I’m thinking,
First…
Get one really ‘solid’ post dongle era release that supports everything “Legacy” they possibly can. This should include all the editors (like the current Score Editor) old remote stuff, MIDI modules (the ones where users can do instrument profiles with sysex and stuff), VST2 support (possibly even a 32bit ‘bridge’ for really old stuff), etc.

Cubase 12 should be pretty close to being able to serve as the evermore supported “Cubase Legacy” bridge (For PC Users it’s nearly there. Mac Silicon people have a rougher time needing Rossetta or something?)!

Maybe rather than give such release a ‘number’ in its name, it could be called something like “Cubase Legacy”? Keep it in the ‘supported’ bracket forever-more, but only for keeping it working in newer OSes that come on the scene, or critical bug fixes and the like.

There are a few things I’d like to see added and/or fixed in the current Score Editor before it gets discarded (if they ever do)…but I’ve given up on those. It’s been a really long time since anything noticeable has been added to it.

Having a solid performer that can import pretty much any legacy settings and projects and doesn’t require a ‘dongle’ would provide a ‘roll back point’ to take care of any Cubendo user’s potential needs to work with old ‘legacy’ projects. That’d also give legacy coverage to the newest users who’ve never owned a Stienberg eLisencer Dongle and never will.

From there, newer versions can begin to cut the fat, and truly ‘replace’ older technologies with newer ones. People who need to get into ‘legacy projects’ can still roll back to “Legacy”, get things loaded, and decide to either keep it there, or make adjustments to ‘export it’ again for ‘newer versions and workflows’.

1 Like