Matrix modulation connection is broken in exported plugin

ustk

@griffinboy Thanks! at least I can see that I am not (entirely) crazy

I have solved (or Claude solved I should say) a few issues already but this one is persistent.
I will try again tonight with Opus 4.8 since is good for long task. It might make a difference here reducing the risk of hallucination...

If ever you can manage to get some time trying this snippet, and add it to your list if not already in, it would add even more usefulness to your report by keeping thing as centralised as possible.

ustk

It cost me all my Claude tokens but it's finally fixed!
https://github.com/christophhart/HISE/pull/965

griffinboy

@ustk Thanks for your hard work!

DanH

This post is deleted!

DanH

@ustk said in Matrix modulation connection is broken in exported plugin:

It cost me all my Claude tokens but it's finally fixed!
https://github.com/christophhart/HISE/pull/965

Extended to include Hardcoded Synth:

https://github.com/christophhart/HISE/pull/980

ustk

@DanH Does any of your PR fix a broken modulation connection on preset recall?

When I save a preset with modulations in the matrix, when it loads, the lines are there in the matrix but the modulators are not effective anymore like if the connection was broken...

I can make new connections successfully, previous ones just don't work.

DanH

@ustk my presets seem to load ok with modulation connections still intact. I didn't know this could be an issue, my fix doesn't look at it specifically.

ustk

@DanH Hmmm... don't know what differs... I found a dirty fix:

ModMatrix.fromBase64(ModMatrix.toBase64());

to re-applies the matrix on itself in the postCallback so it remakes the connections. Dirty but working in DAW...

I also found out that:

Engine.addModuleStateToUserPreset("Global Modulator Container");

Was adding a redundancy in the presets so the MatrixData block was appearing twice:

  </MPEData>
  <MatrixData>
    <Connection TargetId="EQ Lo Boost" Mode="1" SourceIndex="0" Intensity="0.8445843446601942"
                AuxIndex="-1.0" AuxIntensity="0.0" Inverted="0"/>
    <Connection TargetId="EQ Lo Cut" Mode="1" SourceIndex="0" Intensity="1.0"
                AuxIndex="-1.0" AuxIntensity="0.0" Inverted="0"/>
  </MatrixData>
  <MatrixData>
    <Connection TargetId="EQ Lo Boost" Mode="1" SourceIndex="0" Intensity="0.8445843446601942"
                AuxIndex="-1.0" AuxIntensity="0.0" Inverted="0"/>
    <Connection TargetId="EQ Lo Cut" Mode="1" SourceIndex="0" Intensity="1.0"
                AuxIndex="-1.0" AuxIntensity="0.0" Inverted="0"/>
  </MatrixData>
</Preset>

but this doesn't seem to be the cause for the broken connection...

DanH

@ustk

Done digging — here's the full picture from the HISE source, structured so you
can relay it to ustk.

The duplicate MatrixData blocks — fully explained

There are two independent writers of MatrixData into a preset:

ScriptModulationMatrix (the object from Engine.createModulationMatrix())
registers itself as a user-preset state manager with the id MatrixData
(ScriptModulationMatrix.h:231, registration in the constructor at
ScriptModulationMatrix.cpp:609). On preset save, every registered manager
appends its own child — UserPresetStateManager::saveUserPresetState()
(PresetHandler.cpp:2440) does a blind addChild() with no dedup check.
GlobalModulatorContainer::exportAsValueTree()
(GlobalModulatorContainer.h:613) appends a copy of the matrix tree into the
module state. So Engine.addModuleStateToUserPreset("Global Modulator
Container") produces the copy inside the block — that's the
redundancy ustk already spotted, and he's right that it's harmless: on load,
module states restore first and the root-level MatrixData restores last
(UserPresetHandler.cpp:678), overwriting it. He can drop that
addModuleStateToUserPreset call unless he needs the container's own chain
state in presets.

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.

Why connections can be "visible but dead"

The matrix UI draws from the matrixData ValueTree, but the audible part is
separate: MatrixModulators and slider cable connections watch that tree and
resolve runtime connections (source pointers into the container's
voiceStartData/timeVariantData/envelopeData arrays, pushed to targets via
RuntimeSource::updateTargets()). The tree restoring correctly guarantees the
lines, not the signal. 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), or
source modulators are bypassed when refreshList() last ran — the data arrays
only include active modulators (GlobalModulatorContainer.cpp:639), and a
missing source resolves to a null mod function (getModFunction hits
jassertfalse; return {nullptr,nullptr}) — connection present, zero modulation.

This fits his symptoms exactly: new connections work because every edit goes
through connect() → callSuspended → full rebuild with fresh pointers, and his
fromBase64(toBase64()) "dirty fix" works for the same reason — it re-fires the
whole remove/add listener storm after everything else has settled, which is
effectively a manual re-resolution pass. It's not even that dirty; it's
re-running the exact same code path HISE itself uses (restoreFromValueTree and
the base64 round-trip are the same function underneath).

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.
Drop addModuleStateToUserPreset("Global Modulator Container").
Check whether the broken targets' source modulators are bypassed/disabled
at the moment the preset finishes loading (the active-list trap above).
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.

Why yours works: Yours creates the matrix exactly once (Interface.js:4), never
registers the container as module state, and your container sources stay
active — so you never exercise any of the fragile paths. None of your three
open PRs touch this, as you said.

If you want, I can build a minimal repro (one container, one LFO, two matrix
objects + a bypassed source) to confirm which mechanism kills the connections
— that would turn this from insight into a fileable HISE issue.

ustk

@DanH said in Matrix modulation connection is broken in exported plugin:

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

Matrix modulation connection is broken in exported plugin

15

2.4k

13.8k

119.7k