Skip to content
SoundSyncAudio software platform

Guide

Native HISE C++ Setup

Install native licensing sources, patch and rebuild HISE, and integrate the exported plugin.

Start with getting startedExplore API docs

SoundSync

Build the native path

  1. Copy the generated package

    Keep SoundSync under the project Scripts folder. Read SoundSync/Docs/SETUP.md and Native/README.md.

  2. Install native sources

    Use SoundSync/Tools/installNativeHisePackage.ps1 for the target HISE project. It installs AdditionalSourceCode/SoundSync/Native.

  3. Patch your HISE checkout

    Use applySoundSyncHiseApiPatch.ps1, then verifySoundSyncHiseApiPatch.ps1 and verifyHiseSoundSyncApiCompatibility.ps1 against the intended HISE source checkout.

  4. Rebuild HISE

    Build and run the patched HISE authoring executable. The source patch is not applied merely by copying project scripts.

  5. Start the native gate

    Add the two-line include/start sequence below to your project interface.

  6. Export and patch VST3

    After export, use patchExportedHiseVst3Project.ps1 on that exported project, then build it. Reapply after a fresh export when needed.

  7. Verify native authority

    Test startup, activation, device revocation, locked output, and headless hosting in the actual exported build.

SoundSync

Native gate startup

Native gate startup 
include("SoundSync/Scripts/SoundSyncNativeGate.js");
ssSoundSyncNativeGateStart();

Recognize an unpatched authoring build

If SoundSyncNative.initialize is undefined, the JavaScript include can be present while the native bridge is unavailable. Recheck the source checkout, patch verification, rebuild, and executable path before investigating customer licensing.

The exported Windows patch connects copy protection and the native networking/cryptography libraries. Use the generated tools rather than guessing a list of compiler flags. Keep a recoverable copy of your own build configuration before applying a source patch.

Do not substitute a script success for native proof

A working activation overlay does not prove native audio enforcement. Check the intended native authority mode in the generated configuration and exercise unauthorized processing with the editor closed.

Credentials and enforcement shipped in client software can be extracted or modified. Native enforcement raises the integration barrier; it is not a piracy-proof guarantee. Keep developer account tokens and partner secrets out of distributed plugins.

Build compatibility

This guide describes the current implementation and package instructions. Source review does not certify every host, operating system, provider delivery, or payment lifecycle. Test the exact build and environment you intend to release.

SoundSync

HISE package requests

Package Management API

Product status, HISEScript/native generation, rotation, storefront package, and private ZIP links.

Explore

Native account login with two-factor authentication

The updated JUCE 0.7.3 and HISE Native C++ 0.5.2 sources support the customer account two-factor challenge. Regenerate the complete package, replace the matching sources and rebuild the plugin; an older installed binary does not acquire this behavior from a documentation or server update.

Sign in with the customer email and password. If two-factor authentication is enabled, the account form changes to Authenticator or recovery code. Enter a current authenticator code or an unused recovery code and choose Verify code. A challenge is not a customer session, entitlement or device activation; the plugin remains locked until verified account login and product/device activation succeed.

An invalid code can be retried. An expired challenge requires signing in again. The challenge lasts up to ten minutes and is kept only in the running native client, not the activation cache, logs or public state. Account passwords, two-factor codes and account session tokens are not saved in the license cache. Do not disable two-factor protection to integrate a plugin.

Use the serial claim helper for ownership verification

beginClaim(serial, email) starts the existing serial ownership-verification flow. Its first argument is the serial/license key, not an arbitrary web claim token. The wire request sends license_key and the current machine identity to POST /api/license/v1/claim.

A pending claim leaves the plugin locked. Keep the pending serial, email and claim ID in the native licensing flow, then use Restore or pollClaim to check /api/license/v1/claim-status. Once the server returns a claim_activation_token, the client makes the final /api/license/v1/activate request for that same serial and machine. A claim email, verified status or HTTP 200 alone does not unlock the plugin or reserve a device slot.

Pending serial/email context survives a restart in the protected cache. A temporary network failure, server error or rate limit during status checking or final activation keeps the claim pending so Restore can retry. A confirmed licensing denial is different and does not create offline permission.