Is there a workflow that only uses open file formats and protocols?

[soundmodel]

I got a bit fed up with closed file formats, in the context of multi-software workflows.

I think audio production is pretty simple if one only uses a single vendor's software. Then just use the same formats and "self-contained" or whatever storage methods they offer.

But when one combines projects using several software, then keeping the projects so that each of them remains functional is a bit difficult. Just like with software APIS. Audio files are often unchanged and cross-software. But they can become linked to software via using them in samplers etc.

Then I thought, would it be possible to migrate to a workflow where one's projects are in formats that would essentially be usable using any programs.

Some potential problems:

-MIDI data
-automation data
-...

[soundmodel]

In a deeper sense this is the same old problem of why collaboration between users of different software does not work out.

[BertKoor]

Do you actually do any research before posting? This took me one minute to find.
See https://en.m.wikipedia.org/wiki/RF64
It likely can contain midi and whatever extra data.

Yes, DAW support is lacking...

[chk071]

nevermind

[whyterabbyt]

In a deeper sense this is the same old problem of why collaboration between users of different software does not work out.

evidence required

[Trensharo]

In a deeper sense this is the same old problem of why collaboration between users of different software does not work out.

evidence required

It depends on how one interprets "collaboration" and "work out."

I think for some workflows using different DAWs is fine. For others, not quite. Interchange formats like EDL, OMF and AAF omit 98.6% of everything in a DAW/NLE session. So, you can only really collaborate efficiently if what they include is all you need to get the job done (same as rendering stems).

If the other collaborator needs access to the session data to work efficiently, then you have to agree on a DAW to standardize on.

This is the whole premise underlying "Industry Standards." It's why Media Composer and Pro Tools dominate the high end film market... TOGETHER.

[lfm]

I think ProTools have some good thinking about collaboration, for all that use PT then.

You mark a track as shared, and it goes to cloud, and some collaborator can sync their session.
Something like that. But have not tried it for a real test.

So if you collaborate with a keyboard player, you mark keyboard tracks for shared in cloud.
- keyboard player can sync his project and play his part and update again
- everybody get the new keyboard parts

So guess all parties start off with the same project or close to, and then exchange tracks that others contribute to. And also add new tracks from one collaborator. Guessing a bit here.

[enroe]

... I thought, would it be possible to migrate to a workflow where one's projects are in formats that would essentially be usable using any programs.

Well, you can always exchange audio-wav-files. And you can exchange
midi-files.

[soundmodel]

... I thought, would it be possible to migrate to a workflow where one's projects are in formats that would essentially be usable using any programs.

Well, you can always exchange audio-wav-files. And you can exchange
midi-files.

Yes, the further question is, whether this allows most features to be used.

[BertKoor]

the further question is, whether this allows most features to be used.

1. What features are used most?
2. I'm sure you can figure that out yourself.

[BertKoor]

Wav & midi files are good for exchanging some raw data. For linear time daws & projects at least.

Daws that work with loops & clips have issues exchanging data that way.

Until you realise: a linear time project is the same as a clip-bases project, but it contains just one segment of 4 minutes long.

So the exchange format should support clips, snippets, loops etc in order to cover most territory.

Most "standard" data exchange formats fail in practice because of vendor implementation/interpretation differences, so...

[Dionysos]

The Bitwig developers are working on an open exchange format called DAWproject:

The DAWproject format provides a (vendor-agnostic) way of transferring user data between different music applications (DAWs).

Currently, there is no file-format which is purpose-built for this task. Standard MIDI files can represent note data, but it is often a lower-level representation (no ramps) of data than what the DAW uses internally, which forces consolidation on export. AAF only covers audio and doesn't have any concept of musical-time, which limits it to post-audio workflows . Most plug-ins do allow you to save presets to a shared location, but this has to be done for each instance. What most users end up doing is just exporting audio as stems.

The aim of this project is to export all translatable project data (audio/note/automation/plug-in) along with the structure surrounding it into a single DAWproject file.

It's still early days and whether it'll gain any sort of traction is anyone's guess, but it's nice to see the initiative.

[soundmodel]

TBH I don't understand why vendors would want to support such format, because it'll mean people will be able to jump their product-ship.

OTOH, it could also work the other way around. If there's enough pressure for such format, then vendors could be pushed to implement it or risk people jumping from their platform.

When it comes to things like Pro Tools, then "jumping from their platform" is a very unlikely scenario due to the amount that people have already invested on that platform.

This is just outcomes of closed source software in the first place.

[Trensharo]

TBH I don't understand why vendors would want to support such format, because it'll mean people will be able to jump their product-ship.

This is true.

However, this is quite reductive and there are actual engineering problems that have to be solved in other products that implement this.

OTOH, it could also work the other way around. If there's enough pressure for such format, then vendors could be pushed to implement it or risk people jumping from their platform.

This is unlikely to happen because many users have been locked in by their investments. Not monetary investment, but time investment in gaining proficiency with the software, and body of work investment by having years of projects in that DAW's project format.

Also, people using DAWs like Cubase and Pro Tools - in 2024 - have reasons for being there beyond "no alternatives" and if they haven't jumped to Studio One by now... they probably are not likely to do so for DAWProject.

When it comes to things like Pro Tools, then "jumping from their platform" is a very unlikely scenario due to the amount that people have already invested on that platform.

And Money isn't the only thing people invest.

This is just outcomes of closed source software in the first place.

All formats owned and/or controlled by a specific entity are closed de facto. Even if it's completely F/OSS, everything is still dictated by the development of the application that originated it.

Office Formats are an Open Standard now, but it's still basically controlled by the development of Microsoft's own Office applications.

The minute you make it an open standard, you put the brakes on innovation, which means that specific vendors cannot do anything to make that format function better "for their users." Either that, or it's "Open" in name only. Technically open, but still completely controlled and driven by the company that de facto owns it, and the applications they have developed to utilize them.

A good example of this is in the DAW market. MusicXML is a standard, but I think most of us can agree that it's basically run primarily by MakeMusic and what they decide they want for Finale/Dolet for the market segments they serve.

This is kind of the problem with standards as a whole.

Proprietary Products can be agile. They can be changed to accomodate the changing feature set of the application that uses them. They can change quickly and drastically based on market conditions or market changes. Standards typically are slow and products that depend on them are often limited by them.

Also, none of these standards have proven viability, yet. Companies are throwing things like CLAP and DAWProject out, and people are just expecting DAW developers to come out the next week and make statements on how they're "committed to supporting" them, or something.

[jlgrimes11]

TBH I don't understand why vendors would want to support such format, because it'll mean people will be able to jump their product-ship.

If I have a DAW and know I can export and import a universal DAW Standard, there would be less reason for me to jump ship.

I would only jump ship if a DAW isn't providing the features I need for a certain cost. As long as that is met there is less reason to jump ship.