Matrix Modulation Feedback

[DanH]

@Christoph-Hart sounds good :)

Ok I'm away for a couple of days - back Tuesday next week :)

Have a good one!

[DanH]

Ok I'm back!

One thing I seem to need some clarification on is the MatrixTargetID field in the Properties editor.

If I name this 'Volume' or whatever then it appears nicely in the Mod Matrix when I add a source modulator to the knob. But then it occurred to me that it should also match the id of any MatrixModulator module that I have put on the Gain chain in my instrument.

And then when I was fiddling about with a pitch knob that I had previously assigned to a pitch modulator, and have since added a ModMatrix module to the chain, I realised that the knob is now controlling both the original pitch module AND the newly added ModMatrix module (thereby increasing the pitch by double the knob's amount). So perhaps I can scrap the original pitch module and just use the new MatrixMod - but is that how it's meant to work?!

So what exactly is the MatrixTargetID for?

And can MatrixModules replace other types of modules?

[Orvillain]

@DanH said in Matrix Modulation Feedback:

So what exactly is the MatrixTargetID for?

One use is for linking a UI parameter to multiple matrix modulator targets. In such a situation, you don't need to assign the processorId nor the parameterId - you can just name your UI control whatever you want, and then make sure that any matrix modulator you want it to connect to, is also named the same. You can edit the name by checking out the edit ranges section in the matrix modulator.

[DanH]

@Orvillain Ah cool, that's useful. In your example, however, I would then expect 'Matrix Modulator1' to appear as a target in the Mod Matrix UI window. Does it?

EDIT - it doesn't, which is good!

[Christoph Hart]

@DanH The logic is as follows:

• any matrix modulator will show up in the target list with its ID unless
• the matrix modulator has its matrixTargetId property defined. In that case it will override the ID showing up in the target list.

You can use that for multiple scenarios:

• use multiple matrix modulators with the same target ID. This will work and if you add a connection, it will add the connection to all targets as well as automatically sync all properties (intensity, inverted, etc).
• use a prettified matrix target list if your ID naming system is too cryptic (eg. Synth1GainModulator)...

So perhaps I can scrap the original pitch module and just use the new MatrixMod

Exactly. As soon as you connect a UI knob to a matrix modulator, it will control its value parameter (with sets the "base" value of the modulation signal). In order to ensure that the modulation display rings work correctly you need to set the UI knob range to the same range as the InputRange of the modulator.

[DanH]

@Christoph-Hart

Ideally this would be a API method of the ScriptModulationMatrix (something like mm.setHoverPopupPersistence(true) or something.

Is this a thing yet?

[Christoph Hart]

@DanH no it's unfortunately not an easy change because this component was designed with the hover state behavior in mind:

• it's exclusive so it will only show a single component (when you hover over another slider it will hide the previous one)
• there's no logic to check for collision
• since it is built / destroyed at hover / exit I don't need to care about it being synchronized to the data model to react on connection changes etc.

For a persistent UI component that shows the matrix connections of a single UI knob you might be able to use the matrix floating tile - if you set its ProcessorId to the ID of the matrix modulator you're targeting, it will only show the connections that match the target and with some CSSing you can shovel away all the things you don't want to show.

[DanH]

@Christoph-Hart

For a persistent UI component that shows the matrix connections of a single UI knob you might be able to use the matrix floating tile - if you set its ProcessorId to the ID of the matrix modulator you're targeting, it will only show the connections that match the target and with some CSSing you can shovel away all the things you don't want to show.

I guess this would negate the benefit of the source selection callback, to show only the selected modulation dragers?

[DanH]

@Christoph-Hart With the Source Select callback the default selection seems to be the first modulator in the list. Is there a way to script this to a different one?

[Christoph Hart]

@DanH I don't understand - what's got the selection callback have to do with it?

[DanH]

@Christoph-Hart well for example I'm showing the relevant tabs depending on which source is selected but when I reopen the project it defaults to the first in the list and displays that tab and that button is highlighted.

or are you referring to my other question?

[Christoph Hart]

@DanH yes I meant the previous question.

With the Source Select callback the default selection seems to be the first modulator in the list. Is there a way to script this to a different one?

Can't you just call

ScriptModulationMatrix.setCurrentlySelectedSource(String sourceId)

with an empty string?

[DanH]

@Christoph-Hart Thanks, will try. (worked great )

So for the persistent UI modulation dragger - The source selection callback can show only the draggers relevant to the selection. If we create permanent ui controls we'd lose the current system of showing / hiding the draggers depending on the selection.

[Christoph Hart]

If we create permanent ui controls we'd lose the current system of showing / hiding the draggers depending on the selection.

Can't you use the callback to hide the controls?

[DanH]

@Christoph-Hart yeah. I dunno, If I have 100 controls that can be a target do I then need to make (100 x each source) draggers and show / hide them with the callback? Apologies if I'm being dumb about this!

[DanH]

A suggestion: would it make sense to switch the mouse cursor to up / down arrows when hovering on a modulation dragger?