February 21, 2008

A Couple Thoughts On Feature Requests...

by Chris Randall

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.



Page 1 of 4

Feb.21.2008 @ 11:24 AM
Adam Schabtach
I'd like to harp upon a detail that's rather significant to this topic. Many users believe that it is easy to add features to plug-ins. Speaking strictly of the DSP code itself and of the user interface, sometimes it is easy, sometimes it isn't. Someone asked for a bypass switch on one of the recent modulation plug-ins, and yes, internally that's not a difficult thing to do. Recoding Ricochet to make it a "true stereo" processor would be a difficult thing to do. We spent a lot of time considering exactly that design decision, and I (still) believe that we made the correct choice.

However, the real stumbling block is this: adding another control to a VST plug-in means adding another parameter, in the host's view of the plug-in. There is more than one host out there that will unceremoniously crash if it loads an existing session which includes a plug-in whose number of parameters has changed. Users become very, very upset if their sessions start crashing. To some enthusiast in a home studio, it may only be a mild annoyance; to an engineer in a big studio with a high-profile client, it can be disastrous. If Audio Damage were to start releasing updates to our products which accomodated seemingly insignificant feature requests but caused existing sessions to crash, we would quickly lose our reputation for producing reliable products--and rightly so.



Feb.21.2008 @ 12:24 PM
I write image processing software for medical research, and 'feature requests' are the bane of my existence. Not because they aren't sometimes good ideas, but because anyone can think of 100 new features for a program in the time it takes to properly code and test one new feature.

And of course I can't blame people who aren't programmers for this, but they have absolutely no clue as to what things are easy to code in and what things are difficult. The average 1 hour meeting I go to in order to get user feedback generates months of work, even after tossing out the impossible, the impractical and the stupid.

And I'm dealing with a highly focused group of professors and post-docs. You have to put up with every loudmouth troll who ever picked up a cracked copy of Fruity Loops. I feel your pain.


Feb.21.2008 @ 12:29 PM
Adam - I'm so glad it's not just me that fears adding parameters.
You've made my day :)

I suspect that certain non-developers have no idea how much work is involved in _properly_ maintaining multiple versions of a plugin either.



Feb.21.2008 @ 12:33 PM
Chris Randall
For what it's worth, I suspect that the fact we are paid for our craft is largely a result of the ability to stomach the problems and make the experience simple for the end-user.

Or to put it another way, if it was easy, everyone would do it.



Feb.21.2008 @ 12:49 PM
Man. I just read some of that thread. What a sad, sad waste of your time.

I'm pretty sure there is a reasonable facsimile of that guy that exists in every sector of our society. God damn it sucks when you run into them.


Feb.21.2008 @ 12:49 PM
I commend you for your patience with that guy. While I'm no developer, I can appreciate all the thought and work you guys put in to your releases. I mean, it really is an art form. His points were just foolish asshatery. It'd be like me asking [demanding] you to change a snare sound on one of your songs and then being pissed that you didn't do it for me.

I suppose the good news is that guy has a lot of disappointment in life we can all look forward to.


Feb.21.2008 @ 12:50 PM
I think too often end users forget the art that goes in to the craft.

I don't believe I make a lot of feature requests in beta phases. Apart from following in life a general axiom of choosing one's battles wisely, I view much of what's in the software as representative of the designers' perspective. Feature requests should start with "this would make it easier/faster/simpler/better to use...." and rarely "you know what I would really like this to do....."

Evaluating someone else's work should be about the flaws and merits explicit to their work, not how I might impose my perspective on to it. Some folk just have trouble with that idea, everything of course being about themselves.


Feb.21.2008 @ 12:53 PM
Well said Shamann!

Feb.21.2008 @ 1:10 PM
Quote: "... I'm not aware of any female plugin developers at this time."

Sophia from dfx?
link [destroyfx.smartix.co...]">link [destroyfx.smartix.co...]


Feb.21.2008 @ 1:12 PM
mike kiraly
I have never understood those who get angry over what their music software purchases don't contain. You really don't see this too many other places in the consumer market.

For example, it's not considered appropriate for me to spend $30 on a hardcover book (the same price as some of the AD plugs, no?), read it, and then demand via every known internet forum that this book contain an extra character which was not part of the original plot. I can't buy a movie ticket, see the movie, and then freak out because the studio chose to not include one of my favorite actors. I can't buy a car, and then wage an internet war for the manufacturer to install sateillite radio for free as an after-market add on.

It amazes me that music software (and occasionally hardware) consumers always feel entitled to a mountain of lifetime free upgrades and updates - bug fixes and promised features excluded of course - I'm talking about new features.

You should pruchase a producet based on it's exisiting feature set (and it's perceived value to your life) and NOT for the wishlist items you can dream up after the fact.

Now, what really irks me are people who buy a $49 plug-in that does EXACTLY what it says it does, and still feel entitled to feature upgrades. Maybe, just maybe I can sympathize with someone who purchased an expensive open ended plug-in platform (like a Powercore, etc) believing the value in the price to be the foretold expandability. But a $49 plug-in?

BTW, I haven't read the KVR thread, so maybe this mini-rant is way off base.


Page 1 of 4



Sorry, commenting is closed for this blog entry.