DAWproject format, exchange between DAWs

+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!

2 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 :pray:t3:
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