Latest version of HISE breaks existing presets....

[Christoph Hart]

The code that sends the macro value as plugin parameter is already in HISE 4.1.0.

What changed in that commit is that HISE registers a plugin parameter at index 0 for the UI control (basically what the compiled plugin is doing) so before that value was sent out to nirvana (or the DAW if HISE runs as a plugin), but now it loops back to the first UI component that is defined as plugin parameter.

HISE_MACROS_ARE_PLUGIN_PARAMETERS=1

This solves the problem my registering the 8 macro controls as plugin parameters, so changing the first macro just changes the first plugin parameter (=macro) => no op.

So the proper fix would be:

if USE_BACKEND && HISE_MACROS_ARE_PLUGIN_PARAMETERS==0 => don't send the macro value as plugin parameter

if USE_BACKEND && HISE_MACROS_ARE_PLUGIN_PARAMETERS==1 => send it

Note that the compiled plugin is completely unaffected by this. All it would break is the behaviour of HISE to send out macro values as plugin parameter without that flag.

[Lindon]

@Christoph-Hart do you want a copy of my project to test with?

[Christoph Hart]

@Lindon yes but please give me some guidance on what to look for. Also if you can dumb it down so I don't have to download gigabytes of samples, would be great.

[Lindon]

@Christoph-Hart I know its a long way back but if you look at the first three or so posts in this thread I think that does dumb it down , and explain exactly whats happening.... let me know if thats not enough, I can send the project without the samples - as Im pretty sure they wouldnt be needed to see this problem anyway....your call.

[Christoph Hart]

@Lindon yes send over.

So your particular problem is that plugin parameters + macros + preset recall is not working (mastervolume +30 = 1.0 normalized)?

[JulesV]

@Christoph-Hart When I open a project previously saved in a DAW using a plugin compiled with 2024 commit HISE (I only tried in Reaper and Logic on macOS), with the same plugin compiled with new HISE, the saved settings are not loaded in the DAW. The plugin is loaded with the default state.

[Christoph Hart]

@JulesV Are you using plugin parameters? And is this affecting only controls that are linked to plugin parameters or all values?

[JulesV]

@Christoph-Hart In the plugin, all controls are set to plugin parameters. Also most of them are set to isMetaParameter. And all controls are initializing with default values

[Lindon]

@Christoph-Hart said in Latest version of HISE breaks existing presets....:

@Lindon yes send over.

So your particular problem is that plugin parameters + macros + preset recall is not working (mastervolume +30 = 1.0 normalized)?

yes that about sums it up - I will send it over...

[Christoph Hart]

@Lindon Would it be possible that the single error that both you and @JulesV are experiencing is because of a drift between the plugin parameter value stored in the DAW project and the internal preset?

Whenever you save a DAW preset, it will

• create a .preset containing the plugin state (exactly as if you would save a user preset)
• store the values of all registered plugin parameters

and dump that into the binary data blob stored as DAW project.

In a "healthy" plugin, these values should not drift - the plugin parameter value is the value stored into the preset. But if there is a mismatch (either because of a new plugin parameter that wasn't stored or because of some initialisation error at startup, it might create these issues.

[Lindon]

@Christoph-Hart I think not. As this is showing up in HISE as well as compiled plugins.... see my posts at the start about using Console.print to tell me whats happening...

Sent you the project link to your email

[JulesV]

@Lindon Is it fixed on your side?

[Lindon]

@JulesV I haven't heard back from Christoph so I assume not...

[Lindon]

@Christoph-Hart - is there any chance of ever getting a fix for this?

[dannytaurus]

@Lindon Without me having to read 4 pages of posts about this, what's the outstanding issue?

[Christoph Hart]

I've let the robot loose on it. "Read this topic and propose a fix. Make no mistake."

[Chazrox]

@Christoph-Hart said in Latest version of HISE breaks existing presets....:

Make no mistake

[David Healey]

@Christoph-Hart said in Latest version of HISE breaks existing presets....:

Make no mistake

Proceeds to hack huggingface

[dannytaurus]

@Lindon Looks like there's a related commit for this, have you tried with this commit in place?

• e1fb54695 (May 2026) — "fixed macro controller controlling first plugin parameter control inside HISE"

[dannytaurus]

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

1. 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.
2. 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.

1. 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.
2. 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.
3. recursive, sendToHost and the global enablePluginParameterUpdate then become deletable. (deferNotifyHostFlag can stay - batching host notifications is an optimization, not a correctness guard.)
4. 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.