5 ms·

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

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).

swatcoder 2y ago
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.
- PaulDavisThe1st 2y ago
  That said, you can import PT sessions into other DAWs without plugins and that can be quite useful sometimes.
- textadventure 2y ago
  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.
  - swatcoder 2y ago
    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.
    - textadventure 2y ago
      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.
    - bravura 2y ago
      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/reverse_engineering_serums_fxp_files/ https://www.reddit.com/r/edmproduction/comments/69hxa7/rever...
  - PaulDavisThe1st 2y ago
    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.,
- webprofusion 2y ago
  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.
  - ulbu 2y ago
    Do you suggest the assumption we don’t care about plugin state? just bounce and batch import in that case.

swatcoder 2y ago

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.

PaulDavisThe1st 2y ago
That said, you can import PT sessions into other DAWs without plugins and that can be quite useful sometimes.
textadventure 2y ago
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.
- swatcoder 2y ago
  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.
  - textadventure 2y ago
    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.
  - bravura 2y ago
    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/reverse_engineering_serums_fxp_files/ https://www.reddit.com/r/edmproduction/comments/69hxa7/rever...
- PaulDavisThe1st 2y ago
  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.,
webprofusion 2y ago
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.
- ulbu 2y ago
  Do you suggest the assumption we don’t care about plugin state? just bounce and batch import in that case.