@dannytaurus said in Latest version of HISE breaks existing presets....:

@Christoph-Hart Here's what 'my' Claude says:

The pattern so far

Since a92a701de (the unified automation base class), every automation actor - host parameter, macro, MIDI automation, UI widget, script, preset restore - is both a reader and a writer of shared values, connected through the dispatch library. The regressions since then have all been the same bug wearing different hats: a listener can't tell an echo of its own write from a real change, so it feeds the value back around the loop. Each fix so far suppresses one specific edge:

633626eeb - gate refreshParameterValue() on enablePluginParameterUpdate, and switch MIDI automation's setAttribute from async to sync notification e1fb54695 - carve the backend macro-to-parameter-slot routing out behind HISE_MACROS_ARE_PLUGIN_PARAMETERS

Alongside the pre-existing guards (recursive, sendToHost per parameter, deferNotifyHostFlag, the exclusive-mode conditionals in loadUserPresetInternal()), that's now seven or so overlapping mechanisms all answering the same question by inference: "is this change an echo?"

Why I think flags can't fully close this

Two structural limits:

The global flag suppresses the wrong scope. enablePluginParameterUpdate is one boolean for all parameters. While parameter A's update is dispatching (flag false), a legitimate concurrent change to parameter B hits the early return in refreshParameterValue() and is silently dropped -the internal value updates but the host never hears it. I suspect this is exactly the DAW-project-vs-internal-preset drift you were hypothesizing about at the end of the thread. The guard isn't just failing to fix that bug, it's a source of it. Scoped guards can't survive deferred dispatch. A ScopedValueSetter protects a call stack, but this system defers across threads by design. By the time an async-queued listener runs, the guard is long restored and the echo sails through. That's why 633626eeb had to change MIDI automation to sync notification - to drag the callback inside the guard's scope. Changing threading semantics to make a boolean reachable feels like the approach hitting its ceiling.

Proposal: make provenance explicit

The class structure from the rewrite is good - I'd keep all of it. The change is to what a notification is: value plus origin, instead of value alone.

Add a small source token (Host, Macro, MidiAutomation, UI, Script, PresetRestore) to SlotSender::sendChangeMessage() and the listener callbacks, threaded through CustomAutomationData::call(). Because the token travels with the queued message, it survives deferral and thread hops - the thing no scoped flag can do. Each writer passes its own token and ignores incoming messages carrying it. MacroPluginParameter::setValue() writes as Host and skips Host-tagged notifications; same pattern in HisePluginParameterBase, MidiControllerAutomationHandler, CustomAutomationParameter. recursive, sendToHost and the global enablePluginParameterUpdate then become deletable. (deferNotifyHostFlag can stay - batching host notifications is an optimization, not a correctness guard.) Preset restore becomes a first-class source: "macros must not clobber freshly restored widget values" becomes a one-line filter rule instead of an ordering convention plus exclusive-mode conditionals, and the MIDI sync/async choice stops mattering for correctness.

For precedent: JUCE's own ParameterAttachment solves the identical loop the same way - each attachment filters its own echoes at the attachment point.

Hmm, I must give this Claude malarky a bit of a go......

@Kalliopei why not use a peak meter floating tile instead of a panel?

@eschirle that message is saying you haven't built HISE with IPP

@LUIS29

I can give the mac compiling a go and try if it compiles ok.
No guarantees. You need to codesign it afterwards thou on every mac machine it is running.
it's not too hard, just running some code through terminal on mac.

@David-Healey oh my god. thank you really. i'll wait for solve. good night that kind man

@Christoph-Hart
Yes, you're quite right, that probably is the real cause.
Still a bit weird, since an older install worked as should.
Although it was the one with an .pkg, or was it .dmg, installer from the website,
so that might have to do with it as well.
And as the admin and the sole user of the machine, the writing rights should've been ok.

You just need to run a command to tell the system where xcode is.

Make sure your xcode app is in /Applications (not the user folder, the system one). Then run the command

sudo xcode-select -s /Applications/Xcode.app/Contents/Developer

I was not planning on making another one today as I am deep diving into glsl, but got an idea and had to flesh it out. 🥧

So this is "KOMPRESS"

Minimal with a central large knob, Figma design.

This one uses quite a lot of blur for the glow on the black knob which is a HISE problem but since its stationary on the knob , I could move only the line indicator on the knob and just either print the blur or if keeping as vector see if I can get away with one blurred component?

KOMPRESS UI

KOMPRESS Final.png

KOMPRESS DAW

KOMPRESS DAW.png

KOMPRESS D16:9

Wide AD.png

KOMPRESS 4:5

Long ad.png

@Christoph-Hart haha thanks man! i dont know what to say. im too new at this stuff, its all hieroglyphes for me.

@combamusic Thank you!

@Jeetender That is strange. Didn't you see the latency reported in the DAW?

Removing the module that causes latency is not a viable solution. Once you know the latency of your plugin, you should just be able to report it to the DAW with this method.

So it's not an "in plugin compensation" but telling the DAW "hey, I introduce this amount of latency, please compensate for me" (in which "this amount" is your job to determine)

@ospfeigrp You can draw that kind of thing using look and feel or paint routines, you'll need to get familiar with drawing arcs.

I figured it out.
In order for the matrix modulator to properly work I need to set my filter cutoff to 100%.
Then use the "Value" knob in the Matrix Modulator module as the main Filter Cutoff knob.
I was using a 2nd UI knob that I wired to the Cutoff, but the Matrix Mod module expects you to use "Value" as the main knob/slider and "Intensity" as the modulation depth.
Setting the filter to 100% ensure that both "Value" and "Intensity" have control over the full range of the filter.

@griffinboy sick isn't it? I wonder myself how I got there, but then again given Idid nothing else for the past months than spend every free hour on this... it's a bit pathetic ;))) I need to start having a life again lol

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.

@Orvillain said in Why I'm not making a Windows installer (nor code-signing):

Interesting, I wasn't aware of that. More details would be lovely! Private message if you need to :-)

https://forum.hise.audio/topic/14949/why-i-m-not-making-a-windows-installer-nor-code-signing/13?_=1785506496174