Publishing

The directory and its submission flow are proposed, not shipped. This page describes the intended lifecycle so tools can be built to fit it.

Publishing puts your tool at a live URL with a browser playground anyone can hit without an account and a download button for the plugin. Getting there is a checklist, a review, and then a versioning discipline.

What you must supply

Five things, and the submission is refused — politely, with the missing item named — until all five are present.

Metadata. A name, a one-line tagline, a category (Instrument or Fx, the same two values plugin.config.json accepts), and tags. The tagline is what appears in the directory listing, so write the sentence someone scanning a grid needs, not the sentence you would open a README with.

A license. Any OSI license, or a commercial one if you are selling. See Licensing for what each choice implies.

At least one screenshot. Of your actual UI, at a size that survives being shown at card width.

A demo preset. The playground loads it on first visit, so it should be the setting that makes the best case for the tool in about four seconds. This is the single highest-leverage asset you provide and it is routinely the one people phone in.

A source link, if the tool is open.

What review actually checks

A human loads the tool and listens to it. The bar is not taste — it is that the tool does not blow up a speaker or a CPU. Concretely: no output that clips catastrophically at default settings, no runaway feedback reachable from the parameter ranges you declared, no denial-of-service CPU cost per block, and a plugin that loads and unloads cleanly in a host.

Usually a day or two. A rejection names the specific thing to fix.

Assets and the playground

The playground runs your web build with the demo preset loaded. It is the same bundle you deploy and the same bundle embedded in the plugin, so anything that works in one works in the others — which also means anything that assumes a CDN or a service worker breaks in all three.

Ship a reasonable web app and you ship a reasonable plugin: a small effect's compiled kernel and generated shell are tiny, and your UI bundle is most of the binary weight.

Versioning

version in plugin.config.json is the published version, and updates are submitted the same way as the first release. Two rules keep existing users working.

Never reorder or remove parameters. bridgeParams assigns automation indices by array position, and those indices are what a DAW stored in a saved session. Reordering silently reassigns someone's automation lanes to the wrong knobs. Append new parameters at the end.

Never change the plugin id. The VST3 class UIDs are derived deterministically from it, so changing the id makes the new build a different plugin as far as every DAW is concerned, and existing sessions will report a missing plugin rather than upgrading.

Changing a parameter's range is legal but it is a real change: existing saved normalized values will denormalize to different engine values. If you must, do it on a major version and say so in the changelog.

Deprecation

Deprecating removes a tool from the directory listings and search while leaving existing installs and existing session recalls working. That is the point — a session someone rendered a record with should still open in five years.

Mark a tool deprecated when you have replaced it, and point at the replacement. Do not delete: a tool disappearing out from under a saved project is the one failure mode that makes people distrust a plugin ecosystem permanently.

You are never locked in

Every published tool is a self-contained unit — kernel, schema, UI bundle, manifest — and can be self-hosted. The SDK, CLI, contracts, and example tools are open; the hub services (accounts, payments, hosting, review) are the business. If the directory ever stops being useful to you, what you built keeps working somewhere else.