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.


#14

Hi Dave,

could I ask you a few questions on MyCommerce? (I’ve been using BlueSnap for some time now, but they introduced an “account maintenance fee” a few years ago, and are now going to change their APIs, so I’m wondering whether, if I need to make changes to my purchasing process anyway, perhaps now is a good time to look for better solutions)

I understand MyCommerce calculates/charges the correct amount of Tax/VAT for your customers, which is great. Do they also hold off that tax/VAT and remit it themselves to the correct authorities (so you don’t need to deal with all of that)? That’s how it goes with BlueSnap, which is a nice feature.

Does MyCommerce support coupon codes for promotions, where you can let multiple people use the same coupon code? I quickly checked their info, and only seemed to find something about generating multiple coupon codes for a promotion (like 1000 or so), and nothing about just issuing a single coupon code that is then used by different people. In BlueSnap, you can create a single (or more) coupon code(s) and say how many times it can be used, and if it can only be used once for a certain email address etc.


#15

Hello Koen, each country’s Vat is taken at source when the user purchases, it can be absorbed into the price (gross), which means everybody sees the same price, or added to the final price at purchase (net). They charge you a percentage of the purchase to themselves using two models:
Model A USD 2.95 + 5.00% of the product price)
Model B (14.90% of the product price with a minimum charge of USD 2.50)
The only promotion I’m aware of is a coupon system then is fixed code for all. I send the code to people for an educational,discount (40%) it’s just a bunch of numbers, the user thinks it’s just for them and they haven’t shared it to anyone else, yet. I change the code occasionally. I’ve just started a Christmas holiday discount, which was quite successful last year. It’s probably best to let it run into the new year because you always get late people that complain about the cut-off point. The coupons are just simple things that you can turn off and on and have a running time or set as continuous. You can set bulk buy discounts at any number and any price.

You create the keys on their site by sending them a java class, that is quite easy to do, but remember you have to duplicate the same routines in C++ for you plugin to duplicate the reg code.


#16

This is something I was worried about until I read this blog post: https://community.mixedinkey.com/Topics/22771/must-always-be-online-to-use-captain-plugins-no-go-feature

“You have to remember - those who pirate it would not have bought it anyway. You’re assuming that potential paying customers are becoming pirates.”


#17

Well, that blog post isn’t really solving any problem. I didn’t use this plugin and don’t know anything about. But for sure I agree with the users there, that a workflow that only works online is just not an option, no matter if it is a computational or policy necessity.

However, I also disagree with that quote:

There is a fraction, who just “forget” to pay, after they got it from somewhere, because “they wanted to evaluate it first”. So my 2 pennies are, don’t put to much effort into making it pirate safe (it isn’t possible anyway), and avoid all nuisances and support cases for paying customers.

But at the same time, having a reminder for after the trial period to get a decision, if the user wants to buy or doesn’t want to buy makes sense to me.


#18

I recently spoke with a developer who’s due to release a synth plugin, he was initially going to create licenses etc but he decided on a different model: he creates a limited demo build, and a full version. The full version does not check for a license at all. Paying customers get regular bug fixes/updates and support via email. His thinking is that even with very clever copy protection, it will get cracked anyway, so you’re just buying time. His advice to me at least was to focus on the product you are creating and do the minimum necessary with regard to licensing.


#19

I tend to agree with this, but not sure entirely. I’ve always been of the opinion that hacking crews tend to focus their attention on big ticket items. Not sure they tend to bother with £20 or £30 purchases, so I think sale price is also a factor.


#20

It’s a big subject! There was a study a few years ago that said only 1% of Windows software was actually purchased. All I know is I’ve been stalked by a particular group for years, I think they are based in China or perhaps Japan from my research on them - I don’t really care to be honest, but they send me a nice email whenever they crack a plug-in of mine. It doesn’t matter if I put registration code time bombs (ie. check different parts of the registration at a later date) or whatever, it represents more of a challenge to these kids, I can almost see them rubbing their hands together and wiggling in their seats at the prospect of getting around the latest obstacle I throw at them. Cracks can cause a lot of heart ache, stress and worry. But the world is full of c :slight_smile: ts! And all you can do is minimise their control of your products. My stuff is not expensive - it’s just fun for them to crack.