@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
