Accessing Server API from HISE
-
@Christoph-Hart said in Accessing Server API from HISE:
This is the way to go and don't bother about the naughty client, think about the legit customer who wants to use your plugin without Wifi access..
Why does the legit customer need restricting, unless they're naughty. ;)
Libre Wave - Freedom respecting instruments and effects
My Patreon - HISE tutorials
YouTube Channel - Public HISE tutorials -
@d-healey you can do an a cheap and dirty update approach. Juce has an easy way to read a URL result as a text string and compare it with an input string, so you can just stick a .txt file on your site (hidden of course) and literally just have the text as the version number and match it against the current version. Whenever you load the plugin it can check that result against the internal version number and display it if needed. Just means you need to remember to update the text file.
Similarly you can do this for file activation for online list of CD keys, and it helps you to be able to disable any cd keys that are chargebacked/refunded. For this you probably would want credentials though, as having a publicly available list of keys is not really ideal :p
I might implement this in to my public branch once I'm finished with this chunk of work on release triggers
-
Because there are different levels of naughtiness and you want to prevent the moderately naughty customer to just upload it on some filesharing hoster.
Everybody has to find a solution that matches his paranoia and mine is a simple license scheme that prevents passing around a single copy across different computers without restriction, but I know there is a spectrum that spans from @d-healey to PACE :)
-
@d-healey The solution lies in the payment form, just add a "I am a naughty customer" checkbox :)
-
@ustk said in Accessing Server API from HISE:
@d-healey The solution lies in the payment form, just add a "I am a naughty customer" checkbox :)
I'm very tempted to implement that technique.
-
It takes weeks if not months to take the plunge of buying a plugin (at least I am)
Then 20min to actually buy it
Then 1min to hours for the download
Then 1-10min for the install/running
Then 30sec to type the credentials
Then 5-10sec to click activate and wait for the result...Can't help pressing F5 in the forum...
-
@ustk said in Accessing Server API from HISE:
Then 5-10sec to click activate and wait for the result...
All true but it's this last bit - a lot of customers are suspicious of what you are communicating to your server....
Frankly "calling home" schemes put off a large number of users - Christoph is right the local key solution is best - its the one most users can live with.
-
@Lindon said in Accessing Server API from HISE:
All true but it's this last bit - a lot of customers are suspicious of what you are communicating to your server....
That should be one of the advantages of the GDPR stuff - you need to tell them what data you gather and it's plain illegal if you collect more, so unless your customer suspects you of breaking the law, there's not too much room for suspicion.
-
@Christoph-Hart said in Accessing Server API from HISE:
@Lindon said in Accessing Server API from HISE:
All true but it's this last bit - a lot of customers are suspicious of what you are communicating to your server....
That should be one of the advantages of the GDPR stuff - you need to tell them what data you gather and it's plain illegal if you collect more, so unless your customer suspects you of breaking the law, there's not too much room for suspicion.
-- and given they are suspicious of you anyway.....honestly dont shoot the messenger - I think its daft too...
-
@ustk said in Accessing Server API from HISE:
It takes weeks if not months to take the plunge of buying a plugin (at least I am)
Then 20min to actually buy it
Then 1min to hours for the download
Then 1-10min for the install/running
Then 30sec to type the credentials
Then 5-10sec to click activate and wait for the result...All of those things you mentioned are something I give serious consideration to. There are many strategies to minimize the time at each of these stages. My goal always is to make them as short as possible. Here is my approach:
Rather than having customers debate for days, weeks, or months whether to buy a plugin or look for a cracked version, turn your offering into an impulse buy. You can do that by pricing your product right and offering great value, which could be through additional updates. The goal here is not to sell a product at the highest price possible but in the highest quantity. I would rather sell a product for $20 to 10 customers, than for $200 to a single customer. Since these are digital goods, all that matters is the total sold. And the more users you have, the higher your brand awareness will be.
Offer a bundle deal on all of your products, so that it is just too good to pass on. Present all benefits and features in a nice way to make it so enticing that every minute a potential customer goes without purchasing it, is a "painful" minute :)
I have carefully looked at every stage of the purchase process and made my checkout for as frictionless of an experience as possible. You can complete the purchase within a minute. Get rid of all unnecessary input fields. All you need is an email and credit card fields/ PayPal.
Upon purchase, send automated emails with instructional videos and other docs on how to install and use the products, so that users can be up and running as quickly as possible, without having to bother you with support requests.
The installer should do as much as possible, avoiding having users to do any sort of manual hunting and copying around the computer.Speaking of naughty users sharing stuff- depending on what scale it is, it may not always be a bad thing. It could possibly introduce your brand to a larger user base. I discourage it by affordable pricing, but should there be some, you can implement plugin updates to entice them to purchase. That's one of the reasons I want to implement version update notifications, but not automatic updates. If a user obtains my plugin without purchasing it, they may get a notification that a newer version is available with a link to the relevant post. In the post, they can see what has been added. But, to update, they need to login to their account and download the latest version. That is also a great opportunity to expose either legitimate customers or anyone else to new products that they may have missed.
-
@Christoph-Hart Can you please point me to your latest official resource for the copy protection implementation?
-
hise_tutorial/SimpleCopyProtection at master · christophhart/hise_tutorial
The Tutorial project for HISE. Contribute to christophhart/hise_tutorial development by creating an account on GitHub.
GitHub (github.com)
But I haven't touched it since the initial commit, but be aware that this is not a "official" or readymade solution, but more like a starting point.
-
@Christoph-Hart Got it. Thank you!
-
@ustk Where is the url to the api containing get name method shown on the commit?
-
@JulissaDantes Sorry but what do you mean by "url"? the gitHub url?
-
@ustk I'm refering to the case of an external API, you said to add an API we could see that commit as a guide and you added the getname() method , but where is the api url, like "http://api/etc/parameter"?
-
@JulissaDantes I'm not sure we're talking about the same thing...
the getName() method is an API added to the API collection of Hise.
If you compile the latest commit of the develop branch from Dave's fork here: https://github.com/davidhealey/HISE/tree/develop
You'll get theEngine.getName()API available. (Engine.getVersion()has been fixed too)
