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