@David-Healey said in HISE with Claude:

I'm not sure there is any security advantage to use a desktop app rather than a web one

I think he means if you run Claude on a dedicated machine there will be far less personal info on that machine to get leaked either way.

@resonant Do you use git to manage your project repos?

@David-Healey Same page:

Deprecations in Xcode 27 Beta
The following items have been deprecated or removed:
The minimum supported deployment target on macOS for the C++ standard library has been increased to 11.0.

@David-Healey Claude says:

the libc++ minimum deployment target was raised to 11.0, which is a hard toolchain fact — a C++ codebase like HISE cannot target 10.14 or 10.15 from Xcode 27 regardless of distribution channel

So 10.13 to 10.15 etc are completely out for Xcode 27, but can it build for 11 (even if 12 is the minimum for App Store) is still an open question.

@David-Healey Hope you're right!

@David-Healey said in Why is macOS minimum 11.0? (And beware of Xcode 27!):

Where do you see this?

Xcode 27 Release Notes https://developer.apple.com/documentation/xcode-release-notes/xcode-27-release-notes

The relevant line is under the "Intel Deprecation" section (issue ID 162138432):

"Xcode 27 will only install and run on Apple silicon Macs. The macOS 27 SDK supports back deploying Universal (Intel and Apple Silicon) apps to macOS 12 and later. Intel development is still possible with macOS versions that support Rosetta like macOS 27."

@David-Healey said in Why is macOS minimum 11.0? (And beware of Xcode 27!):

I noticed it too and I changed it in my fork a couple of months ago.

And no ill effects so far?

@dannytaurus Just looked into Xcode versions and requirements.

My installed Xcode 26.1 will build back to 10.13 but Xcode 27.0 changes everything.

Looks like Xcode 27.0 targets a minimum of macOS 12 - which makes sticking on Xcode 26.1 a necessity for now.

Xcode 26 can build for macOS 10.13 targets, but Xcode 27 moves that way up to macOS 12!

Also means HISE will need to bump up to macOS 12 for compatibility with Xcode 27+, so maybe I just get on the 11+ ride now?

In commit 837ae1404 (19th April 2026) the minimum macOS target was changed from 10.9 to 11.0 but I can't seem to find any compelling code reason why.

@Christoph-Hart Was this just a preference? Or was there some code/architecture reason for the change?

The jump from 10.9 to 11.0 is not small. It cuts out quite a few older systems:

┌─────────┬─────────────┬──────────┐
│ 10.9    │ Mavericks   │ 2013     │
├─────────┼─────────────┼──────────┤
│ 10.10   │ Yosemite    │ 2014     │
├─────────┼─────────────┼──────────┤
│ 10.11   │ El Capitan  │ 2015     │
├─────────┼─────────────┼──────────┤
│ 10.12   │ Sierra      │ 2016     │
├─────────┼─────────────┼──────────┤
│ 10.13   │ High Sierra │ 2017     │
├─────────┼─────────────┼──────────┤
│ 10.14   │ Mojave      │ 2018     │
├─────────┼─────────────┼──────────┤
│ 10.15   │ Catalina    │ 2019     │ 👈 32-bit support dropped here
├─────────┼─────────────┼──────────┤
│ 11.0    │ Big Sur     │ 2020     │ 👈 Apple Silicon introduced here
└─────────┴─────────────┴──────────┘

A percentage of my customers are on pre-11.0 systems, and all my existing Maize Sampler-based plugins support back to 10.14, so I'd like to change the 11.0 to something lower in my exports.

Anyone know of any reason why this would cause problems?

Side note: @David-Healey, you mentioned here that you use 'HISE defaults', which are now 11.0, but the Rhapsody website says 10.14+. Just wanted you to know you might need to change your website wording, if you've exported/updated the player since April this year.

@ustk Oh yeah, of course. We already discussed all that previously in other topics. I must be delirious!

@Chazrox Great work!

You do realise at some point you need to combine all these features into a full UI builder?

Quite a task, but it's the road you have chosen for yourself!

@Lindon @HISEnberg said in Measuring plugin delay times....:

Possibly some hosts are not going to support dynamic changes to the latency reported

This might end up being the biggest issue of all. Even if you accurately record all those permutations and combinations of latency, if the hosts don't play ball with dynamic changes to latency values you're SOL.

EDIT: nonsense, as oust points out below

@HISEnberg said in Measuring plugin delay times....:

Console.print(Engine.getLatencySamples);

Unfortunately, all that does is show you the value you already set with setLatencySamples(), it doesn't get the actual latency of the current configuration.

@resonant I don't think the demand is there yet. None of my Windows customers has ever asked for an Arm version.

@voxuer1 Doesn't look like there's anything in the oversampling container.

Is the Kanai42110 node the RNBO effect? If so, select it then choose 'Wrap into oversample4' from the Edit Node Properties window.

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

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

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

@griffinboy That's incredibly impressive!