4 ms·

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 plug

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.,
- textadventure 2y ago
  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.

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

textadventure 2y ago
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.