Ways to develop Demo/Trials of my products

Hi all, this post is about asking what the ways to deal with Demo/Trials of products are… I am sure there are hundreds of approaches and would love to hear about effective ways to deal with these situations for small developers. So far I guess that the most basic way is the Time/Date method: Plugin registers the time at which it was opened first, saves it, and as soon as X time has passed, plugin stops working.

Additionally, there is the typical "plugin bypasses every X seconds for a couple of seconds.

I can see the two examples above easily by-passable (time/date) or quite annoying (the bypass method), so my question is: What’s an effective way to create a trial of a product?

PS: I know I could also create a whole server-side-handshake system, but again, as a small developer, I believe this opens a door to the whole “network security and stability” of the server, which could completely absorb a huge chunk of my resources - so I am trying to avoid it…

Your proposed method time/date would work but could be easily bypassed. E.g. by user deleting the saved data.

It really depends on your users and what they might find annoying, and what would help them decide to buy your product or not. If you want to avoid dealing with a server, you could provide a separate build with features limited (e.g. with #ifdefs) or audio bypass/noise after X mins. Providing a feature-limited build prevents hacking since the code will not exist in the build for them to unlock.

And yes I can confirm if you go the server verification route, it will suck up a lot of your resources!

2 Likes

Interesting - can you enlighten me a bit on the #ifdefs concept? I understand there’s some #ifdefs variables that JUCE gives me (if mac, if windows, etc)… but how and where can I create my own definitions?

Thanks a lot!

If you’re using Projucer you could add definitions per target here:

eg. the Release target would have:

PLUGIN_IS_FULL_VERSION=1

and another Release-Demo target would have:

PLUGIN_IS_FULL_VERSION=0

then in your code you would wrap the parts you only want to be in the “full” version with:

#if PLUGIN_IS_FULL_VERSION
// some code to only be in the full version
#endif

or stuff you only wanted in the demo (such as notices that it’s a demo version, a button to purchase etc.):

#if !PLUGIN_IS_FULL_VERSION
// some code to only be in the demo version
#endif

You would probably also want a “Debug-Demo” target too whilst developing, with the appropriate definition in there (and also the corresponding definition in the “standard” Debug target too).

Thank you so much! So every time I’ll compile I just change the PLUGIN_IS_FULL_VERSION accordingly on the projucer? :slight_smile: magic!

Personally I’d set up multiple targets like this:

image

You can use “Create of copy of this configuration” to quickly set up a duplicate:

Then set things like the binary name, and the preprocessor definitions accordingly for each.

Oh right, so one copy is = 0 and the other = 1, and that way I compile the one I need! Of course, thank you so much!

1 Like

If you use the same binary name and plug-in identifier for your demo plug-in and your full plug-in, a user can re-open a DAW project after switching from the demo to the full plug-in.

Also consider that the demo plug-in might be present when the installer for your full plug-in is executed. It would be nice if the installer will remove or replace any leftovers of the demo.

2 Likes

thats a great point! Thanks!