Matrix Modulation System - Last Call for bugs fixes & changes!!

[DanH]

@Christoph-Hart Ah ok, this does actually work in this latest commit Didn't before, all good, bravo

[DanH]

@Christoph-Hart However it doesn't look like LFOs assigned to a parameter are having an effect yet....

[ustk]

@DanH In this case I think the parameter should just be a normal parameter without ExternalModulation
The way I understand it, a scriptnode parameter that has ExternalModulation set shouldn't be connected with a cable.
Just set the target for the corresponding UI knob

@Christoph-Hart if I'm right then the connector (and any previous cable) should be removed or disabled and greyed out.

[ustk]

@Christoph-Hart For the delete button, I can't seem to actually set a background color like I do with other elements.
background and background-color are both setting the icon color (be it the original one or a custom icon in .delete-button::before)

[ustk]

Why do I see both the controls that have a matrixTargetId and the actual Matrix Modulators (with the _MM suffix) in the drop down?

Should they be named the same not to appears as duplicates?

[ustk]

@Christoph-Hart Bump bump

What should we do with this?
Is it on your side or is there a specific procedure not to show the Matrix Modulators in the list?

[Christoph Hart]

The matrixTargetId is the ID of the modulator unless you explicitly change it

[ustk]

@Christoph-Hart oh ok so if I use the same id it will appear only once?

[Christoph Hart]

yes, that's the idea.

[ustk]

@Christoph-Hart Got a weird one...
Changing the target from the dropdown, the modulation stays on the previous target.
The dragger appears on the new one but the modulation is still heard on the first target...

[ustk]

@Christoph-Hart So in the end, removing a connection from:

• Double click on the dragger -> works
• Click the delete button in the matrix -> works
• Select "No Connection" or another target from the dropdown -> doesn't work

[Oli Ullmann]

@ustk
@Christoph-Hart
An addition to this:
This only happens if a MatrixModulator is used for the parameter. If only the matrixTargetId is used for modulation for the parameter, the problem does not occur.

[ustk]

@Oli-Ullmann Exact, that's why I didn't see the problem before (aka in the 8th post above this one where I didn't have the issue yet) because I had different names.

[DanH]

@Christoph-Hart setting matrixHandler.setCurrentlySelectedSource("LFO 1"); does not create the modulation draggers above connected ui components / knobs. It does everything else in matrixHandler.setSourceSelectionCallback(function(source) that I've set. Is there a way to force the selection to draw the draggers?

[DanH]

@DanH @Christoph-Hart Ah so the draggers weren't ready to be drawn yet, so I've had to use a couple of delayed calls to make them appear after they're ready to be drawn for both compiling and launching the project first time:

matrixHandler.setCurrentlySelectedSource("LFO 1");

// Force trigger the broadcaster after a short delay
Content.callAfterDelay(50, function() {
    // Try to manually trigger what normally happens on click
    matrixHandler.setCurrentlySelectedSource(""); // Clear
    matrixHandler.setCurrentlySelectedSource("LFO 1"); // Set again
});

Engine.createTimerObject().startTimer(1000);
Engine.createTimerObject().setTimerCallback(function() {
    matrixHandler.setCurrentlySelectedSource("LFO 1");
    Console.print("Delayed init complete");
    this.stopTimer();
});

[Christoph Hart]

@DanH wow that looks hacky. I think the reason is that at the time the script's onInit is executed, the actual UI components of your interface don't exist, so they don't get the notification to show the draggers when they are created. The proper solution would be to correctly initialise the "dragger state" when creating the UI components - there's already a system in place for that because the hise::LambdaBroadcaster<T> class which is used for communicating the exclusive source has the option of initialising new listeners directly with the current state.

I'll try later whether the AI can oneshot-fix this with my assessment and our new workflow. If you want you can create a github issue from this, then I can also test the workflow as it is intended to be.

[DanH]

@Christoph-Hart done

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

[Christoph Hart]

@DanH yup, one shot indeed....

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

I couldn't reproduce your bug as this requires a lot of UI components to hit that scenario, but if you checkout the branch with the fix and confirm that it works, then I'll merge it into develop.

Aside from the concrete bug that we solved: with the new workflow setup correctly and an AI agent you'll be able to solve that completely on your own - it analysed the bug correctly, made a risk assessment that correctly came to the conclusion that this is a non-breaking change / fix and then applied the fix exactly as I would have done it. It also automatically would have created this PR with the summary so that I can do a quick review and merge that with a single click. Scary times.

[DanH]

@Christoph-Hart Thanks! I'm in a more manual mode tackling a couple of other issues right now which I'll post if and when successful, but a one shot option would certainly have made my morning go a lot smoother hahah!

[dannytaurus]

@Christoph-Hart Nice!

Does a new issue automatically trigger the workflow?