Matrix modulation connection is broken in exported plugin

[ustk]

@Oli-Ullmann Mmmm... I have them all already...

Do you mean you actually have an FX plugin working with the matrix modulation system? (extra_mod nodes, UI matrixTargetId, etc...)

[ustk]

@Oli-Ullmann @Christoph-Hart Alright I got something!

When setting the hardcoded DLL to "" then back to the original one, the connection is made.
So why it's not connecting at init I don't know...

@Oli-Ullmann Do you set your networks/DLL from script or are they just set in the module tree like I do?

Perhaps I should also add those module states to the presets?

[Oli Ullmann]

@ustk
Okay, I have a working FX plug-in with modulation. However, I control the parameters using HardcodedFx.setAttribute(parameter, value) because I’m controlling multiple parameters simultaneously with a single UI element. So I’m not using extra_mod nodes. Since modulation in an FX plug-in is usually monophonic and I don’t need sample-accurate modulation, this works for me.

The UI element has a matrixTargetId, and I’m using HISE’s modulation system.

I load the HardcodedFX dynamically via script. I haven’t added the module states to the preset. Just the Global Modulator Container.

So it’s possible that it works for me because I control the parameters via setAttribute and the UI elements aren’t directly linked to the effect parameters. But that’s just a guess.

If it helps and you're really stuck, I'd be happy to send you my project without the effects DLLs and C++ files....

[ustk]

@Oli-Ullmann Thanks a lot for the detailed explanation!

This confirms what I see, so the main difference is that you load your hardcoded DLLs dynamically.
I doubt the setAttribute is the origin of the problem because when I force the DLL it then works.
I need sample accuracy so the targetId is what I want.

Now, when you say "I load the HardcodedFX dynamically via script", do you mean once at init or on preset load CB? (or other behaviour to swap them on the fly)

[Oli Ullmann]

@ustk
I load the effects via the ControlCallback of my UI elements using SlotFX.setEffect(String effectName). The UI elements are saveInPreset.

I can also swap the effects on the fly.

What do you mean by “when I force the DLL”?

Here’s some additional information that might be important:
I created the basic effects in Max and then imported them into HISE via RNBO. I then combined these effects further in a ScriptNode network. I compiled this network and loaded it into a HardcodedFX.

[ustk]

@Oli-Ullmann By force the DLL I mean setEffect("") then setEffect("myFxDLL") to force a refresh at init

const var DLLNames      = ["Tube_ClassA_DspNetwork", "Noise_DspNetwork", "EQ_DspNetwork", "Exciter_DspNetwork", "Tube_ClassB_DspNetwork", "Transformer_DspNetwork"];
const var HCModuleNames = ["Tube Input HCFX", "Noise HCFX", "EQ HCFX", "Exciter HCFX", "Tube Output HCFX", "Transformer HCFX"]
const var HCModules = [];

for (name in HCModuleNames)
	HCModules.push(Synth.getSlotFX(name));

const var initTimer = Engine.createTimerObject();
initTimer.setTimerCallback(forceReloadHardcodedDLL);

inline function forceReloadHardcodedDLL()
{
	this.stopTimer();
	
	for (fxSlot in HCModules)
	{
		fxSlot.setEffect("");
		fxSlot.setEffect(DLLNames[HCModules.indexOf(fxSlot)]);
	}
}
initTimer.startTimer(500);

The way the effect are built doesn't matter (I have a mix of networks, C++ and Faust as well...)
Now I narrowed it down, the main difference is that I am using matrixTargetId for full matrix mod control of the parameters. This is where the connection breaks after init.
I tried with Claude different patches but nothing does better than this "force refresh timer" thingy

@Christoph-Hart Is this production safe enough?
There might be a broadcaster that fires after init, that would be a better pal for the situation I think...

[Christoph Hart]

nah, looks hacky, let's solve that properly. can you or your pet robot give me a handoff describing the exact problem? There's some order-of initialisation problem that should be pretty easy to fix once I can reproduce it here.

[ustk]

@Christoph-Hart here you go (all the fixes my pet and I tried until today haven't worked so my hacky solution... Using a processingSpecs BC works too, because the root problem as I understand it is the samplerate not being set before the module are constructed/connected)

HISE bug: extra_mod runtime targets broken in exported plugins

Setup

NUM_HARDCODED_FX_MODS > 0, hardcoded FX modules with networks containing core::extra_mod nodes driven by Matrix Modulators in the FX's modulator chains.
Works in HISE backend, broken in exported plugin (compiled DLL and interpreted both).

Symptoms

Network parameters don't respond to UI changes or preset recalls.
Matrix modulator's Value updates correctly but its output never reaches the extra_mod node.

Root cause

Order-of-operations bug between project-state restore and prepareToPlay:

1. Host loads project state → restoreHardcodedData → setEffect(name) → connectToRuntimeTargets(*newNode, true).

2. ExtraModulatorRuntimeTargetSource::addConnection (ModulatorChain.cpp:2155) builds a SignalSource with sampleRate_cr / numSamples_cr from getSampleRate() — which is 0 because the host hasn't called prepareToPlay yet.

3. target->onValue(signal) stores that zero-rate signal in every extra_mod node.

4. When prepareToPlay finally runs, extra_mod::prepare() reads the stored signal, checkSignalRatio() sees rate 0, and the node ends up in a non-functional state — modulation values never reach the parameters.

In the HISE backend the engine is already prepared when networks are loaded, so step 2 captures a valid rate.

The early-return in HardcodedSwappableEffect::setEffect (if (factoryId == currentEffect) return true;) makes the broken signal sticky — no later preset load triggers a reconnect.

Confirmed workaround

After init delay (so prepareToPlay has run), force-reload each FX:

fxSlot.setEffect("");
fxSlot.setEffect(originalDLLName);

This forces a full disconnect + recreate with a valid sample rate.

Related

Same class of bug as the recent GlobalModulator::prepareToPlay reorder fix ("Fix SmoothedValue assertion when sample rate is uninitialised"), but on a different code path (setEffect → connectToRuntimeTargets, not prepareToPlay).

Suggested fix

In HardcodedSwappableEffect::setEffect, skip connectToRuntimeTargets(*newNode, true) when getSampleRate() <= 0, and call it instead from prepareToPlay once the rate is valid. The scriptnode FX (JavascriptMasterEffect / JavascriptPolyphonicEffect) and HardcodedSynthesiser variants need the same treatment.

[ustk]

@Christoph-Hart I've noticed you attempted to fix this in https://github.com/christophhart/HISE/commit/dc5bb89e68c917505e4a5fa70ff6db8d8a490c22

It behaves better but still not working. we need to cycle bypass/unbypass the modules at least once after init for the effects to work. After that, they are working nicely when loading presets.

[Christoph Hart]

@ustk hmm, you sure? bypassing / unbypassing just calls reset() which shouldn't change the connections...

[ustk]

@Christoph-Hart Pretty sure... But I'm checking with the real develop instead of my custom branch before confirmation...

[ustk]

@Christoph-Hart Ok so due to other another issue that causes an instant DAW crash, I need to stay on my custom branch.

The fix I've made is:

Don't bother the GlobalModulators.h, I reverted it...

But I confirm it's only working when cycling bypass once after init. If it's related to my fix I don't know, because I can't remove it without seeing the plugin crashing the DAW...

[Christoph Hart]

@ustk but that's not the hardcoded master FX - just tried again with a simple dsp network that modulates an osc with an extramod - it initialises the connection correctly. We're talking about loading the project fresh in HISE, right?

But your fix look good, no reason to call this with a samplerate of zero.

[ustk]

@Christoph-Hart said in Matrix modulation connection is broken in exported plugin:

We're talking about loading the project fresh in HISE, right?

No, it was always working in Hise, the issue is with the exported binary.

[ustk]

@Christoph-Hart AI said that it was initillay because Hise already prepared all the processes (or something like this) so modules are well ready to work.
But exported plugins needs to do it at init so prepare to play was not ready yet (or reset with bad samplerate) when the modules are initialising, if it ever make sense to you...

[Christoph Hart]

@ustk ah yes sure, now I'm back on track. Let me just check the current example as exported plugin, but I checked this exact setup back when I fixed it last week.

[ustk]

@Christoph-Hart I expect your binary to crash if you don't have samplerate fix from above. Or something is definitely weird...
I you need I can provide you with my project.

[Christoph Hart]

@ustk no my test never touches that codepath. I'm loading a compiled network in a hardcoded fx - all your changes are modifying the script FX modules. What's your exact setup?

[ustk]

@Christoph-Hart Mmmm... Maybe because I am still using a basic ScriptFX in the project that I don't compile (but I can compile it and use it in a hcfx) that the crash happens without the samplerate fix. I'll try to place it in a HCFX to sse if it's at least stable without the fix.
But yeah that's not related to the HCFX module thing

The setup is:

• FXs are hardcoded modules
• They make use of NUM_HARDCODED_FX_MODS=8
• Extra mod slots are receiving a matrix modulator
• UI components have a matrixTargetId set to the corresponding matrix modulator name of the corresponding hcfx

In the networks:

• there are extra_mod nodes set to the index of the extra mod slot
• Corresponding network parameters have their ExternalModulation property set to Combined

HCFX modules are bypassed from UI buttons.

So at init, the state of the project has been saved with the init preset, that has all modules unbypassed by default. Then other presets are bypassing/unbypassing the modules as you load them. It's only when a module has been cycled bypassed/unbypassed at least once that is actually able to modify the sound

[Christoph Hart]

I'm testing pretty much this setup:

1. global mod => LFO
2. hardcoded FX in master chain with network:
   • 1 parameter, set to combined
   • modulates a osc.freqRatio
   • extra_mod slot has a MatrixModulator connected to the LFO
   • no preset, nothing, just the default state

Load VST3 instance => pitch wobbles. Before the fix it didn't.