Fear of the DAWs


#1

Hey there,

Is it realistic to run a small VST dev company all alone as a side-business? I’m not worrying the most about developing and selling (my life does not depend on it). The part I‘m most afraid of is handling support. Even if JUCE is keeping a ton of the ugly part of cross-platform-developing away from me I’m still afraid that there will be problems on certain DAWs and/or systems (PC, Mac) that I did not see on my own system.

What are your experiences? Is it possible to run a small side biz selling VSTs made with JUCE all alone? Or will compatibility issues kill me (or at least my time)? (Lets just assume I’m not the worst dev in the world but I have never released an audio plugin before)

Richie


#2

I don’t have direct experience, but if you want to be on the safe side, just compile for AU and you’ll only have to debug for Logic and Ableton


#3

Not quite correct. There is also Adobe Audition, Adobe Premiere Pro, Final Cut Pro X, …
I don’t think limiting to AU helps you at all.

I completely understand you, I have some almost finished projects from my time before getting hired full time, and I was always wondering, if it is better to try it or if I get more trouble than gain. One time I’ll try it.

My way would be transparency, on your website list, which hosts you tested. And have a time limited demo version, so courageous users can try new hosts. That way you are pretty much on the safe side…

Good luck!


#4

Go for it. If you’re plugin is not compatible with a certain host, it’s at least half their fault .


#5

I work for an audio company and also have my own apps (for example on Google Play Store). On mobile stores people consider the review system as a bug report system. you can easily see reviews such as:
(1-star) not working! try to steal you credit card details.

For plug-ins I do read and handle some support. most people are very helpful.
You would need to keep some time of your “part-time” to do support and maintaining code if you’d like to keep good reputation.

Usually you’ll have:

  • user reports an issue
    • option a: user fault. helping them resolves the issue. closed.

    • option b: DAW issue that is impossible to fix. you and the user should contact the DAW developer. it might help. (on JUCE I remember 2 cases: 1. closing Cubase caused JUCE plug-ins to crash, 2. Ableton tempo change reported negative sample position). KEEP IN MIND THIS IS LESS COMMON

    • option c (MOST COMMON): you do something that on the particular DAW happens on a different sequence.

    • option d: JUCE issue. you reproduce it with a simple project or JUCE demo projects and report it on the forum, provide a pull-request or fix snippet, etc…

Example of common issues:

  • Assuming your editor will have samplerate or some data based on prepareToPlay / processBlock on its creation.
  • Assuming all hosts provides a specific data (playback state, fps, program changes, etc)
  • Assuming the I/O of your plug-in won’t change on the fly.
  • Assuming some callback will be used each time playback starts

Suggested Precaution:

  • Validate your plug-in thoroughly with auval and awesome pluginval.

  • Make sure you keep symbols or mapping to symbols (pdb/dSYM/dwarf) so any logs from users would be helpful when needed.


#6

Definitely agree with @ttg there, and I’ll offer my 2¢ as well: if you get to a point where you’re struggling with the amount of time you have to spend on support, you’re doing pretty well for yourself.

I started my company a little over a year ago with my first plugin. Immediately after announcing my first product, I had a couple major support issues to handle, mostly coming from the fact that at that point I had no idea what the consumer expectations looked like. I would imagine you experience something similar (I’ve chatted with a few other devs who’ve had a very similar experience there).

But once you make it over that little hurdle you’re actually in a great spot. From my experience, JUCE covers so many edge cases and compatibility issues for me that 99% of the support requests that actually involve fixing code are just fixing some dumb mistakes in my C++ that can be identified and resolved on any platform.

Going back to the main point I want to make though: of the people that you sell to, only N% of them would ever open a support request, and of that N%, only M% will be using some weird DAW on some weird platform that you’re not equipped to handle. But M% of N% of the number of people you sell to will be a very small number as long as the number of people that you sell to is a small number. And that’s the real hurdle. So if you’re getting a ton of support requests, it’s quite likely that you’re really moving some sales, and in that case I think you’re doing great.


#7

Thanks Tal, I’ve just added some tests for these cases now! https://github.com/Tracktion/pluginval/commit/477d15345ddc4c30eab34ddff578eba41d104d40


This is exceptionally good advise. Keeping symbols on macOS/Windows is relatively straightforward but does anyone know how to do this on Linux?

I would imagine that you could specify a file to strip to put the symbols but I can’t figure it out.
The ideal would be that you could then send this to addr2line in the same way that you can call atos on macOS.

Do you just have to keep a non-stripped copy of the binary?
Has anyone done this?


#8

It’s so easy to fire off a quick email to answer most customer questions, but the chances are you’re going to keep getting the same question over and over, the time you spend answering the same question will add up.

My rule to minimise the time I spend on support:

  1. Publish a FAQ online.
  2. Anytime you receive a request for help that isn’t covered by the FAQ - Add the answer to the FAQ, then email the customer a link to the FAQ.

This takes longer at first, but you will discover your support requests reduce over time.


#9

All good advise above!

One thing to add:
Perhaps try to find say 5-8 (good and “host-spread”) beta testers to help you cover more systems / hosts that you will ever have time to test in yourself.
With “good” I mean: active when asked and preferably “precise” (not sloppy in descriptions of bugs and reproduction steps). With “host-spread” I mean: try to solicit people with different hosts/platforms/systems.

And perhaps another one (I’m a sinner regarding this one, and still haven’t learned my lesson):
Sometimes, it makes sense to simply not respond within the first 30 minutes when a support question comes in, no matter how much you love your customers and hate to see them struggle.
If your time is really very limited, I think it’s fair to “let some support issues automatically solve themselves”: there seems to be a magical time period (say 4 hours or so), within which some support questions get handled by the requester himself. Note: this is only for the simple things, not real genuine “bugs” that really cause your users serious trouble, of course. You would typically get some support question, and then say 1-2 hours later a follow-up saying “never mind, I already found it myself / in the manual / in the host docs / …” (or you’d get that as a reply after you quickly wrote your support follow-up email) :wink: Depending on the number of support requests you get, this might save you some time as well. In general, I try to respond within 24 hours, and usually get quite positive feedback about my support (it would appear that bigger companies don’t always have better support, from what I sometimes hear).

Last one: if you use ZenDesk or the like, you can set up snippets of answers to insert in your (still personal!) support requests: good for the recurring ones (of course, if it’s a real bug on your end, you should go and fix it!). And you can setup reminders for support requesters so that they get notified that you have answered them and they haven’t replied your email since say 5 days. I love to know if my support actually helped solve the issue or not!
I personally don’t deal with support issues over Facebook or Twitter, but ask people to use the contact form on my website for that (which will open a Zendesk ticket).


#10

Are people purchasing the plug-in? If so, I had the most pain from registrations. Make sure you accept at least UTF8 key text input, because you need to accept accented characters and all language formats. Always make it ignore case by forcing the whole thing to lower-case, not forgetting to top and tail spaces off the strings.
Above all, don’t be nervous, if you can’t fix a problem straight away, just let them know that you have seen their message. Plus, don’t be too reserved when giving refunds, there will always be refunds - always.


#11

Thank you all so much for your posts. Really, you took my fear of the DAWs or at least made it a lot better :slight_smile: If I look at it very honestly: A small boutique indie shop for audio plugins I have in mind won’t start with thousands of users. The few crazy people who will buy my stuff won’t swamp me in support mails. But with all your advice I now feel a lot more prepared to get that right from the beginning.


#12

Thanks for your suggestions! I totally agree that it’s important to give refunds when users are really unhappy with the product. Especially in my case (one man company as a side biz) generosity is important.

About the registrations: I think I will not host a shop myself. There are services like gumroad that take care of it for you and you simply add a few code snippets on your site. I don’t want to have too much stress with developing the website and shop. Enough stress to polish my rusted C++ skills now :wink:


#13

I’ve used Share-it (MyCommerce) for 14 years, and they handle the credit card stuff for me, which includes PayPal, intercontinental TAX/VAT additions. There’s still a lot to consider and do. How are your customers going to purchase the plugs for example? By entering a code or downloading the full version? Full versions can be pirated of course, which is a terrible/OK thing depending on your point of view, of course.