Just wanted to wish everyone a happy, productive and prosperous new year!

Until you spend hours debugging an inaudible filter node because Claude set the smoothing to 20 seconds instead of 20ms!

@David-Healey In a conversation with ChatGPT today, it said to me

Your mockup surprised me—I expected to dislike it. I don't.

AI is getting cheekier!

Anyone care to share their overall plans and goals for the coming year?

My main goal is to start releasing HISE plugins. I've been learning HISE for a while and it's time to start exporting my efforts!

1. A series of 4 free synth plugins, first one Sublime posted here for design feedback, and another 3, each based around one simple preset concept. Sublime is all about bass.

2. Then I have 2 collaborations I want to work on, both with UK house music producers. One is a multi-output drum plugin based on a series of expansions, the other is a chord synth with some interesting features.

3. I also have a lot of vintage reverb impulses recorded and processed, which I'd like to turn into a suite of free reverbs.

My user base is mostly house music producers & related genres - rave, techno, classic house, etc. I've built a decent brand and I think my customers will love the move from Maize-based ROMpler plugins to way more fully-featured HISE-based plugins.

What are your goals?

I like using overlay images to ensure my Figma design is translated properly to HISE. Currently, the only way I know to toggle the image visibility is to select/unselect the image, or quickly slide the alpha slider, which is difficult because of the 'invert' half of the slider.

This PR adds a toggle button between the image dropdown and the alpha slider. It uses an existing image icon for the button and respects the alpha slider value.

This allows me to toggle the image without taking my eyes off the interface, making it easier to spot changes.

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

@David-Healey I just had a go at fixing this. Is that what you mean?

HiseSnippet 1112.3ocsVs2aaaCDmJIJKwacqEne.H7e4roYH+pIcACMO8pwxCi4rhMDDTPKcxhKRjFRTMwXneH12z8MH6ndXKO6klZfI.av6Eue2wi2w9QRGHNVFQLpb0jw.w3qLGLQn7O1mwEjdmPL9ZyyYwJHhlw5nIiYwwfKwvX8eRyvX6MHoe+8aNhEvDNvLVDx6jbG3LdHWMia+C9YdPPWlKbEOrj1sOnmiTbrLPlf3YcSaxXlysrQvELsZqYRdKK1mX7sl1scX60zqSqVu9061wcH330.FtqCytCyqCC41l0tSi1DiMO0kqjQCTLEDia5QR2IC7k2Ixbv63w7gAflnAY.54L1ji84At8KRNwDhwF8mkpVOKU8Ryy4t7o7mkxddp.5LKJmzLV6wfTiOCHYTBRajAoWXNvIhOVMShFOeoYOAdB5wvylxPISWxZ+05lGKQMDp5gragtQHwTKp0z11hh+sy9UpfmOwJZ.yi9izBSbh.LRNS5vBNSJu8PgaW.BpoUGUrdDLhqqe5lHbTbonVU2H1c8kiSFeNHRNBOhGEISDtUsndE5LxhJG9G6T4OqPwuQ0iAUVcQsp12am+UEcQlXOrd5W.GUsqssrsz.F+cCJ9iOQTzSAg+29+CrHJCiXjUcFFs3dVvdLy8PjCJ7Z1012P+NZSKJ65FSW07F52SaqW0Jc0M6uPHo2Vd7a4i7CveJvk9FZln35ih.PP+gozCCRf4CacpCb0QOSLJ.pkiHK5d6TBmJ3dUAPy0HCt6YUDCHnmsNE1Md0LFstYIHu.U24yUyfEJuKVaTq5IfGKIPgI1FsqaOUtNyeHFpBv8JDVowuFeVSQoEsZ.3opVbBlU1crLbn7H48MJU7MRikvwRAnc3TMzVNkPCnEJOwhhc1u37lJEWHUvkhZ5i7sq7wJz+sHOukJSiiHYP.DsTw5FbQOlg0DIgCgHK7PRexVnHdgd9tDa9z5R3jkVJonTzSvUWNFxo6JCb0290qWrmBIOup6tjiPTUUZukmm2aoHuR3t5VKSSyjzPnbyexu16DlhUrY39h9ZLDo35Px3D3C3vgrFWaadBDeqRNF6yO8.kXrUlqeVQaMl.BR86VloqaPturCmTl.KICKFlr8lDxCOLO2lkYeG2U4OyZ9A9f9tXYNjR35KdhoDDclFMyPlowKwEgrTdqunO+8CzXCSLei4kBnxU2IqbkOd8GGXtPedbBizMIfoleridfbt.rJatd8594hXtZR4A1eFyhrezYQOUH9By9bki+xw3ZKAiXsy+GXLeB9yLO0yC6bNCfaX182V0w0eB2icpUbwnyYpHttF3hjvAXYnCfdWf0xw55h0z2Ayns0z5Lv.P3lR7.9kKrgl1HWXiBgX0kSj78NY2b0uQXqTNHlDougZa7wbHMcIWVCwmr7dGm42pELr4pZXqU0v1qpgcVUCe0pZ3tqpg68oMT+hxCSTxvrqMDx48OMs4pgwoBFVAlVsR9GztgJYG

Content.makeFrontInterface(200, 200);

const laf = Content.createLocalLookAndFeel();

laf.registerFunction("drawPopupMenuBackground", function(g, obj)
{
    g.setColour("0x00000000"); // any transparent colour
    g.fillRect([0,0,200,200]);
});

laf.registerFunction("drawPopupMenuItem", function(g, obj)
{
    var a = obj.area;

    var padArea = [a[0] + 2, a[1] + 2, a[2] - 4, a[3] - 4];
    g.setColour(obj.isHighlighted ? Colours.green : Colours.blue);
    g.fillRoundedRectangle(padArea, 8);

    var textArea = [padArea[0] + 8, padArea[1], padArea[2] - 16, padArea[3]];
    g.setColour(Colours.white);
    g.setFont("Default", 14.0);
    g.drawAlignedText(obj.text, textArea, "left");
});

const ComboBox1 = Content.getComponent("ComboBox1");
ComboBox1.setLocalLookAndFeel(laf);

The drawPopupMenuBackground object should probably include an area, and the popup menu items still have a subtle drop shadow. But they're both fixes for another day.

PR here, if it's useful: https://github.com/christophhart/HISE/pull/805

@bendurso Today I learned that right-clicking a module in edit mode shows a different context menu to right-clicking not in edit mode.

Posting this in case it helps anyone else. I just banged my head against a brick wall for too long before I realised how simple this was!

When using a Floating Tile with content type Waveform (to display the waveform of Sine Wave Generator or Waveform Generator, for example) the default waveform path is a filled shape.

You can override this with LAF function drawAnalyserPath and draw a line path instead of a filled path:

laf.registerFunction("drawAnalyserPath", function(g, obj)
{
	g.setColour(Colours.white);
	g.drawPath(obj.path, obj.area, 5);
});

However, this means that the path is clipped at the bounds of the floating tile, especially at wider line thicknesses:

To prevent the clipping, I fudged around with it for longer than I want to admit before I realised the answer is to simply reduce the area that the path is drawn in, by half the thickness of the path:

laf.registerFunction("drawAnalyserPath", function(g, obj)
{
	g.setColour(Colours.white);
	g.drawPath(obj.path, obj.area.reduced(2.5), 5);
});

Voila! No more clipped paths! Top row is using obj.area, bottom row is using area reduced by half line thickness:

You might want the left/right of the path to bleed out of bounds, in which case change the reduction from all-round to y-only:

obj.area.reduced(5) 👈 all-round
obj.area.reduced(0, 5) 👈 y-only

Note: you might need to compile with HISE_USE_SCRIPT_RECTANGLE_OBJECT=1 for the reduced and other Rectangle helper functions, as per the docs: https://docs.hise.dev/scripting/scripting-api/rectangle/index.html. Not sure if it's still the same, or if it's built-in to all new builds.

@Chazrox said in MEDIA BROWSER PLUGIN [NOT A HISE PLUGIN - but may be useful]:

The forum has definitely been less active since everyone has found their agentic work flows.

I noticed that too. Bit sad really. Maybe we should all start sharing more wins we have with AI?

I just went down the Windows installer and code signing rabbit hole for my synth plugin and came out the other side with a decision I didn't expect: no installer at all.

TLDR: if your plugin is one file going to one folder, a ZIP with clear instructions gives your users a smoother, less alarming experience than an unsigned installer, and costs you nothing.

Sharing the findings here in case it saves someone else a day of research.

My plugin is a single VST3 on Windows. Bundled presets/images/fonts/audio assets (for simple Audio Loop Players). That means one file, one destination folder. So the installer would exist mostly for polish, not necessity.

Here's why I dropped it.

The problem: an installer is an .exe, and an unsigned .exe looks scary

If you ship an unsigned installer, SmartScreen will greet your users with the "Windows protected your PC" screen, and they have to click "More info" then "Run anyway" to proceed. I'm sure most Windows users, especially music producers, are used to this, but for a paid product from a developer they've never heard of, that's bad optics. I'd argue worse than no installer at all.

Option 1: Azure Trusted Signing. Blocked for me.

This is the modern route everyone recommends, and it's cheap. But it's only available to individuals in the US and Canada. In the UK you need a registered (Limited) company. I'm still a sole trader with no Ltd, and I'm not registering a company and wading through Azure bureaucracy just to unblock a release. Registering is on the roadmap but not worth bumping it up for this.

Option 2: An individual code signing cert. Possible, but underwhelming.

There is a middle path: Individual Validation (IV) certs. SSL.com and Certum both sell these to individuals with no company required, verified via passport and a face scan, turnaround in days not weeks. Certum even has a "Cloud CODE Signing for Individual Developer" product that a company literally cannot buy.

But here's the catch that killed it for me: signing removes the "Unknown publisher" label, but SmartScreen reputation still builds up gradually per certificate. A fresh cert with no reputation can still trigger warnings. So you pay, you do the ID verification dance, and your users may still see scary screens for a while. And from March 2026 the CA/B Forum caps code signing cert validity at 458 days, so this becomes a recurring chore, not a one-off.

The realisation: no .exe, no problem

SmartScreen cares about executables. A ZIP containing a .vst3 and a text file doesn't trigger any of this.

So the Windows release is:

• MyPlugin.vst3
• INSTALL.txt ("Copy MyPlugin.vst3 to C:\Program Files\Common Files\VST3 and approve the admin prompt")
• LICENSE.txt

That's the whole install. VST3 has one canonical system folder, so there's no per-DAW path confusion like the old VST2 days. I shipped earlier plugins as VST2/VST3 and had some support tickets, but those were usually because of the VST2 confusion. Oh, and I'm clearly not doing AAX either - another axis of complexity avoided.

The installer isn't dead, just deferred

When I register as a company, I'll 100% ship an Azure cloud-signed installer. Shipping an unsigned one in the meantime would be a downgrade from the ZIP.

One extra risk: the ever-annoying Anti-Virus checks on Windows, and two practical mitigations. [1] Submit the ZIP and the .vst3 to Microsoft's file-submission portal once the release build is final (it whitelists the hash and hugely reduces the block-at-first-sight risk), and [2] run the final binary through VirusTotal before release so I know which of the ~70 engines flag it, if any. Both are free and take minutes.

Very open to having my mind changed here, but given the fact that I've been distributing my previous (non-HISE) plugins for 3 years on Windows via the ZIP > extract > copy to folder method, I think this is a no-brainer approach for my first couple of self-contained HISE plugins.

@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.