A Couple Thoughts On Feature Requests...

There’s this thread over on KvR which got kinda silly yesterday. We have (or “had,” rather) one customer who is (“was”) somewhat incensed that we didn’t add a particular feature to Ricochet, and despite the fact that I promptly refunded him, decided to air that grief on KvR. That’s fine, of course, as it’s what KvR is for, essentially. But my defense of Audio Damage and our policies maybe got a little more spirited than he expected. What can I say? I type faster than I think.

In any event, it got me pondering the nature of this business a bit last night. I was thinking that Audio Damage is in kind of an odd place, as while we’re sort of largish, as far as the non-big-company plugin sources go, we’re still small enough that the company has a very personal face. Or to put it another way, we have the sales and product line of a bigger company (like Ohm or PSP or whatever) but we generally act like the guys that make a lot of freeware plugs, inasmuch as you can talk directly to the person that makes the damn things.

(Does that make any sense? I didn’t think so.)

But on to the larger point, which is regarding feature requests. As I stated in the KvR thread, we take feature requests seriously, but we don’t usually add anything to a plugin unless a lot of people ask for it. There is a lot of reasoning behind this, but the simple fact is that changing the available parameters in any given plugin is a big deal. Some features that are requested (such as adding a control to the LPF in Dubstation) will actually change how the plugin sounds, and this is a Bad Thing, generally, as it will affect how a mix sounds if the plugin is used in that mix.

But the root of the issue is, I think, thus: you can write the guy that just put up a free VST and announced it on KvR, and say “hey, I tried your plugin and Knob A should control Parameter B in This Fashion” and he’ll probably make that change for you if it seems logical to him. (I’d use a more gender-neutral terminology if plugin development wasn’t such a sausage fest, but I’m not aware of any female plugin developers at this time.) So, since you can do that, you might assume that anyone that is easily available (e.g. us) will do the same thing, and be nonplussed when that turns out to not be the case.

We have a group of people we rely on, including at least one person from every demographic we’re aware of in this industry, from the well-reasoned hobbyist on up to professionals that regularly chart in their genres, other plugin developers, and first-call engineers. This group of people get the plugins as soon as they enter beta (and in some cases they get early screenshots) and their opinions on features are regularly implemented long before the plugin ever sees the light of day. Using this method, we’re fairly confident that when each plugin is released, it has a feature set that is appropriate to its abilities, and the controls that are present and the ranges under which they operate are as useful as we can make them.

Of course, this won’t change anything if the customer has severe ADD or whatever (as was the case in this particular instance, I think), but I hope that it sheds a little light on how we do things.