I'm currently building an app which I hope will allow batch exporting of HISE projects, auto notarization on Mac, and auto-generating installers. So far I have the basics working on GNUx. I need to finish the interface and add the batch handling, but that shouldn't be too difficult, then I'll tackle the other platforms.

This app should make it much easier for everyone (and especially beginners) to export their projects from HISE and build installers.

This is what it looks like so far (it's an ugly work in progress).

@MikeB

Dave, 34, UK, doer of many things.

It's starting to look a little nicer now.

Status update:

GNU/Linux: Fully working (standalone, vst2, installer). x64 only
Windows: Fully working (standalone, vst2, vst3, installer). x86/x64
MacOS: Fully working (standalone, vst2, vst3, au, codesigning). Needs a bit of tuning but almost there (installer). x64 only.

When I say fully working, that's in my own tests, I expect many a bug report when I release it into the wild.

It's quite possible that AAX plugins will compile just fine on Windows and MacOS too, I've implemented it in the app but haven't tested it.

If all goes well I should finish up the tuning of the MacOS build tomorrow and it will be ready for my patrons to test this weekend!

@Christoph-Hart Could you merge my juce_template pull request (if all is well) as the mods there are needed for my app. The mods are also useful for regular exporting from HISE, bigobj is enabled by default and the VST3 SDK is set correctly to the one that is in the JUCE folder.

pkgbuild works! I can programmatically generate unique packages on MacOS now! woohoo!

Feature request: Ability to designate some presets as factory (read-only)

Done

And a happy new year!

The source code is now online - https://github.com/davidhealey/hise-exporter

I'm just ironing out a few bugs then I'll build the beta executables for each platform and make them available on Patreon.

I've been thinking of making a HISE tutorial series, as I did for Kontakt, and wondering if there is any interest in it. I already have the Patreon page and YouTube tutorials, and a dedicated course would cover some of the same ground but in a more structured way. What do you guys think, worth doing?

I did a little Skype interview the other day where I was talking up HISE, as always.

@dustbro Could be a permission issue. Is it only happening with the VST or also the AU?

That's correct, vst3 shows up as a folder, same on GNU/Linux. LV2 format is the same. I think .component also shows as a folder, no?

@orange said in How to make Trial Plugins for 10 days:

but this time the plugin couldn't pass the macOS notharization system.

I don't think people using cracked software care about that

@Lindon said in How to make Trial Plugins for 10 days:

they have some way of "seeing" into my product script code... and reading my approach and my secret keys

I would guess that this is what they've done.

Exciting times!

@Christoph-Hart I haven't been able to make a minimal example. But when the freeze happens the debug output fills with this

@Lindon What happened, how did we end up in this thread?

Part of the problem I think with Urs idea is he is expecting the cracker to look for the point at which the app performs a delayed check. If I was trying to crack software of this kind I wouldn't bother at all with when the software wants to perform a check. I'd look for the if statement that enables the functionality I want since that can't be delayed. If I have a valid license the software must do what I want when I want it, I compare this against an unlicensed version and find out where the restriction has been placed.

As an example, let's say the app goes silent for 1 second every 30 seconds, well I search for that functionality in the code and disable it. The delayed checker can carry on happily doing its thing, in the meantime I'll just enable all the functionality I want and tell it to ignore any signals that it may receive from the license checker in the future, whenever or however they may be delivered. It still comes down to swapping some boolean tests. The delayed checker is only a block if your plan of attack is to nutralize the checking mechanism, but you can just sidestep it.

In his example there is a message "this demo has expired". All you have to do is find that text string in the binary (of course it could be obfuscated but you can still find it). And then change a boolean value and that message will never appear.

The idea is certainly a valid additional tool to include though. One possible scenario is the crackers don't even notice the check, they think the software just works fine with or without the license, and only end users who've downloaded the app and don't have a valid license discover the security limitation after they've been using it for a while, and that may prompt them to purchase a license.

@Lindon Thanks, I just found a similar post by him in another thread. So it seems it's a way to make it harder for crackers but doesn't eliminate but doesn't solve the problem 100%.

@Christoph-Hart This bug is there in the latest commit. Basically if you have a project with multiple scripts and you click the edit icon to go to one script, then click the edit button of your main interface script, HISE will just freeze. This doesn't seem to happen with a simple project but I'm trying to make a reproducable snippet now.