Skip to content

Plug in launch checklist

Jump to bottom
p0nce edited this page Jan 15, 2025 · 30 revisions

Pre-launch list

There are many things to do before releasing a brand new plug-in. Here is an example list to help being organized.

UX

  • Have you used your own plug-in extensively?
  • Has your plug-in useful presets? (See Adding Presets)
  • Have you tuned parameters range?
  • Are the non-trivial points explained somewhere? (manual, tutorials, videos...)

Visuals

  • Is the feedback helpful or distracting?
  • Have you checked on various screens and different lighting conditions?

QA

  • Did you test your plug-in in a real song?

  • Did you send the plug-in to QAs?

  • Would the plug-in be useful to you? To the QAs?

  • Did you implement a tailSizeInSeconds override yet? Don't leave the default one!
    Caution, as it is very easy to grossly underestimate this value.

  • Have you checked reported latency with the latency-check tool?

  • Does your plug-in work in mono? It's nice for being listed in Logic.

    Protocol to instantiate mono plug-in in Orion:
 - build a plugin that does only 1-1, disable 2-2
 - instantiate mono synth (or mono sample in supposedly newer DAW)
 - insert as insert

  • Does your plug-in work in a sampling-rate as low as 11050 Hz? This is important for auvaltool validation.

  • If you were using live-reload, have you disable Wren live-reload (with filesystem path) for release?

  • (for an effect plug-in) Does your plugin support 1-1 or 1-2? Else Logic users may have trouble finding it to instantiate.

  • (for a new plug-in) Are you using all the newest futureXXX Options? This will help maintenance later. (See Options)

  • Typical failure point: Not working in macOS 10.12 to 10.14

  • Typical failure point: Crashing when augmenting buffer size from 64 to higher.

  • Typical failure point: Not launching on Linux

  • Typical failure point: Not launching on Rosetta

  • Typical failure point: Not launching on arm64

  • Typical failure point: Not launching on Windows 32-bit (if needed)

Performance

  • Have you profiled and optimized your plug-in DSP?
  • Have you profiled and optimized your plug-in UI?
  • Does your plug-in detect silence to speed up things in DSP? (Warning: this is usually very hard to implement correctly)
  • Have you tuned maxFramesInProcess() return value? (512 is often a good start)
    It changes CPU usage, and memory usage. You can use process or bench to find your favourite value. In VST3, allows to modulate parameters faster.
  • Are you sure that no PBR widget is updated on its PBR layer at 60 FPS?
    • you can use Raw widgets for fast animation instead (consider dplug:canvas)
    • or widgets that renders to both Raw and PBR layers, but only update the Raw layers with setDirty(UILayer.rawOnly)

PR

  • Have you written a KVR PR?
  • Have you written a newsletter entry?
  • Have you written a blog entry?
  • Have you made a launch video?
  • Have you made sound examples?

Legal

  • Have you reproduced copyright notices that must be redistributed in a binary redistribution? (those can go in the user manual or licence)
  • (VST2) Do you have the Steinberg Agreement to release VST2?
  • (VST3) Do you have the Steinberg Agreement to release VST3?
  • (AAX) Do you have the Avid and PACE authorizaton to release AAX?
  • Do you have a CommonMark licence file for inclusion as "licensePath"?
    • Note that dplug-build allows the following macros in license files: $VENDORNAME, $PLUGINNAME, $PUBLICVERSION, $CURRENTYEAR.
Clone this wiki locally