Is there a workflow that only uses open file formats and protocols?
-
- KVRian
- Topic Starter
- 1097 posts since 28 May, 2010 from Finland
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
-...
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
-...
-
- KVRian
- Topic Starter
- 1097 posts since 28 May, 2010 from Finland
In a deeper sense this is the same old problem of why collaboration between users of different software does not work out.
- KVRAF
- 15279 posts since 8 Mar, 2005 from Utrecht, Holland
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...
See https://en.m.wikipedia.org/wiki/RF64
It likely can contain midi and whatever extra data.
Yes, DAW support is lacking...
We are the KVR collective. Resistance is futile. You will be assimilated.
My MusicCalc is served over https!!
My MusicCalc is served over https!!
- Beware the Quoth
- 33178 posts since 4 Sep, 2001 from R'lyeh Oceanic Amusement Park and Funfair
evidence requiredsoundmodel wrote: ↑Tue Sep 19, 2023 2:12 pm In a deeper sense this is the same old problem of why collaboration between users of different software does not work out.
my other modular synth is a bugbrand
-
- KVRian
- 633 posts since 29 Dec, 2019
It depends on how one interprets "collaboration" and "work out."whyterabbyt wrote: ↑Tue Sep 19, 2023 7:13 pmevidence requiredsoundmodel wrote: ↑Tue Sep 19, 2023 2:12 pm In a deeper sense this is the same old problem of why collaboration between users of different software does not 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.
If I said you are blocked, I won't see your posts. Please kindly refrain from quoting or replying to me.
"Notifications for Nothing" are annoying. Blocking me in return is a good way to avoid this.
-
- KVRAF
- 6427 posts since 22 Jan, 2005 from Sweden
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.
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.
-
- KVRAF
- 2590 posts since 19 Mar, 2008 from germany
Well, you can always exchange audio-wav-files. And you can exchangesoundmodel wrote: ↑Tue Sep 19, 2023 1:27 pm ... 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.
midi-files.
free mp3s + info: andy-enroe.de songs + weird stuff: enroe.de
-
- KVRian
- Topic Starter
- 1097 posts since 28 May, 2010 from Finland
Yes, the further question is, whether this allows most features to be used.enroe wrote: ↑Fri Sep 22, 2023 11:46 amWell, you can always exchange audio-wav-files. And you can exchangesoundmodel wrote: ↑Tue Sep 19, 2023 1:27 pm ... 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.
midi-files.
- KVRAF
- 15279 posts since 8 Mar, 2005 from Utrecht, Holland
1. What features are used most?soundmodel wrote: ↑Sat Sep 23, 2023 5:36 am the further question is, whether this allows most features to be used.
2. I'm sure you can figure that out yourself.
We are the KVR collective. Resistance is futile. You will be assimilated.
My MusicCalc is served over https!!
My MusicCalc is served over https!!
- KVRAF
- 15279 posts since 8 Mar, 2005 from Utrecht, Holland
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...
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...
We are the KVR collective. Resistance is futile. You will be assimilated.
My MusicCalc is served over https!!
My MusicCalc is served over https!!
-
- KVRian
- 588 posts since 26 Sep, 2007
The Bitwig developers are working on an open exchange format called DAWproject:
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.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.
-
- KVRian
- Topic Starter
- 1097 posts since 28 May, 2010 from Finland
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.
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.
-
- KVRian
- 633 posts since 29 Dec, 2019
This is true.soundmodel wrote: ↑Thu Mar 28, 2024 10:32 am 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.
However, this is quite reductive and there are actual engineering problems that have to be solved in other products that implement this.
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.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.
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.
And Money isn't the only thing people invest.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.
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.This is just outcomes of closed source software in the first place.
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.
If I said you are blocked, I won't see your posts. Please kindly refrain from quoting or replying to me.
"Notifications for Nothing" are annoying. Blocking me in return is a good way to avoid this.
-
- KVRist
- 93 posts since 5 Jan, 2008 from Atlanta
soundmodel wrote: ↑Thu Mar 28, 2024 10:32 am 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.