Just wanted to give a quick view of the first implemented HISE serial validation tool.

First and foremost, use the Product Wizard to create a product. It will walk you through step by step.
11f7ea5a-7a0e-4212-a91e-13e05eb16e06-{0B3C526C-0AA4-46B3-8510-B76FA53E3490}.png

Once that is complete, you can generate a HISE package directly in the developer product view page. Simply enter your project UI size and generate the package. Unzip and place the SoundSync folder in your HISE projects "Scripts" folder.
license manager0.jpg

Open your project and use 1 simple include line to generate the entire package in your project.

include("SoundSync/Runtime/SoundSyncRuntime.js");

Then your branded validation window will be present. It will pull your logo, brand colors, store name, etc all from your Store/Brand page in the developer profile.
license manager1.jpg

Use the "Test Connection" button (when connected to the internet) to confirm your connection with SoundSync and to tell the server you have successfully put the package in your project. In your product view (where you downloaded the HISE package) you will see connection status.
license manager00.jpg

Once server connection is verified, simply hide the Test Connection button on your UI. This would complete your setup for live export/compilation.

Now lets test it.

Enter a serial number from your Serials page. You can generate them via the Serial Generator. Customer purchases will include an auto generated serial. If the serial is not tied to a customer yet, it will make them confirm identity and create an account on your website.
Click "Register and Verify"
license manager2.jpg

The verification will either pass (if serial is already link to customer) or will tell customer to check their email for confirmation. All customer support, verification, etc emails are also branded. If you have set up your custom braded website and domains, they will be used here as well for your from and reply to emails. Soundsync is created to live completely in the background.
license manager3.jpg

Once the customer verifies the license, they will be directed to a confirmation page and the plugin will automatically validate in the background.
license manager4.jpg

Hopefully some of you can find this helpful.

Looking forward to the feedback and thanks to everyone who already signed up!

All the best,

Aaron

@ustk ok here is what I did:

downloaded aax-sdk-2-6-1.zip unzipped it and got aax-sdk-2-6-1 folder copied this folder to HISE/tools/SDK/ opened SDK/aax-sdk-2-6-1/Libs/AAXLibrary/MacBuild/AAXLibrary.xcodeproj in xcode ran Product>Build For/Profiling. xcode tells me this was a success... renamed aax-sdk-2-6-1. to AAX in the HISE/SDK folder opened my project in HISE ran Export>Export As Instrument and selected AAX as my target....

got this in the console window:

⚠️ ld: ignoring file '/Users/lindonparker/HISE/tools/SDK/AAX/Libs/Release/libAAXLibrary_libcpp.a[2](AAX_VDescriptionHost.o)': found architecture 'arm64', required architecture 'x86_64' Undefined symbols for architecture x86_64: "AAXStartup(IACFUnknown*)", referenced from: ❌ "AAXShutdown(IACFUnknown*)", referenced from: ❌ "AAXCanUnloadNow(IACFUnknown*)", referenced from: ❌ "AAXGetSDKVersion(unsigned long long*)", referenced from: ❌ "AAXRegisterPlugin(IACFUnknown*, IACFPluginDefinition**)", referenced from: ❌ "AAXGetClassFactory(IACFUnknown*, _acfUID const&, _acfUID const&, void**)", referenced from: ❌ "AAXRegisterComponent(IACFUnknown*, unsigned int, IACFComponentDefinition**)", referenced from: ❌ ld: symbol(s) not found for architecture x86_64 ❌ clang: error: linker command failed with exit code 1 (use -v to see invocation) [KeyEngine - AAX] Linking KeyEngine ** BUILD FAILED ** The following build commands failed: Ld /Volumes/Untitled/Nomad\ Sounds/KeyEngine/Binaries/Builds/MacOSX/build/KeyEngine.build/Release/KeyEngine\ -\ AAX.build/Objects-normal/x86_64/Binary/KeyEngine normal x86_64 (in target 'KeyEngine - AAX' from project 'KeyEngine') (1 failure) ⚠️ /Volumes/Untitled/Nomad Sounds/KeyEngine/Binaries/Builds/MacOSX/KeyEngine.xcodeproj: The macOS deployment target 'MACOSX_DEPLOYMENT_TARGET' is set to 10.9, but the range of supported deployment target versions is 10.13 to 14.5.99. (in target 'KeyEngine - All' from project 'KeyEngine')

so its something about this:

found architecture 'arm64', required architecture 'x86_64'.

for some reason its not set up to build properly on my M1 mac...

@David-Healey Please check your dms for me

@David-Healey
Looks like they are selling Plug-Ins and knives. :-)

@pratitghosh move all the xml files into the new project and then compile the DLL there

@observantsound You can use both references at the same time. Just use the one that works for the bypass, and the other for your sampler job

What I said might work, but do as @David-Healey said it's better implementation even if the reference are the same behind the scene 👍

I think you can probably do it using the MidiAutomationHandler: https://docs.hise.dev/scripting/scripting-api/midiautomationhandler/index.html

@David-Healey ok thank you

@JC Hey i actually got the moonbase module to work in juce 6..
took David's advice and messed around with Claude and got it to work.

little tricky for me but its working. I Havent shipped anything yet though--Hopefully soon.

@jeffd

So i got a notarized .pkg working of the .hr files. still need to test more but i got them into the plugin's own per-user app-data folder. Then when the plug-in opens and installs the samples it can also auto-delete the .hr files right after extracting. And no gatekeeper quarantine from macos. Ill have to do the same on pc and create .exe for the .hr files to match. but perhaps this will be best. less confusing for people i imagine?

@Oli-Ullmann Yes a vm is the way to go if you don't have a mac

@David-Healey payload is good.

Oh ok, I didn't know. I do it right now.

@David-Healey Thank you. It compiled and worked just fine.

@dannytaurus Oh nice one! 👍

@ustk very sexy!

@ulrik Thanks for clarifying that detail, I was able to export my practice projects.

@David-Healey No, because this is about persisting the file to the user's disk.

Although as I said earlier, I think the final best answer is to display the license directly in the plugin somewhere.

Then nobody could ever accuse the developer of not making the license easily available.

Website goes down - no problem
User moves the plugin to another machine - no problem
User wipes/moves/modifies their AppData folder - no problem

If the license is in the plugin itself, it can't be accidentally moved, deleted or overwritten, and it can't become unavailable because of server outage.

Probably going this route now...

@Lindon Yup that's because it needs to be thought more as "container" rather than strictly "installer". PKG or ZIP are containers so -> notarisation