Questions & Answers

Would PreSonus Support a YAML or JSON-based plug-in standard inside or outside the song file?

0 votes
asked Sep 16, 2019 in Instruments and Plug-Ins by brconflict (1,650 points)

Plug-ins need a standard attribute format. When plug-in versions, DAW versions, OS-versions, and bundling mix data are concerned, there's always a risk that future plug-in support will be broken. I'm campaigning to DAW/plug-in developers to join a consortium and agree on a standard format how plug-in settings will be stored. Would Presonus support an open standard for plug-in settings?

But we want to keep plug-in settings information inside the song file.

That would be permissible, so long as that part of the file is readable. For example, at the bottom of the file, there would be a start and end flag for plug-in settings, and a start/end to each plug-in's settings. The plug-in information might be read as it is today, as a "key", but it could also separately be read as an open-standard format for archival or moving/importing to a different OS, DAW, or when plug-in developers don't simply follow an installation/signature standard (YAML?).

Could these settings be saved in one file or a single filer per plugin?

Yes, the idea isn't to dictate where and how the settings are saved, but that the settings are all in the same standard format.

We don't wish to re-code our DAW to support a whole new format

You don't have to. You only need to generate the standardized output, so that, in the file, a file scraper, or human may export the settings and import them into another situation. Your DAW can ignore it, so long as its updated for newly saved changes to the plug-in settings during a session.

How would anyone match up settings from an older plug-in that has been rebranded?

The plug-in developer, assuming they did the right thing and adapted the format, would build into each plug-in the ability to 'interpret' the old settings and allow mapping to the new settings. If a plug-in name changed, there would be an 'alias' history of names listed in the YAML standard format, so that the DAW or plug-in could match the new or older name. If the plug-in developer did not follow the standard, but the DAW did, then the YAML settings of the old plug-in would still be interpreted with a simple tool.

People don't want to scour a massive DAW song file to hunt down the plug-in's settings

This is the clever bit. Since the standard would call for a start and end to the plug-in section, along with a script-readable format for each plug-in, a simple Python or other software-developed tool can read the format and produce the settings in a human-readable format so users could easily see how the settings should be manually mapped to the new plug-in brand/version. Even if the user is moving to an entirely different EQ, it may be possible the settings might be human-interpretable so that the new EQ can be set-up the same way, if not exact.

Where would the standard "dictionary" or "index" of all plug-in information live?

The consortium would elect an authoritative "owner" or set of owners to maintain a catalog. Much like an IP address registry (, or the IANA). Perhaps one DAW or plug-in developer (like Waves or Plugin Alliance or both) would volunteer to own the catalog. That said, the catalog will be shared as to increase survivability, and to prevent one catalog owner from charging high prices for the listings.


The consortium web-portal API could be created that any scripting tool might pull down an archived version of any plug-in on the market over time, and display a graphic representation of the plug-in along with its settings! Talk about making plug-ins future-proof!

The future of DAWs and plug-ins isn't going away anytime soon, but what also isn't going away: change. Where old-school studios are all that's left to load up old Led Zepplin sessions from analog, we don't want to see the future of digital domains suffer the same archival challenges. Where the analog domain relied on session notes, we don't have useful session notes for the digital domain, since we rely heavily on the software's archival recoverability (too much).

Thanks for taking the time to read this!

Please log in or register to answer this question.