Time limits for demo's

[Drnkhobo]

Hey guys, ive been thinking of some limitations, like the one already in FS for VST demo's. I want to create a time limit for a program of mine. So you know the ones "30 day trial" ect.

I know I can do this in Ruby

Code: Select all

now = Time.now

but this can easily be bypassed by changing the windows time. Its too easy if you get what I mean.

Has anyone here successfully done something like this? Dont get me wrong I dont want it to be FULL proof but a little more than just changing the system time/date . . .

[tester]

Slow ramp/slide.

[Nubeat7]

i like the ramp idea , could be used for just working 10 minutes after loading a plugin or starting an exe..

[RJHollins]

Couple questions ...

Is the 'ramp' timer 'additive' ? In other-words, if an time threshold is set ... will each successive runs continue incrementing until the final [max] time is reached?

2nd ... and possible limitation, when the DEMO times out, if the app is replaced with a new or archived version, won't the ramp time start fresh ?

Thanks for any insight.

[tester]

1. Set ramp (either via stream using code, oscillator or de-zipper, or via green using slide prim or timer or windows time calculations).
2. First time threshold reached - triggers switch, that turns off the whole application/output (one trigger switch, bo go back).

The ramp will start from zero each time you start the app, but what nasty is - you need to start the app over and over again.

Among other solutions, you can give some voice-over (built in loop wave), that is added to sound output. Or you can build a distractor, similar to one that is added in demo mode for VST.

[Tronic]

just a NOP assembly operator to elude this protection.
don't waste your time in simply protection, use your time to make better and better code.

[RJHollins]

just a NOP assembly operator to elude this protection.
don't waste your time in simply protection, use your time to make better and better code.

So your suggesting that if that single operator is replaced with a NOP command ...
Then, when the app is then run to test the crack, we should initiate a 'format drive' command ?
You may be right ... that is better code.

In the meantime, it would be nice to offer a similar 'demo' function that, some, 99% of all software gets released as. A way for a potential buyer to audition, and if they want, to purchase a full working version.

[tester]

RJ - I don't understand something. Observing what you were creating in last months (and how you were approaching SM/FS boards), this one should be very easy for you to make on your own, in literally no-time. Make an example for us, so we can point you - what and how you can improve it. I encourage you that you enliven your own flow of creativity. Perhaps, first of all - define your strategy, to what degree you wish to be intrusive in limiting your demo, and then follow these assumptions step by step.

My advice - do something simple, and forget about complex solutions; not worth of your time. If your buyers are crackers, then you are in no positions to dictate rules. If your buyers are regular users, then they will encounter the limitation and decide to buy, because "this is what regular people do".

Additionally - you can disable (remove, hide or modify) the preset manager from saving or loading external presets. If there are many tabs and options - good enough for me.

[tester]

...

[Drnkhobo]

Thanks for the replies !!

I dunno about this whole topic now
It seems that if there is a way (and there IS) people will get past it.

I suppose its down to the individual & how much time you want to put into it.