@Lurch Actually, I made a flowchart. Yes, there are a lot of steps!

@David-Healey @Christoph-Hart, and anyone else - let me know if any of this is wrong and I'll update.

@Lurch To add to David's reply - freebies and paid products are treated the same. If they're not open source (as in, plugin source code supplied to end users) then you need a HISE licence.

If they are open source, and you supply the source code to end user, you don't need either a HISE or JUCE licence.

For closed source, the revenue for the JUCE licence is calculated differently depending on if you're an individual or company:

• For individuals, the revenue is just that from your use of JUCE, meaning the plugins you create.
• For companies (limited company, LLC, etc.), it's the whole company's revenue, regardless of whether it's from the plugins or not. Big distinction.

Note that although the current JUCE licence is technically for JUCE 9, it still covers JUCE 6 that HISE uses:

Can I use a previous version of JUCE using a JUCE 9 licence?

A JUCE 9 licence grants you the right to use all previous versions of JUCE, under the terms of the JUCE 9 licence.

@David-Healey Done

• ABSOLUTE RULES now has a MINIMAL CODE COMMENTS entry. It says to comment only what is non-obvious, contradictory, or missing from self-documenting code, to keep needed comments to one line, and to point at the forum topic or GitHub issue/PR for more context.
• Comments & Documentation under Code Style carries the detail with three examples. The FL Studio comment from PR 1040 and the instrument-plugin note beside the confusingly named macro in PR 1039 are listed as good comments. The multi-line host-echo paragraphs from PR 1037 are listed as too much, with the one-line-plus-reference guidance. It also bans comments that restate code, narrate control flow, mark edits, or leave investigation notes behind.

@David-Healey Oh, you mean comments in the code! I thought you were talking about commit and PR messages.

I checked the comments in my last two PRs and stand by them. I feel both require more explanation than the code alone provides.

With confusingly named stuff like FRONTEND_IS_PLUGIN you have to write a comment, because that macro name is the very opposite of self documenting code!

And FL Studio is a special case where the UI warning message is misleading because FL provides per-plugin buffer sizes.

I'll ask Claude to keep comments restricted to explaining non-obvious or contradictory things.

@David-Healey I like plenty of context in the commit and PR so they stand alone and I don't need to remember what caused it, why I fixed it, and what options we discarded.

What do you mean by 'bloat'? A couple hundred more bytes of text?

Here's a tiny PR that sets the macro to zero by default for instrument plugins.

If you set it yourself in the plugin preprocessors, that will override this default, so it's safe.

It uses the confusingly named FRONTEND_IS_PLUGIN (which returns false for instruments ).

https://github.com/christophhart/HISE/pull/1039

In 2022 Christoph said:

I fixed this recently so now it should cope with any buffer size you throw at it (with a slight performance hit at weird buffer sizes). You can safely deactivate the macro.
https://forum.hise.audio/post/59057

Since then the standard forum answer has been to set the macro to 0 (for example 8478, 12569).

@justmull I hit the same thing in Live 12. Claude tracked it down.

HISE reports every parameter change back to the host as a manual edit, including the ones from the state restore on project open and from the editor being created, and Live treats those as a user takeover and greys/disables the lane.

PR here: https://github.com/christophhart/HISE/pull/1037

It gates those non-user origins and stops the plugin echoing the value the host just sent.

Verified in Live 12 with six automated lanes over repeated project opens and editor open/close.

One note on the getValue() == newValue guard: HISE stores the attribute before it notifies, so that check is also true for the user's own knob drags. With it in place the host is never told about a user move, which breaks automation writing.

That is why the PR filters on where the change came from instead.

@David-Healey Great info. Thanks!

Let's face it, this question is going straight to @David-Healey

What's the reality of providing Linux versions of my plugins? I've had a non-zero number of requests for it.

Five specific requests for Linux support ("Linux please, very buggy in wine", "Linux Mint 22.3", "Linux Mint", "Mint", "Ubuntu 24.04 LTS") and 2% of my recent survey said they run Linux as their main OS.

What do I target?
Does one Linux plugin work on multiple systems?
Does Linux have code-signing/notarisation or a convoluted mafia-style certification system, or is the Wild West?
What's the support volume of Linux users versus Mac/Win users?

@David-Healey I'd probably take vibe coded voodoo over 20+ years of legacy code and technical debt

Like you say, a black box is a black box, so as long as what comes out of KODA works properly, it doesn't really matter what the code is like.

Totally agree of the ecosystem stuff. That's why I never developed for Kontakt (too much licensing overhead) nor used many, if any, Kontakt libraries.

I've looked into all the other systems you mentioned and they all have similar tradeoffs.

The only move I would make from here is likely to pure JUCE. With AI tooling even as good as it is right now, let alone what it will become, that's the realistic and practical direction.

@David-Healey

What does Koda do that Kontakt doesn't?

No idea, but at least it won't have a load of legacy cruft in there.

I don't use Kontakt libraries at all if I can help it. Never liked the platform, as either a developer or end user.

@David-Healey Agreed about competition.

Not competition to HISE though, because with KODA you build libraries for someone else's player, not your own VST3/AU plugins.

But competition in terms of UI, features, ease of use, etc. definitely.

Regarding Kontakt, some would say at least it's a newer, less encumbered system.

Looks pretty cool, but I'm not sure I understand what the whole thing is.

https://kodasampler.com

Definitely a sample-based plugin builder, but looks like it's also a marketplace too?

You build libraries for the KODA player, rather than building your own VST3/AU plugins.

Looks pretty nice though!

@Christoph-Hart Great, thanks.

Where do I get a copy of the current licence? I was never sent one when I started paying.

@ustk Yeah, good idea. I asked Claude if the version reports as an invalid number, or just as 0.0.0.

• The AU plist has AudioComponents.version = 0.
• Pluginval decoded that as v0.0.0.
• JUCE’s decoder explicitly formats the packed integer 0 as 0.0.0.

0.0.0 is valid as a semantic version, but AU metadata uses a packed UInt32, not a SemVer string.

In practice, hosts treat raw value 0 as “version unset.” Logic therefore labels it invalid, while pluginval merely displays the decoded value.

For 0.0.30, the AU field should contain integer 30. The bundle’s separate CFBundleVersion can remain the string 0.0.30.

Can anyone confirm how revenue is calculated for the commercial HISE licence? @Christoph-Hart

There's conflicting info on the website and in the preview contract. Conflicts highlighted by me in bold.

Pricing table on https://hise.dev/#license says it's HISE-based:

Indie: less than 50.000 € annual revenue made with HISE-based products
Pro: more than 50.000 € annual revenue made with HISE-based products

The preview contract first says it's company-wide revenue, regardless of HISE:

Section C.2

"The licensing fee shall be payable monthly and be measured in terms of the total annual revenue generated by the Customer, regardless of whether this revenue is related to the Software or not."

Then Annex 2 goes back to HISE-based:

Annex 2 (pricing scheme)

The total net revenue is the sum of all revenues that is being generated using products based on HISE.

So the website and the pricing annex in the contract agree on HISE-based revenue, but Section C.2 of the contract seems to say it's the total revenue generated by the customer, whether from HISE products or not.

@resonant I'll also add, if you want to build a plugin manager like Arturia Software Centre or UVI Portal, that would be an interesting HISE project.

But for a straight up single-product VST3/AU/AAX installer, I'd go with Package Builder or Packages.

@resonant I wouldn't use HISE to build a simple installer for VST3/AU/AXX.

Package Builder by Araelium and Packages by WhiteBox can both do this very easily with native macOS windows and controls.

@David-Healey So you think the docs are wrong, rather than it being a bug?

If it's intentional behaviour I won't file a fix. But if it's a bug, it should get fixed because it's one of those silent time-wasters that can grind productivity to a halt.

@David-Healey

FL Studio is so temperamental

Ugh, indeed. And not really something I can ignore.

I just did a user survey and FL Studio users are 8%, third largest after Live 61% and Logic 14%.