A few questions -
- Is there anything like an Edit Decision List (EDL) that's common in video editing software?
- As this supports Ableton Live - how would it handle exporting Session View clips from Live to a DAW that doesn't do Session clips - which can be triggered manually or programatically but due to this non-linear nature, don't really "live" anywhere on a timeline?
- Does this include automation, internal/VST plugin parameters/automation, tempo/beat subdivision, and key changes?
The audio world (which is a superset of the DAW world) has nothing remotely like standards for session files. The closest thing you could maybe name is AAF, which is really from the broadcast world, and is an abomination (it carries every hallmark of design-by-committee that you could ever list).
The good news is that people rarely move sessions from DAW to DAW, and on the occasions when they need a workflow that revolves around "stems" (1 audio file per track) generally gets the job done.
Pretty interesting. If you add support for Pro Tools and Logic Pro, you'll have the attention of industry pros. Others important DAWs to consider supporting are Studio One, Cubase, Nuendo, Adobe Audition (this one should be easy, their session files are basically XML).
For as much as it does work, this works because it translates project formats between VST hosts, where you might run the same plugin that will be able to read its own data payload in the output project.
But neither ProTools nor Logic supports those VST plugins, and the embedded data for AAX and AU plugins are each encoded differently. There's no guarantee -- and generally slim likelihood -- that you could coax an AU or AAX version of some plugin to read data written by its VST sibling, and likewise any other combination. Even if you could pull it off in some cases, you can't get it consistent enough for professional use.
This sure to be a super useful project for some people, but it can only reach so far.
I don't see why it should be untenable. You can have equivalent parameters on identical plugins regardless of the plugin protocol is coded in, and the same plugin in AU could produce a signal that nulls out to the exact same processing applied on the same plugin in AAX or VST versions. So there has to be a way to translate between the two. And it's a very worthwhile problem to solve, perhaps the most important one when it comes to converting sessions between DAWs.
Plugins encode their state as a combination of automation parameter values managed by the DAW and opaque binary blobs for everything else.
In the general case of professional-grade use, you can't assume that two versions of the same plugin will handle any of those in compatible ways. In some cases they might, but there's nothing that guarantees it and many known cases where it doesn't hold.
And speaking to your broader point of "there has to be a way to translate between the two" -- this is likely true in a formal sense, but not a practical one. If it was 2030 and your job was to revive some dead AAX plugin and open its projects in some new one that you were writing for AUv4, you could do a whole bunch of bespoke debugging and forensics to make it happen. But there's no solution for the general case, as applies to a converter like this.
Also, there is at least one synth (Serum) where the developer declined to document the file format of the presets:
"I reached out to Steve through Xfer's forum and he was prompt and helpful. Unfortunately, the .fxp file format is completely dependent on the source code, and he can't release a spec for it without making the code open source. Which probably isn't happening any time soon."
VST plugin state is a binary blob owned by the plugin (the host's job is merely to read/write from/to disk when required). This is because the plugin is free to have hidden state that the host does not know about.
AAX and VST and AU [ and other ] plugin formats do not require any kind of interoperability of the way their plugin state is serialized and deserialized. Pulling the VST binary blob from a session in one DAW and giving it to the "same plugin" in AAX format running in ProTools is not even a thing.
Not only that, but even identifying "the same plugin" is far from trivial because different plugin formats use entirely different models for identification. The fact that the session in DAW A uses a VST format plugin identified as "XXXX-YYYY-ZZZZ" gives you no clue how to identify the equivalent plugin in LV2 or AAX or AU formats.,
Ah, I see, so it's a matter of not being able to get the data out of the plugin in the first place, in a way that's usable outside the DAW.
So, even if it was somehow possible say, to reverse engineer one specific plugin across AAX, VST and AU, you'd still be no closer from solving true cross-compatibility from AAX, VST and AU in general.
The assumption here is that we care about plugin state. I have audio projects with minimal plugins and the first job is converting the track structures (including cropped/transformed wavs), plugins are replaceable in many cases but it perhaps depends on the genre and composition style you are targeting.
Interesting (and cool) to see some support for tracker files in this. Probably a niche ask, but I would love to find a tool that can reliably convert files saved from MED/OctaMED/SoundStudio from the Amiga days. libopenmpt does support some older files of this type (and you can compile ffmpeg with libopenmpt support) but the stash I have of my own music from back in the day are newer and I have been unable to find anything to convert them short of getting OctaMED running again.
Wishlist: Akai MPC3 - especially as the brand new 3 format has a single track order for all sequences in a project, thus making it functionally compatible with most DAWs.
This is so cool and actually was something I was thinking of building for a while! Would love a write-up of how the file formats was reverse engineered.
Interesting, will have to check this out.
A few questions - - Is there anything like an Edit Decision List (EDL) that's common in video editing software? - As this supports Ableton Live - how would it handle exporting Session View clips from Live to a DAW that doesn't do Session clips - which can be triggered manually or programatically but due to this non-linear nature, don't really "live" anywhere on a timeline? - Does this include automation, internal/VST plugin parameters/automation, tempo/beat subdivision, and key changes?
The audio world (which is a superset of the DAW world) has nothing remotely like standards for session files. The closest thing you could maybe name is AAF, which is really from the broadcast world, and is an abomination (it carries every hallmark of design-by-committee that you could ever list).
The good news is that people rarely move sessions from DAW to DAW, and on the occasions when they need a workflow that revolves around "stems" (1 audio file per track) generally gets the job done.
Pretty interesting. If you add support for Pro Tools and Logic Pro, you'll have the attention of industry pros. Others important DAWs to consider supporting are Studio One, Cubase, Nuendo, Adobe Audition (this one should be easy, their session files are basically XML).
That's largely untenable because of plugins.
For as much as it does work, this works because it translates project formats between VST hosts, where you might run the same plugin that will be able to read its own data payload in the output project.
But neither ProTools nor Logic supports those VST plugins, and the embedded data for AAX and AU plugins are each encoded differently. There's no guarantee -- and generally slim likelihood -- that you could coax an AU or AAX version of some plugin to read data written by its VST sibling, and likewise any other combination. Even if you could pull it off in some cases, you can't get it consistent enough for professional use.
This sure to be a super useful project for some people, but it can only reach so far.
I don't see why it should be untenable. You can have equivalent parameters on identical plugins regardless of the plugin protocol is coded in, and the same plugin in AU could produce a signal that nulls out to the exact same processing applied on the same plugin in AAX or VST versions. So there has to be a way to translate between the two. And it's a very worthwhile problem to solve, perhaps the most important one when it comes to converting sessions between DAWs.
Plugins encode their state as a combination of automation parameter values managed by the DAW and opaque binary blobs for everything else.
In the general case of professional-grade use, you can't assume that two versions of the same plugin will handle any of those in compatible ways. In some cases they might, but there's nothing that guarantees it and many known cases where it doesn't hold.
And speaking to your broader point of "there has to be a way to translate between the two" -- this is likely true in a formal sense, but not a practical one. If it was 2030 and your job was to revive some dead AAX plugin and open its projects in some new one that you were writing for AUv4, you could do a whole bunch of bespoke debugging and forensics to make it happen. But there's no solution for the general case, as applies to a converter like this.
Also, there is at least one synth (Serum) where the developer declined to document the file format of the presets:
"I reached out to Steve through Xfer's forum and he was prompt and helpful. Unfortunately, the .fxp file format is completely dependent on the source code, and he can't release a spec for it without making the code open source. Which probably isn't happening any time soon."
https://www.reddit.com/r/edmproduction/comments/69hxa7/rever...
Right, I see. So we are basically stuck with this problem until maybe perhaps most plugin and DAW devs support CLAP or something like that.
VST plugin state is a binary blob owned by the plugin (the host's job is merely to read/write from/to disk when required). This is because the plugin is free to have hidden state that the host does not know about.
AAX and VST and AU [ and other ] plugin formats do not require any kind of interoperability of the way their plugin state is serialized and deserialized. Pulling the VST binary blob from a session in one DAW and giving it to the "same plugin" in AAX format running in ProTools is not even a thing.
Not only that, but even identifying "the same plugin" is far from trivial because different plugin formats use entirely different models for identification. The fact that the session in DAW A uses a VST format plugin identified as "XXXX-YYYY-ZZZZ" gives you no clue how to identify the equivalent plugin in LV2 or AAX or AU formats.,
Ah, I see, so it's a matter of not being able to get the data out of the plugin in the first place, in a way that's usable outside the DAW.
So, even if it was somehow possible say, to reverse engineer one specific plugin across AAX, VST and AU, you'd still be no closer from solving true cross-compatibility from AAX, VST and AU in general.
The assumption here is that we care about plugin state. I have audio projects with minimal plugins and the first job is converting the track structures (including cropped/transformed wavs), plugins are replaceable in many cases but it perhaps depends on the genre and composition style you are targeting.
Do you suggest the assumption we don’t care about plugin state?
just bounce and batch import in that case.
That said, you can import PT sessions into other DAWs without plugins and that can be quite useful sometimes.
Interesting (and cool) to see some support for tracker files in this. Probably a niche ask, but I would love to find a tool that can reliably convert files saved from MED/OctaMED/SoundStudio from the Amiga days. libopenmpt does support some older files of this type (and you can compile ffmpeg with libopenmpt support) but the stash I have of my own music from back in the day are newer and I have been unable to find anything to convert them short of getting OctaMED running again.
I'll try this out when I get home. I have a bunch of .flp files that are not very complicated, and I'd like to get them to Ableton. Very cool project!
Wishlist: Akai MPC3 - especially as the brand new 3 format has a single track order for all sequences in a project, thus making it functionally compatible with most DAWs.
This is so cool and actually was something I was thinking of building for a while! Would love a write-up of how the file formats was reverse engineered.
Great idea! Would love something that converted old Cubase .all and .cpr projects to other formats (very hard to reverse engineer though).
Have added DawVert to https://github.com/webprofusion/OpenAudio
Great. I was just looking for something to move a project from Bitwig to Ableton. I'll test this out!
this is cool. what does it do with instances of stock instruments/effects that don't exist as plugins?