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?

@Lindon I reckon you need to use the links of the actual version, and change the version number manually so:

https://cdn.avid.com/aax-toolkit/aax-sdk-2-8-0.zip

becomes:

https://cdn.avid.com/aax-toolkit/aax-sdk-2-6-1.zip

All legacy versions "should" be available this way

@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

@Lindon Yes you spotted both of the main issues:

JuceHeader collision. Previous versions used #include "../Binaries/JuceLibraryCode/JuceHeader.h" which was fine for the DLL, but exporting to VST3/AU caused the JuceHeaders (project info like companyName, versionString, etc.) to be pulled in twice. Solution is just to use #include <JuceHeader>

.cpp.inc is resolved on all Fx to just .cpp (it was a leftover from the batch compile I ran).

A handful of effects couldn't be compiled together — some of the amp/saturation nodes (the ones based on a shared __Gain_H template) and a few of the k-reverbs. Individually they were fine, but combining them caused build errors. It came down to a couple of effects accidentally reusing the same internal names behind the scenes, so they stepped on each other once everything compiled together. That's now sorted out, and the full set compiles as one.

The repo is up-to-date now and should be more stable.

@David-Healey Looks great! I kid ye not, I'm noodling on my website redesign now and used very similar colours and layout!

Total coincidence! 😂

CleanShot 2026-06-18 at 19.05.42@2x.png

CleanShot 2026-06-18 at 19.05.32@2x.png

@lijas90 Thanks!

4 over 4, that's enough stats for me 😎

I thought at one point the "full mod range representation" has been made available so it covers the full range of lastModValue (like in the above post)

Was I dreaming?

modvalue.gif