@DabDab @Fortune arguing in a forum is totally pointless guys, and I'm sure the rest of us would prefer not to read any of it. Everyone be nice and civil towards eachother please and we can all carry on making super plugins... :)

Here are Wheel sliders I've made in LAF. Fill your boots. Thanks to @ustk for the broadcaster bit at the end.

HiseSnippet 2463.3oc6Z0sbZjbEdPVrwP1M0tUsWkq5vEof0XLCHzOQYqUBIPhxHAQfr2Jt7psYldfNZXFpYFj.6xo1KxySdExiPdERdCxavlyo6YX5QfkkUVeUDUoeltO+7c9sOS0z0y0f4665okJa+4SXZo97z8l6DL5fQTtiVqC0R83zu73FMZ2Sq97ITeeloVpTO5Hb2TYVWS74+7c0o1TGCV7RZZuvkavZyGyChWs6dOmaa2jZx5yGqP8F60xv04.Wa2o.RdT5xZSnFWRGxNkhjsVZsio9izR8Mo0MnaMvhMPefk4VVU0Mzqr016TY.0Z.cmxT1fMLFrsktkVpOqgIOv0qW.Mf4qkZ85tly6Mx8ZGoBdA2mOvlgOnq0Czrb4lt1lnIhqpcvHtsY2HWjuFHktwNrGIcXec5S3l7EqG639RwFjXNTcfoVKI7dTB3oqBuxJvaEPJkBjVWBouJcOCO9jf3cP77qS2xIf4YQg3jJTjzps1E+1zG3BT3DTZL8RVSO3gEbjeyxkKRfeUX2rYgXke.4JpG4jNGJxNtn89MIeKIheCOFXVscMn1sccubeGylLlcdjWUNJ4wFx8AMzbpiQ.20IeNSO50m4FP8l2ylax7xUjXEs4vhD2A+kBYea1LO6YOiX45QnDeAYDe9aXjJkmsY4r3t.P7csYkl3wcBxG3gV.xKffLYIvGD7y.DWaWBHJ8msAw0hDLhEIuq4lAiJQHm6yrlZS3Vj4tSIFinNCYB5DDrPTWOBruWhKAxTu7tDTpD4BgBlZDLkZKoDDb+QbehMidEymTaxLjJeHomQXbfZzfLYkVHeJHV.+knficWwpheAJ4ET6o.hbIS8YBWBpqwtWwFCAhHcOx0i+FH1.52l6.Z7YRbPnNlDYvhLgZZxcFBhZhX4AtAAtik5JChg.HrX22CPrM53zkFoX0kUHHAaVQv.88ERLT5RIIEcWpIHmJ6RBsjIdrqPQH4k.nxXDBnPfH37JfCLPV5JgY+Mpfp.4IwRd2H+yBtTXCB3aVc6pEtM9EL2kGXL5kBOEjJa.NMtwH.f9DOQh.XskepPVwwDTgNSG2V3m+VnjQjgAqL.hp.C2LVrfI7odPJ.ZyB+BvlITdfMVICXAWyXNgrD5FGJ6XBTWdVy5k2t7N5RsUG5dNzycJDFkjHYPDyU4oY4las4NgQx9PbyPtYXTTZ47.elskTB9ifd2IkP8x6TolTBGR8tTPBZBFJJ1lObTfBaU2to3ijs13tHKLKKlQvBNiBgJVSS33CwxCK4yBkX9H+PgcC2xBn5LPR4iJYvFOgBSZSJhDJcFvHl.zWRvx+3WZfMP9xR+UyJRflhw09EIzWU80uVzjIyBc0Cpj8ylQUvX3pxFUpUodAEO2Qdr4HcXOvWv7B3X6SHdmupPOah8dW015aFuejYdHPjHFdhqoDFwIaKYmJ4EQh.6jjGCcbLfsK7m+3hrZ3om7jBBxdq32QYvyw5rJPUEu.4ojq1MTUR0gv93E49BfOuHYlp+CJ.mE5leWhlbGKaInD0dJACCDtivHcMMCqvXlgc3fvJdJlR2njgfaXyYVI.qUEsiUhRx6ikZe7rr0GOK67dYYQtGGZpuvw4EcD10TnEKOf.NQl7vhEkeG4AUtPGX+3RuUVNbMJ5B6pPypP3lgHDPUkhxiKgUpnjiFoORmqXd1z4j73IE+9vlvKZjfGFYGhwB2HANRDXeg7uB6GousdM8ZP0fnln7rxgeDqnWCJNQU2C6iQ56N4V5Xb6ZJgbqB+Qo0nXsMKmPW0iON8+Y0UtnRC0jFlHXtJCaEMqDLcq5cY0rjKcCgYFqZJDqBBfbNqodhAYLgYZWEXPYohlpBAknr+CkC65HlsH7zpUjGuxtcqJM9CjB+Th9MKzfezuIdqimS.Q5YjdS8D8oJB0YTwoZPioAyWjGGdTm+c7HGwTwniiVD0Z1Hcl8cX4TzT2CQoLdhqC7P9bQCZmq.J9klEWcN7jyz2sU+CN9ibp9j77vb8OLW+cdt9HWwCCo+vP5OLj9CCo+vP5OLj9CCo+vP5+ewP5wyM+dFSO4f0nfvQj2+79cd5YM5e9YmpLtNoeGxIsN7v1MHc6zqU+VcNEbJc5h+y9swYSOd+SedOjriNqwQjy60+4jlcNCVuUueGJYRcOWpoAEmcmXxr3NbbBc0WNXwvV8cmZL5hAFvwIMbFBghv2OPQD4wSdxwMy8GH4VlwbEwcodC8g8eUNiHuB7pA4DSLl60BJBnRJdszQBnjFD.yPhmdHmrDu0irKqfRR556tvgehKLMcCjG+7uR04+ZPmGXyMtzmzwwdNBgbIUlE2CbA13q03v7Vo1LMaGtc9bnDFap9VNKruhRTKdeGnVIu3oRiQnc9jBYy.KmYAwXRg3UAxus9N5kpgGcnrq7EWLw2AKy6j9mHEBEdm5Fv53jWnorvg02bKKqUtGlp54ZaC1wp1Fu5Nuaiw7xS4KRDCxufPsTqm7NuR+9uyK0qjyPV4nPnqSKHwryDly66h5zBK2zzRsVHp.RCD2N1uI71wjuHpF2TKU1zQuNrl.yp2io1cf+OOcbtTRI7S+7+XOsyacHMfh2UWHr.nNAGND8BoNjcE2fIu4tLoOj4eIzuDbVKxZ0R8Y2EjOKF0A6MO9Am8DmqqdaqiXXKt3UNcOMEsk8tYmJ5i+QquwzYwtn+4dPYyjdvq5qdmxi4lvQJcc8E8fTcnPmI5TaYcQBGshQ7qjFwWDZDsoCX1Ba3woE+utB9+IpB9+Q+8BXyBtgwlzj.FtoIswGk1qnn8+0jUock.6Mbm+vpz8xWB7WlFdqho1zfj2IMdy8gafdU0KBFurWGvaOWMJ7K1EUeWg3WkVzac0XbsUfQrF+S.FCud+uHcCwT.w.b8zM+9OM2ku1YtSwAONgF3wgDjzmNcbOXRCCFncGGlM1zL0ZXOI4ykwmQOPOlio3geF9DtoN9bpvM0i1TaL0vy8BCYSM7KPviEq.XxQ7ksHS5SvmI5K2JDpH4WXXjTTKwXk6KiUuuLtw8kwZ2WF279x3V2WF29CyH90MY+ovKvHKahO5CNIGRjUePlXDlnDI.kje0uqHB82BdSzYQDBI5dApHogioZOilSssWhFbwaPWuKYWq9rPmfYhq81u9uez+9M+suCPM7hmAHn2Jc0sJ4zeymu8A0OZ3AkJ8hFMokOWu6zMrMtr0Q3Ok1+vteO+O8x+r94Mg+2pToRZ6G.kSClFvRzUskTthJXsawQ8W+D4nvi8tKNJjtayQEs1urNpDG9kvUcR2FhoYRkpgCEZqIW8+xpPPhg

Thought I'd leave these here in case anyone also wants to post hilarious customer interactions to make us all laugh

followed by:

@Christoph-Hart HISE_NUM_STANDALONE_OUTPUTS Error // Channel Amount Mismatch on every start

https://github.com/christophhart/HISE/issues/692

This one has been driving me nuts

Appreciate it doesn't happen for everyone but I have to re-set my midi controller in the Hise settings every time I open Hise!

@Christoph-Hart

Scriptnode Notch Filter has the incorrect display graph (shows Bandpass) and neither it or the bandpass filter graph respond to Q value changes. Currently impossible to use either with an External Filter Slot on the user interface...

https://github.com/christophhart/HISE/issues/703

Feature Request: Draggable ADHSR Envelope (like the curve EQ and Tables etc)

I think we keep this guy just for the positivity

@jupe 'bitchbend'

@obolig it's a good post. Had a similar experience and after some digging back in 2020 I came across HISE (not so much digging required these days!).... It was instantly intuitive and the members on this forum more or less taught me how to script. Many thanks for putting it together @Christoph-Hart

For anyone interested I released a new effect plug-in this week... The MOD-EQ-1

Check it out here:

https://dhplugins.com/mod-eq-1/

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

1. 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.
2. 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

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

@Chazrox https://forum.hise.audio/topic/14184/juce-submodule-psa?_=1780482119841

@Orvillain Have you tested with zoom factor? Had issues with this...

@Orvillain There should probably be an option for either. There's also the labels to think about as well... It's not a one size fits all solution.

@Orvillain because my draggers (depth knobs) are always visible. All of them. So if I switch panels then the draggers still sit on top of the new panel. Make sense?

@Orvillain any panel that you want to appear at any point, let's say a floating mini preset menu, or a floating tooltip, or a page, the draggers will sit on top of. However mine are persistant, rather than appearing on hover, so that changed the dynamic a lot.

@Orvillain I found the scenario!!

@the-red_1 yes, something broke in a recent commit. If you open the dsp network xml file you will be able to enter the max gain value in there.