+1 this would be a fantastic feature
1 Like
Oh I hope Cubase implements this! For anyone who is wondering just how hard it is to implement⌠it took ONE programmer approximately 5 days to make a converter that takes DAWproject and converts it to Reaperâs .rpp format, so it appears that they did a good job making the DAWproject format, or else it probably wouldâve taken a lot longer.
Oh man I really really hope this happens, it would be glorious!
3 Likes
Just to add my voice to this, the existing methods are not sufficient and this feature would be greatly appreciated and enable me to use Cubase more than I already do.
I use both Bitwig and Cubase, but in different ways and for mostly live performance reasons. I often find myself having to make the choice at a certain stage in a project between staying in one DAW or the other as moving back and forth becomes cumbersome and unreasonable.
A standard like this would go at least some way to relieving those issues and would allow me to continue using Cubase within the production process for longer, even if itâs only a partial solution.
Genuinely donât understand the thoughts that Steinberg shouldnât be looking at this. If nothing else (and there are dozens of reasons I can think of) wouldnât it be better to be part of it from the beginning and bring their knowledge and expertise to steer it too a better place?
Fair enough, but your list of priorities is not the same as other peopleâs, for me this would me huge.
Itâs an open source project on github, so even if Steinberg decide to not get involved, thereâs still a chance this could be done someone out there 
I see that most of it is done with .vstpresets, .fxp, audio files and .XML which is what Cubase functions with, so it shouldnât be too difficult of a task.
2 Likes
I have Cubase (13), Studio One Pro 6.5.1, Bitwig (latest) and Repaer (latest).
I would love to take any song from any of these DAWs into the other during the recording, arranging & editing stage whilst mixing in my DAW of choice.
For the time being Reaper does not have DAWproject imbedded yet there is a free tool that opens a Reaper song (.rpp) and writes it back out to DAWproject format and does the reverse too. With one caveat, Studio One does not import a DAWproject file from Reaper if each audio clip does not start at 1:1 and is not contiguous, even though Bitwig will import those type of tracks correctly. Presonus has been notified of this issue/bug.
1 Like
Just tried it. Having just taken a very complicated studio one project with 74 tracks that used third party vstâs across midi and audio tracks into bitwig⌠worked great!
ssl plugins, softube console one plugins, uad plugins etcâŚ
It even kept my folder and color settings⌠oh myâŚ
Iâll upgrade both my nuendo and cubase base versions (Iâm one release behind) when they put this in, for sureâŚ
Iâve got projects that goes back many years from studio one, cubase and nuendo. I jumped around a lot back then to grab new daw featuresâŚlol
After reading this post went back into the converted project, side chains were imported in, fx channels all created, all plugins where openable, bus channels were created, bus channel sends were created⌠Iâm mean it brought the whole thing over, gold clip, Lava, dynOne SSL fusion plugins etc⌠everything that I used. I wasnât using any native studio one plugins⌠since i jump between daws, my stuff is always in 3rd party that runs across all.
Granted DSP utilization in bitwig was 100% at times when playing the imported project and could not run the project without stutters at times, but that wasnât the import. Its a complicated project and studio one seems to be a little better optimized for dsp utilizationâŚ
There is a user-contributed open source tool to convert Reaper to or from DAWproject.
I am interested in this because I work with several venues that have digital boards capable of tracking to any DAW, and they would like to be able to offer this service to the client. But they donât want to have to maintain 10 different DAWs. It would be nice if they could have a single DAW for all events. At the end of the event, they could export the project to DAWproject format for the client.
Of course, that is only goof for S1, Bitwig, and Reaper today. Hopefully Cubase, ProTools, Logic and others will get on board soon.
1 Like
+++++++++++++1 Yes that DawProject Format is perfect for collaboration
1 Like
Just to follow up. Studio One now imports that Reaper project, exported via ProjectConverter, that had non contiguous clips correctly.
Now if Steiney would get on board, Iâd be a happy camper.
One aspect that isnât usually mentioned is that this should be a solution, not just for moving/collaborating across different DAWs. It also is a solution for collaborating across different releases of the same DAW. This may not be an issue much with Cubase, but it is a definite drag with StudioOne. I have often found myself forced to by a S1 upgrade that I end up using for only one client/project.
Most DAWs are backward compatible. That isnt really a problem. Cubase, Studio One. Bitwig, Sonar, Samplitude, Digital Performer, etc. etc. Are all reliable.
I think Ableton Live is unique in its ability to flub this on occasion.
I guess for going backwards it could be useful (e.g. v6 â v5), but I donât think that is a priority scenario. Most DAW upgrades arenât breaking the bank, and there are sales all the time.
It is a priority for me. There have been 3 times now that I have been forced into upgrades to S1 because a collaborator had a newer release higher than mine. And there is no way to SaveAs an earlier release. So either I have to keep several versions on my computer, or else I force the next person into upgrading.
True, it is not a fortune, but it is really annoying. It is freaking 2024, for cryinâ out loud. The software ought to be designed such that if you open a file created by a newer version, it opens, and just ignores the elements that were not supported in the earlier release. 99.99999% of the cases, I am not using the newest features, so there should be no issue with upward or downward compatibility. That should not force upgrades.
Honestly, I donât know if this is an issue with Cubase. It has only happened to me with S1 collaborators.
Steinberg has been pretty good in this respect over the decades.
Smaller/older versions can usually at least open stuff built in larger and newer versions.
In some cases, like with Dorico, the smaller Elements and SE versions can sometimes even open huge projects made with the big Pro editions (enough to play it back, but you usually canât add new stuff using the power features, or power tweak the existing stuff). So, you could theoretically build a massive, unlimited score in Pro, and then share it with Elements users so they could at least see/play/print the thing, and do minor edits to the âexistingâ score/parts. I think the same holds true for Cubase, at least in terms of getting the raw track and automation data loaded into the project view.
Opening older projects made with a version older than your installation is usually pretty solid.
Opening a project made with a newer version, Say Cubase 13, in an older version, say Cubase 11, usually goes pretty well too! Newer versions constantly change what they can do to a track or lane, but the lane data itself doesnât change much if any with new versions. If they do add more fields and whatnot to the track data, older versions just ignore it.
With any DAW, I think a bigger problem can be when the various plugins you have installed are in a different state/version than the last time you saved that project. While the track data itself is perfectly fine, a host might struggle making the right connection, with the right plugin. Provided the plugin ID itself hasnât changed, itâs possible plugins can behave or work differently over time. Occasionally you might even find one that chokes because the preset snapshot no longer works with the different plugin version (rare, but possible, and usually the fault of the plugin, not the host).
Steinberg stuff, from Cubendo to Dorico have long been good at least opening a project, and if things are radically different between sessions, youâll usually get pop ups and options to either assign different plugins/ports/etc, or âpark the end pointsâ until you decide what to do next.
I.E. Maybe you made a project years ago with a mostly VST2 setup, and now youâve upgraded to all VST3 versions of your plugins. Maybe the host canât figure out where to point a trackâŚso youâd manually point it to a replacement end point of what you had way back when you last saved the project.
I.E. Maybe two years ago you had a different MIDI controller, or perhaps even the same one, but for whatever reason the MIDI ports are named differently now, or in a different order. Etc. Again, youâll get a pop up asking what youâd like to do about the âmissing portâ.
Of course system settings can change over time, and projects might behave differently (even when loading the project in the same version it was made with, but on a different computer, using a different audio interface, or with different default settings). Still, the project itself is gonna load up, with your actual âtrack/automationâ data just like you last left it.
The track and automation data itself tends to remain pretty solid all this time.
All the other stuffâŚplugin changes, kit that was plugged in, audio interface changesâŚwell, In my experience that stuff can be problematic with ANY DAW platform.
Iâd always expect some degree of manual fiddling to get older projects working.
If thatâs something you want to avoid, I can suggest thisâŚ
Install a docking bay or something, that makes it simple to swap system drives without taking your whole rig apart.
When youâre planning to archive a project, or make significant system/software upgrades, Sysprep your actual system drive. This puts as much as possible into the OS driver store, so if you plug the drive into a different machine someday, itâll hopefully still boot right up and get you working nearly âexactlyâ like you left off without much more than spending a bit of time refreshing low level system drivers and such. Also keep relevant documentation on the root of the old drive as to what your system was like when you pulled it. These days youâll probably need to factor in some other âsecuirtyâ stuff during the sysprep to make it possible for it work in any other system than the one the image was built with. For Windows there are a number of diagnostic commands thatâll log everything about your system in a fairly human readable format. The purpose of this is if you need it 30 years later, you can figure out what starting point would be best to put together a system to plug the thing into and have it actually boot up and work again.
Release all your software keys that are stored on the system drive. Stuff like iLok, Steinberg âsoftâ eLicenser stuff (better put that stuff on a dongle before it is too late if you want might need it after 2025), Steinberg Activation Center, Native Access, etc. Youâll want to have them free and ready, because a new system drive can break most of these licensing systems.
Pull the drive, and set up a whole BRAND new system drive before upgrading/changing stuff.
You have options on building new system drives. You could âcloneâ the old one and pick up where you left off, or start with an entirely FRESH installation of all the âlatest and greatestâ stuff.
Once you have the new drive chugging as it should, reactivate/register your all your software that needs it.
The idea here is, umpteen years into the future, in theory, you could just plug those old drives back in, and pick up really close, if not EXACTLY as you left them. In Windows World, chances are good you could even plug the old drive into a much newer computer, get it booted, update some system drivers and stuff, and itâll work pretty much like you left it all that time ago.
If you do take up an archival plan that includes the whole system drive, be mindful of how âinstruments and pluginsâ are installed. Itâs probably better to preserve as much as that as you can on the system drive too. If you use some of those huge 3 terabyte instrument libraries that could be challenging to archive it all as a working setup on the system drive, but at least in that case youâd only need to update a few plugins to your latest version, and carry on with your old DAW in pretty much the exact same state as you last left it.
In Steinberg world, more often than not, you wonât need to boot from/roll back to the old system drive, and newer versions can just import your older projects in a solid and usable state. ButâŚthereâŚareâŚtimesâŚ
Storage media is relatively inexpensive these days, so itâs worth considering just pulling drives and making new ones when doing significant upgrades. Simpler and less time consuming than trying to âback stuff up as images on a huge archival driveâ and ârebuildingâ a zillion little things just to work with older projects.
Thanks for all that. I think Steinberg is doing about as much as anybody could realistically hope for in terms of collaboration across releases and package levels. In the case of S1, I believe it simply refuses to even try to open a project that was created in a later release.
Iâve installed a new GPU and it broke everything. Had to get all of my iLok licenses reset because there is no way I was going to rip out the new GPU just to do that.
You know how annoying it can be just to install these components on some MOBO/Case combinations when things donât quite align perfectly and you have to manually hold things in place (with help) while you tighten screws, etc.
Never mind adjusting cable ties to accommodate different sized components, etc.
I just contacted iZotope/UVI/etc. and got them to reset.
Iâm still down one Arturia activation slot because of that, Lol.
I also had to get it down when I added an additional PCIe SSD to my system. Only the PCIe. None of the SATA SSDs triggered this. It wasnât even the system drive. It was just an additional drive to use as a dedicated cache/media drive for Resolve Studio.
So, these things can be very finicky regarding what types of hardware changes they will accept before deactivating and/or orphaning your licenses.
Some vendors have activation limits with no way to reset them aside from contacting them and asking them to do so.
1 Like
I buy every new steinberg release of Cubase pro and the person that mixes me moved to studio one. I have to move to studio one to continue working with my mix engineer, id much rather stay in Cubase and use a project file converter tool like this. Please implement.
2 Likes
This would be excellent for moving songs from S1 to Cubase and vice versaâŚ
Also, collaboration, sending project for mixing and avoid multiple stem exports etcâŚ
Come on Steinberg, very good feature for 13.5 update
I am not putting Reaper or its users down in any way but I have never come across a Pro Studio with Reaper.
It is an option at ours but in all the years we have had it as an available option it has never been requested/booked for a session.
It would be more helpful for professional studios if something like this was available for Cubase to Pro Tools.
Can not see Avid ever allowing it to the other way but thats okay as the general workflow is compose in Cubase then move to Pro Tools to mix and/or master.
Both DAWs have functions that are better than the other.
We got our wish, this is a feature in C14! Thanks Steinberg.