Plugin Development Best Practices (From A User's Perspective)

[Funkybot's Evil Twin]

I see common trends popping up in forums time and time again about things like missing features, GUI issues, non-ideal implementation of presets, etc. Some developers have come up with interesting solutions to some of these issues. This is my feeble attempt at the start of a "best practices" type document. The idea is that a developer could come here for ideas about how to implement a particular feature in a way that will be satisfactory to most users.

Note: there's no one plugin I own that has all of these features, and I doubt that there's any plugin where all items on this list would even be applicable to. Also, some items on this list aren't even things that effect me (I have 20/20 or better vision for example), but are again, meant to address complaints or issues that come up time and time again. This is also meant to be the "ideal state," so it obviously doesn't factor in the development effort/costs that would go into building all this stuff.

I'd also be curious if developers or users had more ideas, or debated some of what I listed here. It would be great to have a living document that could be used for reference.

Plugin Naming/ID’s
1. Plugin names should never include the name of the company (or plugin suite) as a prefix
2. Names should be short and clear so they are legible within the effects bin of most hosts - let’s say 20 characters or less
3. Clear abbreviations in a plugin name are acceptable
4. If a plugin is updated in a way that compatibility may be broken, a new plugin ID should be issued to ensure the old version can live alongside the new version and project compatibility is maintained
5. When #4 occurs, the new version should be given an updated name/version number to help users identify the new version going forward (example: “Plugin” could become “Plugin 1.5”)

GUI
1. Plugin developers should avoid bright white backgrounds
2. Plugin developers should assume their user base may not have perfect vision and might have difficulty reading small fonts, or knob positions (i.e. text should always be clearly legible, values of knobs/faders/etc should be clear also)
3. Plugin developers should avoid dark shadows, or bright distracting lights
4. Plugin developers should avoid unnecessary borders where not adding value (example: wood panels, a fake room in the background)
5. UI’s should be no larger than necessary with empty space being avoided
6. Multiple UI sizes should be provided
7. UI’s should include a strong amount of contrast (i.e. avoid grey on black, and similar low contrast items)

Mouse Behavior
1. Up/Down mouse movements should move knobs by default
2. Options for circular mouse movement may be provided
3. Holding down shift as a modifier should allow for fine control of parameters

Keyboard (Typing) Behavior
1. Users should be able to enter values manually into their plugins
2. Alt, Ctrl (Cmd on Mac), and Shift should be utilized as modifiers where appropriate

A/B
1. Plugins should include A/B options where possible
2. It should be easy to copy settings from A into B and vice versa
3. There should be an easy way to clear settings from A or B
4. Both A and B settings should be retained within presets for later recall

Undo/Redo
1. Larger, more complicated plugins, which may benefit from undo/redo functionality to protect users from mistakes should include this functionality

Oversampling/High Quality Modes
1. Plugins with Oversampling or other High Quality modes should allow for these to be toggled for lower latency and/or improved CPU performance
2. Users should have the ability to set different settings for playback and render
3. Users should be able to copy these settings to other instances of the plugin
4. Users should be able to set these settings as default

Preset Management
1. Allow users to save their own custom default preset
2. Have a built-in preset manager
3. Users should be able to add as many presets or subfolders/banks as they please
4. Users should be able to mark presets as favorites
5. Users should be able to put presets in categories
6. Users should be able to filter on favorite presets and categories
7. XML format should be used for easy copy/pasting/archiving/sharing of presets

Reference Levels
1. Where it makes sense, users should be able to select between different reference/calibration levels
2. A switch with a few preset reference levels is acceptable
3. A slider allowing users to change reference levels is ideal
4. Users should be able to copy these settings globally to other instances of the plugin
5. Users should be able to save these as default

Gain-Staging
1. Auto-Gain Compensation (AGC) should be developed to offset any increase in gain dynamics or EQ plugins may create
2. AGC should be based on perceived volume, and it is acceptable if there are extreme use cases where it does not function
3. Users should be able to bypass AGC
4. Where a plugin may increase volume, a clean output trim should be provided in addition to AGC or any modelled output with saturation
5. Where a plugin may distort when driven on input, an input gain should be provided to allow users to drive the plugin harder

Dry/Wet
1. Effect plugins should include dry/wet knobs in most scenarios (as appropriate)
2. Separate dry and wet faders are acceptable where beneficial
3. If using faders, there should be modifiers to move both knobs in tandem (example: holding down Alt and increasing the wet level could decrease the dry level, and holding Ctrl could move both in tandem)
4. A “Lock” feature should exist to prevent the dry/wet balance from changing when changing presets

Sidechains
1. Plugins should include sidechain inputs where appropriate (e.g. compression, gates, etc.)
2. Plugins with sidechain inputs should include at least the ability to Hipass filter the sidechain, with more filtering options welcome

Rack Effect Plugins
1. Any rack-style plugins should also include the individual modules as separate plugins
2. Rack plugins should allow for easy drag and dropping within the rack
3. Units within the rack should be sized to allow for multiple units to be visible at once
4. Racks should have global input/output trim knobs
5. Racks should have global dry/wet knobs
6. Each module in the rack should have input/output/dry/wet knobs where appropriate
7. Racks should allow for routing possibilities that are otherwise not possible within the standard DAW
8. Units within the rack should be able to have their own presets with per-unit preset management
9. The rack should have global presets with built in preset management

Noise
1. If a plugin produces “modeled noise,” users should have the option to disable it
2. Disabling noise should ideally be a slider, but an on/off toggle is acceptable

[Zaphod (giancarlo)]

a lot of plugins don't follow your rules or rules asked by customers, but they are pretty successful.As soon as a plugin is "perfect", than it looses identity because nobody complains, so there is no argument and people stops speaking about it
I suggest to commit clearly some mistake if you need attention
Shadows difficoult to read, wrong knobs, crazy choiches.
Ford said it pretty well, if you asked people something to buy they wanted horses

[karrikuh]

Great topic, I was thinking about doing a similar post for some time, since, as a user, I've had several moments where I got pissed by quirks in basic functionality of otherwise great products. While I agree with many of the points in your list, however, I honestly think that in a perfect world, features e.g. related to preset management or oversampling should rather be realized on the host side, rather than having each plugin reinvent the wheel.

So here's my list, of the top of my head:

GUI

• Use plain, smooth background. Abstain from unnecessary, gimmicky FX e.g. complex textures, reflections, lighnting effects
• Respect industry standard: ctrl-click or double-click control (support both!!) => reset to default value. shift-drag => fine adjustment

Architecture

• samplerate agnostic processing. Your plugin should work just fine at 123.456 kHz.
• Control signals should operate at least at host sample rate
• Automation, MIDI CC should be smoothed, but care should be taken to not overly reduce the control response time.

Parameters (Host default GUI)

• Consistent name scheme, sensible choice of abbreviation: <Group> <Param>. Example "Osc1 Volume", "Filter Cutoff"
• Parameter names in Title Case. ALL CAPS hurts my eyes
• Sensible parameter scaling: e.g. Amplitude gain and frequency/pitch parameters should scale logarithmically (in dB and Hz/semitones, respectively) since that's how sound is perceived by humans.
• Sensible value ranges: limit your value range to what is sensible musically. I know this one is hard, requires lot of experience, experimenting. Mathematically: maximize the sweet spot region in your parameter space! I hate it when moving some slider/knob becomes fiddly just because the designer thought he needs to extend the range to insane amounts "just in case". Ideally, one should need to resort to the fine adjustment funcitonality (shift+drag) only in rare cases.
• Meaningful values/physical units. Gain in dB, Frequency in Hz and so on. Please no universal 0..100% or 0.0 .. 1.0 range for every parameter!
• only include paramters in list published to the host which are meant to be automated/externally controlled. For example, I don't want the list cluttered by 100 control points of a synth's step sequencer. It is perfectly possible to maintain internal paramters in your plugin which are just not exposed to the hosts interface.
• Leave out those future compatibility place holder parameters aka "<Reserved>". I think most major hosts handle additional paramters in later plugin versions just fine, I admit though I could be wrong here
• If your plugin has a lot of parameters, provide macro controls

That's it for now, will probably add more soon

[Funkybot's Evil Twin]

a lot of plugins don't follow your rules or rules asked by customers, but they are pretty successful.

These aren't "rules" at all just ideas/thoughts about what works well. Most are based on a general consensus that's been developed about good ways to do various things. I can point to plugins that do each of those things well or poorly, and I think you'd find there's a general consensus about what are better versus "less good" approaches.

For instance, the first time I came across XML presets was through Valhalla, and I know Sean got that from someone else. Now TDR has been doing it to good effect also. Marking presets as favorites and categorizing/sorting/filtering comes from NI. No one's combined the two yet, but who would possibly complain if they did?

Again, I can't think of a single plugin that does all of that stuff.

As soon as a plugin is "perfect", than it looses identity because nobody complains, so there is no argument and people stops speaking about it
I suggest to commit clearly some mistake if you need attention

That's certainly an interesting take.

I'm assuming the suggestion that developers should intentionally makes things to complain about for attention is a joke. The flip side of that argument is: you can aim to do things really well and get attention that way.

A use-case a developer might run into is, "I'm looking to implement X feature, what are some things people want to see in that." It'd be great if they could reference this thread, or something like it for ideas/discussion on the topic features.

[Funkybot's Evil Twin]

oops...duplicate...see next post...

[Funkybot's Evil Twin]

• Respect industry standard: ctrl-click or double-click control (support both!!) => reset to default value. shift-drag => fine adjustment
• samplerate agnostic processing. Your plugin should work just fine at 123.456 kHz.
• Consistent name scheme, sensible choice of abbreviation: <Group> <Param>. Example "Osc1 Volume", "Filter Cutoff"
• Parameter names in Title Case. ALL CAPS hurts my eyes
• Sensible value ranges: limit your value range to what is sensible musically. I know this one is hard, requires lot of experience, experimenting. Mathematically: maximize the sweet spot region in your parameter space! I hate it when moving some slider/knob becomes fiddly just because the designer thought he needs to extend the range to insane amounts "just in case". Ideally, one should need to resort to the fine adjustment funcitonality (shift+drag) only in rare cases.
• Meaningful values/physical units. Gain in dB, Frequency in Hz and so on. Please no universal 0..100% or 0.0 .. 1.0 range for every parameter!

karrikuh, thanks for your post. The quoted points above in particular stick out for me. Particularly Sensible Value Ranges and Meaningful Values!

[cryophonik]

I'll add one more:

- Installers should install the plugin at the root-level of the folder specified by the user, not in a subfolder that is automatically created by the installer.

It drives me nuts when I install my new "DeveloperX" plugin in my "DeveloperX" folder, only to have the installer put it in a "DeveloperX\DeveloperX" subfolder.

[Funkybot's Evil Twin]

I'll add one more:

- Installers should install the plugin at the root-level of the folder specified by the user, not in a subfolder that is automatically created by the installer.

It drives me nuts when I install my new "DeveloperX" plugin in my "DeveloperX" folder, only to have the installer put it in a "DeveloperX\DeveloperX" subfolder.

+1 on that.

EDIT (thought of some more):

Installers

• If your plugin installer is writing/reading registry keys anyway, keep track of what formats I previously installed and where I put them. This way, when I need to update your plugin, all I have to do is click the next button and everything goes exactly where I last had it.
• If all that's needed to run the plugin is a .dll, offer a zip file as an alternative to an installer
• Include version numbers in your installer/zip files. When installing plugins off a backup, it makes it much easier to know you're installing the right version. Also, it means I won't be overwriting installers in case the newer version has a bug that the older version did not.

[RunBeerRun]

I can overlook anything as long as it's portable. Windows doesn't like uninstalls, it's like taking a hammer and nail and forcing it into your computer, it's going to leave damage.

[kylie]

- Installers should install the plugin at the root-level of the folder specified by the user, not in a subfolder that is automatically created by the installer.

It drives me nuts when I install my new "DeveloperX" plugin in my "DeveloperX" folder, only to have the installer put it in a "DeveloperX\DeveloperX" subfolder.

perfectioning this idea would be an installer (and they do exist!) that installs the plugin at the aforementioned root-level folder specified by the user and tell the user about the automated creation of the "DeveloperX" subfolder I would have created anyway myself

(and use, of course, an already existing "DeveloperX" subfolder, and/or let me install it without the "DeveloperX" subfolder, if I really mean it!)

[karrikuh]

Concerning installers:
Only deploy a plugin with installers if absolutely necessary, e.g. complex changes to system configuration are required or many files have to be copied to different places. This is probably rarely the case.

Otherwise, ship a simple ZIP-File with DLLs clearly marked for different platforms. Users are mostly capable of picking the right file and extracting to the correct folder. Plus, they will love the transparency of this kind of installation process.

[karrikuh]

For Windows builds, link the MS Visual C Runtime statically! It's a simple compiler flag, and will save your users a lot of hassle

[fese]

Full ACK especially on the GUI/legibility list.

Mouse behavior
- the plugin should offer mouse wheel support. Shift-Mousewheel for fine tuning gets you bonus points!

GUI
- Use fonts that are optimized for screen use, not some weird fonts originally designed for headlines.

[Funkybot's Evil Twin]

User Guide/Manual

• Have one
• Install it somewhere sensible where users will be able to locate it later on
• Link to it from the plugin UI (a link in the about box may even be a good out of the way place)
• Make it available on the product page of your website (great for when I want to read on my tablet or phone)
• Explain what a feature does as though your users have no experience
• Include use-cases and best practices where applicable
• If complicated setup or multiple steps may be involved in completing a task, include step-by-step instructions - be host specific and include different instructions for popular hosts if needed (Cubase, Logic, Sonar, Studio One, Pro Tools, Reaper, Fruity)
• Proofread the manual, or find people who can assist in making sure the language and syntax is clear

License Transfers

• Allow them
• If not allowed, or not free, or NFR after resale, then state your license transfer policy on your website where people can see it ahead of purchase

Version Numbers/About Box

• Include the version number on the plugin UI
• About boxes are an acceptable place to have the version numbers if you don't want it on the main UI
• About boxes are good places for links to the website, manual, etc.
• Always a good idea to include the development team and thank beta testers in an About box

[Funkybot's Evil Twin]

Full ACK especially on the GUI/legibility list.

Mouse behavior
- the plugin should offer mouse wheel support. Shift-Mousewheel for fine tuning gets you bonus points!

GUI
- Use fonts that are optimized for screen use, not some weird fonts originally designed for headlines.

Good ones, thanks! At some point, I may add the later additions to the original post.