We launched our products with LimeLM (licensing SDK) and it’s been doing ok for the most part but there are occasional hiccups on Windows. For those that have a smooth experience using it, what are the good practices you have employed?
A few notes/observations
Where do you place Turboactivate.dll?
The developer recommends using a .dll, but that’s not as straightforward when it comes to plugins. The automatic search path is in the same dir, as the DAW .exe, not the plugin location. Installing it in System32 feels awkward since now I risk another application that uses LimeLM overwriting the .dll with an older version causing issues for my plugin.
For now, I am just using a static library, but this is not recommended by the developer, and it’s probably why I am getting some occasional issues.
Where do you place Turboactivate.dat?
I’ve run into some issues with folder permissions or unicode characters when using user specific locations. I’ve been experimenting with placing it in the “Resources” folder of the plugin bundle. That works great for Mac, and AAX but there seems to be a lot of Windows DAWs that do not support the bundle format of VST3. The developer recommends placing it in the same location as the .dll.
I’d love to hear about your experiences and recommendations.
Yes, we are quite happy with LimeLM, though there’s always the odd case where the API doesn’t behave properly. It’s important to stay up to date with their latest versions.
we serialize it and load it through TA_PDetsFromByteArray
Dropped them for LicenseSpring. Here are the things that caused us to change:
No Webhook Saas integration. all of the WebApi stuff is for PHP and older technologies. They are still stuck on older technology and have not integrated with the new tech of Saas.
2 IP Address limitation. May not seem like an issue, but if you want to do any kind of auto creative stuff with Shopify or other web services, it makes it very difficult.
Very smug responses from dev. Not willing to admit when stuff doesn’t work
Requires an ethernet adapter to authorize to machine. Can’t tell you how many users we have had that don’t have ethernet adapters, especially now with newer technologies.
BIG REASON - The activation success rate was about 90% and that’s. not good. Having to give 10% of your customers a refund is just not good.
I’m with LicenseSpring Now and although they are not perfect and wish for better and faster response from support, it is pretty much self-run. The WebApi is fully accessible via webhooks and they have modern technologies, even iOS stuff. I use Integromat/Make.com and do all sorts of crazy automations with Shopify.
Eventually, we will use our own system using Airtable and Integromat, but for right now, couldn’t be happier with License Spring, except for the slow tech support response. Luckily I’ve been able to resolve most of the issues.
That sounds very interesting. How was the migration from LimeLM for you? Did you have to email all your customers, or would Licenserping alow importing user keys?
I’m wondering what exactly you mean by “activation success rate” (of 90%). Are you referring to cases where users where unable to activate the software?
I mean that 10% of the users just cannot activate and of those 10% users, it is mostly Windows customers, usually due to hardware configurations or no NIC card.
With LicenseSpring, it is maybe about .5% and of the people that can’t activate. I’m able to get most people up and going if they disable virus protection, proxy servers, firewalls, etc…
@midiculous
Interesting. For us, it also seems that Windows users are the ones running into issues most often, though our failure rate is not as high as 10%. We now implemented @swar 's suggestion of loading TurboActivate.dat from binary resources, and I am expecting the success rate to go up.
I noticed with LimeLM, the big thing is that people are blocking the Lime server in their hosts file. This can often happen if they install a crack for any other software that is using LimeLM.
How does Licensespring work around that? I would assume it’s a fairly common issue for any system that requires an online connection.
I’m not claiming that our implementation is perfect and yes we have TurboActivate.dat from binary resources, but for some reason, just haven’t been able to get it going. We became frustrated and moved on. The other thing too, is all of that checking and accessing the server is also blocked by many DAWs and it can lead to the app failing AU/VST checks as well. So you have to deal with that as well, but that’s not such a big issue as you need to require the user to use the standalone.
My biggest issues with LimeLM are:
No detailed support to be able to look at our sample code to see what we are doing wrong and even the one time I did get that, I still had bad activations.
The API is not modern. It works, but old. With LicenseSpring we are able to fully automate and send webhooks to automate just about anything.
LicenseSpring just works…Almost all customers are able to get up and going.
LimeLM has promised this LicenseChest since 2021, where a user can login and control their activations. LicenseSpring has this automatically.
My developer also states that implementing the LS Code is much easier and with much more modern code.
So…our main decision was not based on just activations, but the entire architecture.
