It would be great to be able to export the Dorico Project to Cubase Project and vice versatile. In the case of saving/exporting from Cubase, we assume it strips off all audio in they exists in the Cubasis project.
Please note that this is different from Integration of Cubase and Dorico say using ARA, etc. This is very basic compare to that.
Rationale: I know we can use MusicXML but this saves time if you already used VSTi and effects in Dorico or in Cubasis. Almost all of VSTi and effect plugins are shared/accessible in both Cubase and Dorico at least on my iMac.
@chikitin, this has definitely been requested multiple times. Better still, people would like a live link between the two so stems don’t have to be constantly bounced back and forth.
I remember multiple posts in old forum about import/export or linking that came at it from different directions. I wouldn’t argue if you want to consider this a slightly new spin on it but the discussions all came down to the same thing - workflow.
Unless I am absolutely done, and will never make any changes to the score in Dorico ever again - having them link up so that changes in one are immediately reflected live in the other seemed superior to most of us. Less steps, etc. That was the thinking as I recall it anyway. Not that someone might prefer the export you mentioned, just that the topics got conflated.
It would be very difficult to export a Cubase project directly from Dorico, so that’s not something you should expect in the near or medium term. However, making it easier to exchange data between the two applications is certainly something we want to achieve. I think it’s that requirement that is the key, rather than the specific implementation detail of what file format is used to achieve it.
I thought always sharing files and memory between two or more processes would be more difficult.
I suppose to achieve what I have requested ( weaker requirement: import/export of midi/VST tracks along with plugins used on the channel strips when imported to the other program) we can design a new XML format: .SteinbergXML format which is a combination of the regular.MusicXML merged /union with XML elements containing the information from the plugins inserted on each track.
We can make it VSTi -compatible beyond midi compatibility of XML. Something like this!!!
Yeah as Daniel says it doesn’t make sense to have them be interchangable, apples and oranges as it were. Cubase and Nuendo files are interchangable however because they are both much more similiar.
My workflow for game composition is Dorico (scoring) → Cubase (midi/VST) → Nuendo (mastering) → game engine. The connection from Cubase to Nuendo is as easy as opening a cubase file in Nuendo and modifying for mastering, and Nuendo has Game Audio Connect and I’ve written a custom plugin for the game engine using the GAC API. So anyhow it’s all a seamless workflow except the Dorico part, so I’m eagerly looking forward to that connection, however it’s done.
I think Daniel said somewhere that they’re focusing on the Cubase->Dorico rather than the reverse however, so I’m a mite worried about that. That will help the people who go to the Piano roll first to compose, but not those of us more comfortable working from a full score.
@DanMcL What I am proposing would solve issues of many of us. In fact, in 2010, Microsoft came up with Office Open XML format ( .doc → .docx, ppt → pptx, …) to connect it Office product Outlook, OneDrive, Word, Excel, PowerPoint, OneNote, SharePoint, Teams, and Yammer.
If what I proposed to get implemented, it will create a smooth workflow and will be beneficial to clients and developers in long run!
With all due respect, your point has been made. No one is arguing against further integration. As I said above, this has been discussed on and off for a good 3-4 years at this point, and Daniel has acknowledged that more integration is a design goal, at least in the long-term. XML has also been discussed at great length, and Daniel is even a chair member of the consortium (W3C Music Notation Community Group) of developers advancing the next xml spec. I have no doubt that deeper xml integration is in the pipeline, even if it is not imminent. That said, there are xml import/export improvements in each new generation of Dorico.
Yes I know, I’m a software developer I think the best analogy actually is with DCC apps (digital content creation) such as 3D modeling tools, where’s there’s always a multitude of tools in the pipeline. With those the standard is JSON with data on the disk. The Dorico db looks to be similiar sized to fbx models, so that would be a good fit maybe. There’s nothing special with XML otherwise, I’ve been bitten taking that road as many times as I’ve benefited, so in my experience it’s not the one size fits all.
But whatever let’s not joggle their elbows - as Daniel said just talk about what you want and they’ll figure out how to do it.
I’m sure the Doricio Team knows how to program. In addition they and their counterparts know the existing data models on which their programs are based and the challenges they face better than even an experienced outside programmer does.
I’m sure that by now, if not before, the Team(s) are aware of your concern and are giving cooperation between Dorico and Cubase the attention they deem appropriate.
as Daniel says it doesn’t make sense to have them be interchangable …
I don’t think Daniel said that. I hope he didn’t say that. I believe he said it would be quite difficult so don’t expect the “holy grail” solution any time soon. I would hope that anyone who works with both notation and DAWs understands that it absolutely DOES make sense. But making sense and developing code are two different things.
(A perpetual motion machine makes sense, but I’m still waiting.)
I think the best analogy actually is with DCC apps (digital content creation) such as 3D modeling tools, where’s there’s always a multitude of tools in the pipeline. With those the standard is JSON with data on the disk. The Dorico db looks to be similiar sized to fbx models, so that would be a good fit maybe. There’s nothing special with XML otherwise, I’ve been bitten taking that road as many times as I’ve benefited, so in my experience it’s not the one size fits all.