xml parsing error, expected '=' after attribute '1'

The cause (found while debugging something else): in hi_backend/backend/ProjectTemplate.cpp, the %STRIP_SYMBOLS_WIN% placeholder sits inside the quoted prebuildCommand attribute:

prebuildCommand="%PREBUILD_COMMAND%;%STRIP_SYMBOLS_WIN%"/>

but what gets substituted into it is itself a set of quoted XML attributes:

 alwaysGenerateDebugSymbols="1" debugInformationFormat="ProgramDatabase"

so the inner quote closes the attribute early and the parser trips on the 1. With the setting off it substitutes an empty string, which is why nobody hits it normally.

Fix: move the placeholder outside the quotes, matching how %STRIP_SYMBOLS_MACOS% is already written elsewhere in the same file:

prebuildCommand="%PREBUILD_COMMAND%"%STRIP_SYMBOLS_WIN%/>

Same fix applies in StandaloneProjectTemplate.cpp (line ~66), which has the identical issue.

Worth fixing since this option is exactly what you need when you're trying to debug a crash, it's what was stopping me from getting usable symbols in the first place.

Best,
Jon

I've been building a multi-mic drum kit, and for days it randomly crashed my DAW whenever I played fast, busy patterns (quick hi-hats, fast toms). It happened in both Ableton and Reaper, but never in the HISE standalone, which is what made it so hard to pin down. Windows reported heap corruption (0xC0000374), and the denser the MIDI, the faster it died, sometimes seconds, sometimes 10 minutes.

I spent past Sunday debugging it with Claude Code, mostly to read the crash dumps for me.

Things we ruled out first, in case it saves anyone time: my scripts (it still crashed with everything disabled), round-robin, choke scripts, voice limits, monoliths vs streamed samples, CPU affinity, deferCallbacks, and the number of samplers. It even crashed with a stripped-down project and an empty script, so it clearly wasn't my code.

We eventually ran it under Application Verifier (PageHeap), which turns the delayed heap corruption into an immediate access violation, and symbolicated the dump. Here's what Claude Code found, pasting its explanation:

The crash is in hi_core/hi_core/MainControllerHelpers.cpp, in DelayedRenderer::processWrapped.

When the host sends a buffer larger than the prepared block size (the "FL Studio violates the block size" workaround), the function chunks the buffer and calls itself recursively — passing its own member delayedMidiBuffer as the midiMessages argument:

processWrapped(chunk, delayedMidiBuffer);   // passes the member

So inside the recursive call, midiMessages is delayedMidiBuffer. Then in the shortBuffer paths:

MidiBuffer::Iterator it(midiMessages);   // iterator into delayedMidiBuffer
delayedMidiBuffer.clear();               // clears the buffer being iterated
for (auto& e : shortBuffer)
    delayedMidiBuffer.addEvent(...);     // and reallocs it
while (it.getNextEvent(m, pos))          // dangling iterator -> use-after-free

The clear() and reallocating addEvent() invalidate the iterator, which is then dereferenced. It only appears in a host because the standalone uses a fixed block size, so that recursive path never runs.

The fix (give the recursion its own buffer so the two can't alias):

// MainControllerHelpers.h — next to delayedMidiBuffer:
MidiBuffer chunkMidiBuffer;

// MainControllerHelpers.cpp — in the oversized-buffer branch:
chunkMidiBuffer.clear();
chunkMidiBuffer.addEvents(midiMessages, thisOffset, numThisTime, -thisOffset);
...
processWrapped(chunk, chunkMidiBuffer);   // was: delayedMidiBuffer

There are two shortBuffer paths that clear/regrow delayedMidiBuffer while iterating midiMessages, so this closes both.

Result: my full kit used to crash within seconds or minutes. After the patch it ran +25 minutes in Reaper with PageHeap still on (so any remaining bad access would fault immediately) and +25 minutes in Ableton on the exact project that always crashed. No crash.

Minor side note it also spotted: alloca(numChannels * sizeof(float*) * numChannels) in the same function allocates numChannels² — harmless, but looks like a typo.

Hope it's useful information. Thanks for HISE!
Jon

Claude does a great job of making and testing bug fixes, but only Christoph really knows where the dragons are hiding in the code! 😜

*I used ChatGPT to help format this bug report so that it's written clearly and thoroughly.
I apologize for the "Ai aesthetic" residue that leaves behind.

Branch: I'm on the latest HISE develop branch, pulled and compiled today
OS: Windows 11
Juce: I'm using Juce 6 (version: 6.1.3)
Project flags:

NUM_HARDCODED_FX_MODS=8
NUM_HARDCODED_POLY_FX_MODS=8

Summary

I think there is a bug in the hardcoded Master FX "parameter-modslot" path.
I didn't want to post a report until I was sure it wasn't my own mistake, but I've been reading the Hise source all day and testing different C+ nodes and in the end I concluded this might be a bug:

If a third-party node exposes a parameter modslot with ConnectionMode::Parameter , loading that node into a hardcoded Master FX forces the modslot parameter values to get set to the top of their ranges (and stuck there).

This is not a small issue. For DSP nodes it completely breaks effects, and means you can't use any c++ nodes that have modslots inside monophonic hardcoded master FX.

I like almost all of my c++ nodes to have modslots so that they can work easily with hise modulation and the matrix modulator. This bug means I have to make modslot and non-modslot versions of every effect, so that I can load the modslot version into poly contexts and the non-modslot one into mono contexts. And then for the mono nodes I have to use a different modulation scheme. Messy.
(unless I'm misunderstanding something).

How I found it

I was testing a compiled third-party DSP node.

The same node behaved normally in a ScriptFX context, but in a hardcoded Master FX it produced broken / glitchy / extremely wrong output.

When I removed these project flags and rebuilt, the hardcoded Master FX version started behaving normally again:

NUM_HARDCODED_FX_MODS=8
NUM_HARDCODED_POLY_FX_MODS=8

So the issue appears to be tied to hardcoded FX modslots.

Disabling those flags is not a usable workaround for me, because then hardcoded modslots would be unavailable project-wide.

Minimal test

I made four tiny diagnostic third-party nodes.

Each node has one parameter:

Parameter_name: ProbeValue

Range:   0.0 to 1.0
Default: 0.25

Each node outputs a tone whose gain follows ProbeValue.

Expected result: quiet tone.
Bug result if the parameter is forced to max: much louder tone.

Each node exposes the same parameter slot:

modulation::ConnectionInfo slot;
slot.connectedParameterIndex = ProbeValueParameter;
slot.connectionMode = modulation::ConnectionMode::Parameter;
slot.modulationMode = modulation::ParameterMode::ScaleAdd;

I tested four variants:

Griffin_ModSlotProbe_NoHandle
Griffin_ModSlotProbe_WithHandle
Griffin_ModSlotProbe_FrameHandle
Griffin_ModSlotProbe_ModNodeHandle

These check whether adding the following details would fix or change the behavior:

• no handleModulation() function defined
• handleModulation(double&) { return 0; }
• block processing forwarded through processFrame() from process()
• isModNode() == true (yeah, I know that's not going to do anything)

Result

In hardcoded Master FX:

NoHandle       left loud, right silent
WithHandle     left loud, right silent
FrameHandle    left loud, right silent
ModNodeHandle  left loud, right silent

The left channel becoming loud proves ProbeValue was driven from 0.25 to 1.0.
And the right channel staying silent means handleModulation(double&) callback was not called.

Expected behaviour

Ideally, a hardcoded Master FX parameter modslot should not push a node parameter to its maximum value simply because the slot exists.

If no meaningful modulation value is active, the parameter should keep its current/default value, or the slot should not be treated as connected until there is an actual usable modulation connection.

Current behaviour

Currently, with hardcoded FX modslots enabled, a third-party C++ node exposing ConnectionMode::Parameter can get seemingly spammed with max-range parameter values during rendering / stuck at max value (moving the parameter doesn't unstick us, the parameters are stuck to max).

Why this matters

I'm assuming that HISE nodes are intended to be modular.
If that's true, then a node that is poly-capable, or a node that exposes modslots, should be able to function in a mono hardcoded Master FX context too.

This is also inconvenient for my shipped products. A HISE user can load one of my nodes into HISE and get broken DSP because the hardcoded Master FX modulation path corrupts parameter values.

The result of all this is that ConnectionMode::Parameter becomes unsafe for third-party hardcoded Master FX products.

Suspected source bug

The Hise algorithm seems to do something like this:

HardcodedMasterFX::applyEffect()
  -> extraMods.processChunkedWithModulation(rd)
  -> ExtraModulatorRuntimeTargetSource::handleModulation(...)
  -> ModChainWithBuffer::getOneModulationValue(startSample)
  -> rd.handleModulation(pIndex, mv)
  -> parameter range convertFrom0to1(mv)
  -> p->callback.call(value)

The important part is in the hardcoded Master FX context, with no active voice state, getOneModulationValue() can return an inactive/default modulation value of 1.0f.

That normalized 1.0 is then converted through the parameter range, so the node receives the parameter maximum.

Request

Could the hardcoded Master FX parameter-modslot path be changed so inactive / unconnected / not-yet-valid modulation does not force parameter-mode slots to max?

post script: a similar / related bug exists in the Hise synth group, I will write a report on that after a bit more investigation.

Christoph, Thanks for all your hard work🫡

P

Is this a known bug?

It's by design.

I had Claude implement a fix.

gclfo.gif

He can drop that
addModuleStateToUserPreset call unless he needs the container's own chain
state in presets.

Yep I need it, so I can't remove it, then 2 MatrixData blocks it is and will be...

Two root-level blocks means two live ScriptModulationMatrix instances at save
time. Unlike most Engine.createX calls there's no caching — each call to
Engine.createModulationMatrix() constructs a fresh object and registers a
fresh state manager, even for the same container ID. So ustk should search his
scripts for a second call (a second script processor, an included file, or a
call inside a function that runs more than once). Restore-side it's mostly
benign (each manager restores from the first MatrixData child via
getChildWithName), but it's the smoking gun that two matrix objects are alive
— and two objects both performing remove-all/re-add restores on the same tree
is exactly the kind of thing that could leave the runtime side confused.

Nope, no smoking gun here.

The signal path goes stale if:

the container's child modulators get rebuilt after the matrix restore
(remember MatrixData restores last, but postPresetLoad, sample preloading →
prepareToPlay, or anything his preset postCallback does runs after that),

something worth investigating, especially prepareToPlay that has been modified recently to fix another matrix bug...

Practical suggestions for ustk

Grep the project for createModulationMatrix — ensure exactly one call, in
onInit, stored in one const var. If duplicates persist in fresh saves after
that, an old instance is being kept alive.

Always had only one here

Drop addModuleStateToUserPreset("Global Modulator Container").

Nope, need it for what it does. And anyway I tried without and it doesn't seem related to the issue.

Check whether the broken targets' source modulators are bypassed/disabled
at the moment the preset finishes loading (the active-list trap above).

Nothing's bypassed

Note whether broken targets are MatrixModulators in mod chains vs.
script-slider parameter targets — they use different listener paths
(MatrixModulator::onMatrixChange vs MatrixCableConnection), which would narrow
it to one code path for a proper bug report to Christoph.

Only MatrixModulators in mod chains here, not direct parameter modulation

Screenshot 2026-04-25 at 00.59.27.png

AI fixed it by adding a samplerate > 0 safety. This is confirmed working in main project, bt the same assertion fired this time for master FXs. So I have made the same exact safety and all is good (for this assertion at least...)

Now a new one with MPE connection... Not done yet but at least I progressed!

This, or something similar to it... has come back in the latest develop, sha: 6446c4ab64ba27c189f5d1ad31ecace25d02a292

I've cleaned my build directory, but still get it.

If you then want a modulation to go from -6db to +6dB, you just leave the knob position at 0dB and add a bipolar modulator with +6dB intensity.

Little bump and also, would this work for nonsymmetric ranges? I ran into one today where I'd like to go from -12db to +3db.

Also there is still this bug with artefacts and voices overwriting each other: