How do you create a trial period for someone once your plugin is made for them to demo, For say 24-48 hours? And also once i make the plugins using packages on a mac will the vst2 & 3 work on a pc? Or do i have to compile on visual studio first? Thanks.
In order to run on a Mac, you need to build on a Mac; in order to run on Windows, you need to build on Windows.
Have a poke around the OnlineUnlockStatus and TracktionMarketplaceStatus classes, they’ll provide you some clues as to the complexities involved in doing license registration and trial periods. There are a lot of different paths to take - but you should inform yourself about the current state of the art in the JUCE SDK beforehand, imho.
As for plugin packaging - @reuk is correct, you will need to build for Windows on a Windows system, and Mac on a Mac system - although there is one sweet little bonus which is that these days you can take your Windows .DLL and run it on Linux, too, if you need to … but then again, you can also just do a native Linux build and forget that nonsense.
For different platform builds, a general bit of advice is that you work to set up a VM environment - this makes it very easy to just stay focused on developing on a Mac (or Windows if that’s your thing) and then have your builder VM’s “catch up” with you, offline, and build/package/sign/notarize everything, automatically. This takes a bit of effort but in the end you will very much enjoy the process of developing on your Macbook, but getting .pkg’s and .exe’s (and .deb’s) spit out for you at the end of the production line …
1 Like
Thanks for that info.
Regards
When i am sending someone a plugin, Is it best to send in debug or release while using packages? Thanks.
Thanks for that info.
Regards
When i am sending someone a plugin, Is it best to send in debug or release while using packages? Thanks.
If you want to Debug the issues that person might have with the plugin - such as seeing DBG() messages that might’ve been emitted to the console while they were testing it for you - then you’d be wise to use the Debug configuration.
If its an end-user who you don’t intend to have that sort of transaction with, then send them the Release build.
But the bigger question is, why don’t you, yourself, know the difference between a Debug and Release configuration of your builds? It is very important to know how the configuration differs between these two build configurations, and I would advise you to think about this a bit better. Debug builds are usually configured to emit debugging messages, or set things up in a way that - if there are bugs - important information can be gathered about the instance, from the user. Release builds - well, as you might infer, do not include such debugging information, because the implication is, that a “Release” no longer needs debugging …
I do no the difference for myself, It is just for sending it to someone.
You probably don’t want to send debug builds to end users, as there’s a high chance they won’t run correctly, even if there are no bugs as such in the code. Debug builds can end up requiring things that are typically only installed on developer systems and they typically also run very inefficiently. If you need error diagnostics from end user systems, you might want to think more carefully how you are going to do that, instead of just giving them debug builds.
Ok thanks