3 ms·
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
by 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 agoRight, 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 agoAlso, 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...