@David-Healey I've tried getting SES for over a year now with no luck, they deny every time.

How did you manage to get it?

If I could get them, I could reduce Soundsync marketing email pricing by nearly 50%.

@dannytaurus A bit of a rigamarole but I'm biased lol.

@cartemtune I'd open it up. As David said, Japan & Australia have a good market, about 15% of my sales are these 2 places.

@dannytaurus What do you mean by reseller terms?

@dannytaurus ahhh I see now, I misunderstood the statement.

@cartemtune Does it prevent you from using the platform once the cap is reached?

Hey Gang,

Planning how your plugin business handles licensing, logging, customer accounts, purchases, activations, updates, and product management can prevent many support requests before they happen.

It also gives you the information and tools you need when a customer does need help.

A few things worth planning early:

• A reliable licensing system that handles activation, restoration, device limits, and offline use.
• A logging system that records useful technical information without collecting the customer’s creative data.
• A customer-management system that connects purchases, products, licenses, downloads, and support history.
• A solid checkout and order system for failed payments, duplicate purchases, refunds, receipts, chargebacks, and missing orders.
• A clear Merchant of Record or payment-processing setup so tax, billing, refunds, and customer responsibilities are properly defined.
• Self-service tools for resetting activations, managing devices, finding receipts, and downloading products again.
• A clear way to identify the installed plugin version and whether an update is available.
• Useful error messages that explain what happened instead of only saying something failed.
• A simple way for customers to send relevant diagnostic information with a support request.
• A plan for server outages, expired subscriptions, refunded purchases, and other unusual situations.

Purchase issues can create just as much support work as technical problems. A customer may have been charged but not received access, used a different email at checkout, purchased the wrong product, or lost their receipt. If orders, customer accounts, product access, and licensing are disconnected, resolving a simple issue can require searching through several systems.

When everything is connected, support becomes much easier.

If someone changes computers, they can reset an old activation themselves. If a customer reports a problem, you can quickly see what they purchased, which version they are using, and whether their license is active. If a payment or fulfillment problem occurs, you can trace the order and restore access without manually piecing everything together.

Good customer service is not only about responding quickly. It is also about building systems that prevent confusion and give both the customer and developer useful options when something goes wrong.

This is one of the areas we are working on with SoundSync: connecting commerce, customer accounts, licensing, activations, downloads, product versions, communication, and support information in one system.

The goal is to reduce preventable support requests while making the requests that do happen much easier to understand and quicker to resolve.

@dannytaurus SoundSync can currently receive information related to the product’s operation and the customer journey, including:

• When the plugin is opened or connects to SoundSync
• Activation, validation, restoration, and deactivation activity
• The installed plugin version
• The product and license associated with the activation
• A hashed installation/device identifier for managing activations
• Interactions with SoundSync-provided areas such as activation, account, store, support, and update interfaces
• Timestamps showing recent validation or connection activity

This can be combined with information already created elsewhere in SoundSync, such as purchases, products owned, downloads, customer accounts, support activity, email engagement, and marketing consent.

That makes practical things possible. For example, a developer could notify customers using an outdated version, help somebody who purchased but never activated, exclude existing owners from a promotion, or create a re-engagement flow based on meaningful customer activity, cart recovery, etc, etc.

SoundSync does not inspect or collect the customer’s audio, MIDI, presets, parameter changes, DAW projects, filenames, or what they are creating. We are interested in product lifecycle events that help with licensing, updates, support, and relevant communication, not the customer’s creative activity.

We also try to keep the principle fairly simple, collect the minimum information needed for the feature, be clear about how it is used, and give developers the controls they need to handle consent and privacy properly.

Some of this varies by integration. For example, the HISE package can report plugin-open and SoundSync interface events, while licensing integrations naturally generate activation and validation events whenever they communicate with SoundSync.

Hey Gang,

Just wanted to drop in with a post I thought some might find useful.

When someone buys and uses a plugin, useful information is created across the store, licensing system, email platform, and the plugin itself.

Connecting that information makes marketing & servicing much more useful. Instead of sending the same emails to everyone, developers can create:

• Marketing emails: Send product announcements, educational content, updates, and offers to the appropriate customers.
• Growth flows: Automate cart recovery, post-purchase follow-ups, review requests, customer rewards, upgrade campaigns, and re-engagement emails.
• Segmentation: Group customers by products owned, purchase history, license status, activation activity, installed version, or engagement.
• Personalization: Adjust email content and offers based on what each customer owns and how they interact with the product.
• Cross-selling: Recommend compatible expansions, sound packs, or related plugins while excluding customers who already own them.
• Customer retention: Identify inactive customers and send relevant education, updates, or incentives to bring them back.
• Product updates: Notify only the customers affected by a release, compatibility change, or important fix.
• Analytics: Connect campaigns to purchases, activations, product use, reviews, and repeat sales instead of measuring email clicks alone.

This is especially useful for smaller plugin companies because these tasks can run automatically instead of requiring someone to manually manage lists and customer records.

It is not about collecting every possible piece of information. It is about making the information you already have useful. Purchase, license, activation, and product data can help make emails & servicing more relevant and show what is actually helping the business grow.

This is one of the larger ideas behind SoundSync. We are connecting the store, customer accounts, licensing, plugin activity, marketing emails, growth flows, and analytics so developers can manage the customer journey from one connected system.

@dannytaurus Including the email marketing is a pretty smooth move. Does the % fluctuate at all based on usage, number of contacts, emails sent, etc.? Or a minimum monthly in sales?

I've seen Gumroad around but never used it. I went straight from the wacky world of Wordpress to developing and using Soundsync.

Is your reason for no licenses just less user friction?

I'd love to see the comparison in price! That's the type of thing that tickles my pickle.

Hey Gang,

This is something I’ve been thinking about a lot lately.

Finishing the instrument is only one part of releasing a plugin.

A lot of us can get the actual product built in HISE like the UI, samples, scripting, presets, installer, export.

That part is hard, but it is also the part most of us signed up for.

The harder surprise is everything that comes after.

Once you want to actually sell it, you suddenly need a whole second system around the plugin:

• a product page
• checkout
• license delivery
• customer accounts
• download access
• license resets
• device limits
• refunds and revoked access
• update delivery
• support emails
• “I bought this but lost the download link”
• “I got a new computer, can you reset my activation?”
• “My license is not showing up”
• “Where do I log in?”

None of that is really the instrument. But if you don’t have it, the release starts to feel unfinished.

That is the gap I’ve been trying to solve with Soundsync.

The idea is to give audio developers the business layer around the product like storefront, customer library, license/activation handling, download access, and the basic post-purchase flow that customers expect.

For HISE specifically, my goal is that the instrument itself should not become a mess of store logic, customer account logic, and manual support work. The plugin should mostly care about whether the customer has access. The rest should live in a system built for selling and managing audio products.

I don’t think every developer wants to build a mini Shopify, license server, download portal, and support dashboard just to release a plugin.

This is the bigger problem Soundsync is aimed at, not just licensing, but helping developers get from “I finished the plugin” to “I can actually sell and support this properly.”

Curious how other HISE developers are handling this right now. Are you using Gumroad, Shopify, custom scripts, manual serials, your own backend, or something else?

Hey Gang,

Quick update on SoundSync & the HISE integration I've been working on.

SoundSync is now LIVE!

This means you have two integration paths available from the developer dashboard:

1. HISE Script Package
This is the simpler drop-in version for developers who want the fastest setup inside a regular HISE project.

The include is intentionally simple:

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

This package handles the branded activation UI, login activation, serial activation, machine validation, deactivation, Store, My Products, and customer product access using HISE Script + WebView.

2. Native C++ HISE Package
This version is for developers who are comfortable building HISE from source. It moves the more sensitive licensing/runtime layer into native C++ and keeps the HISE Script side as small as possible.

The HISE Script side is only a lightweight gate:

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

The Native package includes the C++ source, HISE source patch/tools, setup instructions, and the same product/developer branding flow as the HISE Script package.

The goal with the C++ version is to make the licensing layer harder to inspect or tamper with than a script-only package, while still keeping the HISE-side integration simple.

Current package features include:

• Activation by customer login or serial + email
• Product-specific machine activation, validation, and deactivation
• Server-side activation counts and serial status updates
• Offline grace period and cached local license state
• Branded activation UI with developer logo, product image, Brand Manager colors, and light/dark logo background handling
• In-plugin Store with catalog browsing and single product pages
• My Products panel with current product serial, activation info, copy serial, deactivate this machine, and owned-product access
• Branded storefront/account link handoff with SoundSync fallback links
• Test Connection flow for checking package/API setup
• Product-scoped generated config for each developer/product
• HISE Script package and Native C++ source-build package options

Both versions are generated from the SoundSync developer dashboard and are product-scoped, so developers can export a package with their own product info, branding, activation settings, storefront links, customer product access, and machine/license behavior already configured. They both include simple instructions for integration as well.

The HISE Script version is the fastest route for most developers.
The Native C++ version is the better option if you are already maintaining a custom HISE source build and want a stronger licensing boundary.

SoundSync for HISE is live now, and both package options are available from the developer product dashboard.

If you are building commercial HISE instruments or effects, you can now generate a product-scoped HISE package with activation, validation, Store, My Products, branding, and customer access already wired in.

JUCE packages are also offered for direct JUCE connection.

Feedback from the HISE community is always welcome as we keep improving the developer & customer experience.

Learn More About Soundsync

Best,

Aaron

@dannytaurus Great idea. I'll add this to the HISE/JUCE package updates.

Thanks!

@dannytaurus Hey Danny,
Not to Hijack your thread but figured I could let some light in on Soundsync.

The initial post is about support. I dont have this yet but I just added to the update list and will get it done ASAP! This feature would be included as "transactional" emails, so they will be free.

Soundsync also offers a Marketing Email option which segments your users based on useful info like products purchased, date range, imported list and more options coming soon (like plugin versions, etc).

You also mentioned wanting a more easy to follow fee matrix. Soundsync is easy.
10% fee covers everythinng except marketing emails (first 1000 free every month) and redemption overages (first 10,000 free each month).

So it looks like this:
10% Platform fee (covers transaction fee as well)
Email Marketing (First 1000 free each month, then $1/1000 emails)
Redemptions (First 10,000 free each month, then $0.005 each)

There is a $10 monthly minimum, but this is waved once you surpass that in other charges (like platform fee).

Soundsync is also a MoR.

Apologies again for Hijacking. if you feel this is crossing the line just let me know and I'll remove it.

Soundsync Information

Dev Signup

Best,

Aaron

@Edwards said in Soundsync Beta: HISE Ecosystem | UPDATE: Native-Authoritative C++ Licensing Bridge:

Sounds like a useful workflow for HISE developers, especially having licensing, delivery, and customer management tied together. I’d be interested to see how the activation flow handles offline use in practice.

Good question! The current flow is online for first activation because the plugin needs to verify the license/serial/customer account against SoundSync and bind that activation to the user’s machine.
After that, the plugin keeps a local activation state so the product can continue opening without calling home every launch. If the server is unavailable, the plugin can enter an offline grace state instead of immediately locking the user out.
The intended behavior is:

• First activation requires internet.
• Normal launches restore from local activation data.
• Periodic validation refreshes the license state when online.
• If offline, the plugin can continue working during the configured grace window.
• If the license is refunded, revoked, deactivated, expired, or outside grace, the plugin returns to the activation screen.
• Developers can choose how strict the grace period should be for their product.

So the goal is not “phone home every time or fail,” but also not “activate once and trust forever.” It sits in the middle: friendly to real users who are offline, but still gives developers control over revocations, device limits, offline grace and subscription/license state.

@Chazrox Gotta check it out now!

Hey Gang,

I’ve been working on a complete website and storefront builder for plugin developers, and it’s now mostly finished.

The goal is to make it easier for developers to launch a polished, branded website for their plugins, instruments, effects, sample libraries, or audio tools without having to build the entire web side from scratch.

I’m using Moonwave FX as the live demo:
Moonwave FX Website

This is not just a product page template. It can be used for a full developer/brand website, a complete storefront, or only for specific pages like a product page, landing page, homepage, etc.

Moonwave FX is using Soundsync fully as its host. Only a domain with access to DNS was needed. Outside of that, everything is handled directly inside Soundsync.

The builder is designed so you can customize the website around your own brand, including:

• Full branded websites and storefronts
• Individual product pages
• Full Catalog Pages
• Custom domains (including SSL certificate)
• Custom themes and color palettes
• Logo and brand placement
• Screenshots, videos, audio demos, and product previews
• Feature sections and product descriptions
• Purchase, download, or signup buttons
• Support, documentation, and contact pages
• Page-level customization for different products or releases

Everything is meant to be editable inside the website builder via pages themes, so you can adjust the layout, content, branding, colors, themes, and page structure without manually rebuilding the site each time.

I wanted to share it here because a lot of plugin developers spend most of their time building the actual product, while the website, storefront, branding, and presentation side can become its own huge project. This is meant to make that part faster, cleaner, and more flexible.

I’d be interested to hear what other developers would want from something like this, especially around storefronts, product pages, demos, downloads, licensing, documentation, and support sections.

Website Builder Pages View:

Click Here to learn more about SoundSync.

Of course, everything within Soundsync interacts so websites, customers, verification, serial validation, marketplace, etc all work to make a smooth experience for both Developer and Customer.

Best,

Aaron

UPDATE: Native-Authoritative C++ Licensing Bridge

SoundSync HISE package is rebuilt so the UI stays in WebView/HiseScript, but the licensing authority is now native C++. The WebView only collects user actions and renders safe public state. C++ handles activation, validation, restore, protected storage, device identity, offline grace, deactivation, and the final mayOpenProduct access result. HISE copy protection then reads that native result.

It’s not a pure C++ UI replacement. It’s a hybrid: WebView for branded UX, C++ for licensing authority. That seems to fit HISE better because WebView is still the easiest way to keep product branding, storefront, My Products, and login flows flexible, while C++ owns the trusted licensing path.

@Lindon thanks for the suggestion.

UPDATE: Auto-Detect + Dynamic GUI Sizing

When you download the HISE package, you will not be required to enter the GUI size anymore as it is auto-detected directly in your project. Thanks @David-Healey

Also, the complete HISE package is dynamic and will change dimension based on changing GUI elements (like an expandable keyboard or effect section). Thanks @dannytaurus

For example: Customer didn't pay for their subscription, grace period ends, they are using plugin now with the keyboard extended. The plugin will pause, popup the activation webview, and the webview overlay will still block the entire plugin, not just the original size.

@dannytaurus YES! Im adding this now as well. Didnt even cross my mind.