Log on
Main page Graphics Photography Music & Audio Audio Plugins Video Tools Web Design Documents Space Astro Amiga Funny Surreal Gallery Links & Contact

Plugin Development Check-list


Based on long time experience with using Buzz plug-ins, and the issues these have had, I've tried to assemble a short self-test to help plugin developers rule out some common problems often forgotten. I've made two variations, and you'll most likely only need the first one.

Juce, VST & AudioUnit

  1. Read my Audio GUI Design guide and use what seems relevant. (Optional)
  2. Check both stereo and mono input
  3. Check both stereo and mono output
  4. Use a DAW that offers to randomize all parameters of your plugin, and keep hitting the Random button like 20-50 times while playing, to provoke weird settings. It must never crash.
  5. Check 22050 hz, 44100 hz and 96000 hz samplerate. Changing the samplerate should not affect the sound of either generators or effects. Tuning, vibrato, attack/release times etc. must take the samplerate into consideration.
  6. Try sending digital silence into your plugin and see if CPU usage rises a lot.
  7. Try sending a super low signal (e.g. something at -100 dB) into your plugin and see if CPU usage rises a lot.
  8. Try sending a very short spike (just a few samples) at +100 dB into your plugin, and see if this results in a long-lasting noise burst. Clamping the input at e.g. max +20 dB might worth considering to minimize the risk of noise bursts generated by faulty plugins earlier in the signal path.
  9. Check that even extreme settings do not produce DC unless this is a deliberate behavior.
  10. Try using ASIO with the shortest reasonable buffer size to see if there are any CPU usage spikes that causes stuttering.
  11. Use at least 3 instances of your machine at once with different settings. Save and quit, then load the song and see if it still sounds right.
  12. Duration test: Leave two instances of your plugin running for 24 hours with as much functionality enabled as possible to see if it keeps working correctly for that long. One instance should process audio, the other should be in "not active" mode.
  13. Test as many plugin hosts (DAWs) as possible.
  14. Test that your plugin reacts to the most common midi messages: Pitch bend, mod wheel, program change, all notes off, and whatever CC messages that may be relevant.
  15. Have other people try your machine.

See also pluginval, a tool to automatically test plugins.

Jeskola Buzz

This version of the check list is only relevant when developing "machines" aka plug-in for this specific DAW.

  1. Read my Audio GUI Design guide and use what seems relevant. (Optional)
  2. Check both stereo and mono input
  3. Check both stereo and mono output
  4. Keep hitting the Random button like 20-50 times while playing, to provoke weird settings. It must never crash.
  5. Check 22050 hz, 44100 hz and 96000 hz samplerate. Changing the samplerate should not affect the sound of either generators or effects. Tuning, vibrato, attack/release times etc. must take the samplerate into consideration.
  6. Try sending digital silence into your plugin and see if CPU usage rises a lot.
  7. Try sending a super low signal (e.g. something at -100 dB) into your plugin and see if CPU usage rises a lot.
  8. Try sending a very short spike (just a few samples) at +100 dB into your plugin, and see if this results in a long-lasting noise burst. Clamping the input at e.g. max +20 dB might worth considering to minimize the risk of noise bursts generated by faulty plugins earlier in the signal path.
  9. Check that even extreme settings do not produce DC unless this is a deliberate behavior.
  10. Try using ASIO with the shortest reasonable buffer size to see if there are any CPU usage spikes that causes stuttering.
  11. Use at least 3 instances of your machine at once with different settings. Save and quit, then load the song and see if it still sounds right.
  12. Duration test: Leave two instances of your plugin running for 24 hours with as much functionality enabled as possible to see if it keeps working correctly for that long. One instance should process audio, the other should be in "not active" mode.
  13. Check Buzé and FL Studio compatibility. This is also a way to locate bugs that could potentially crash in the original Jeskola Buzz.
  14. Have other people try your machine.

If you pass all the above tests, you should be ready to submit the machine to buzz.robotplanet.dk.
Website by Joachim Michaelis