Assign mix to matrix issue

[bensmm]

Helllo @maxks. Think I may have another issue. Using SQ-5 'Assign mix to matrix function' and can get each AUX send on matrix routing screen to switch on/off (active tick/untick) no problem. However, cannot get same on/off on matrix routing screen for Main L/R. I'm using MATRIX 2 for clarity. Thank you if you can take a look and see if you have same behaviour.

[bensmm]

Hello @maxks Just wondering if you managed to get a chance to replicate this issue or whether you need some more information from me? Thank you.

[maxks]

Hi @bensmm I will try to replicate and fix issue in next days.

[daukema]

Any updates on this? I'm having the same issue as well. The "Fader mix level to matrix" isn't working for me either; specifically trying to assign/adjust fader for LR to Matrix 2.

[DavidPujals]

I'm also having the same issue - has anyone been able to resolve this yet?

[josephdadams]

I am in the process of converting this module to the v3 API, when that's done, I'd like for you to test it with that version and then we can go from there.

[jswalden]

The way setRouting currently works is to accept two pairs of MIDI NRPN MSB/LSB values -- one pair for if the sink is LR (which is internally encoded as 99), the other pair for if the sink is whatever the type of sinks being targeted is (0 to one less than the count of those sinks, e.g. [0, 12) for mixes). In my heavily-refactored-in-various-ways tree:

            const buffers = self.setRouting(
                opt.inputMix,
                opt.mtxAssign,
                opt.mtxActive,
                model.count.matrix,
                [0x6e, 0x6e],
                [0x24, 0x27],
            )
            mixer.midi.sendBuffers(buffers)

Here, the MSB/LSB if the sink is LR is [0x6e, 0x24], and the MSB/LSB if the sink isn't LR is [0x6e, 0x27].

But this is nonsense. :wink: The sink is not a "mix" (meaning either what on my mixer surface is labeled a "Mix", or that plus LR), it's a matrix. So it's never LR. So those first elements of the two arrays are meaningless (and in all the rest of the module are encoded as 0x00). And when you do the module's math to determine the actual MSB/LSB basing off of a mix in [0, 12) -- namely splitting (0x6e << 7) + 0x27 + mix * MATRIX_COUNT + matrix into two seven-bit halves -- it will work correctly when mix is in [0, 12) for actual mixes but will go wildly out of bounds of the MSB/LSB in that table when mix is 99 as the internal encoding of the LR mix.

(When it goes wildly out of bounds, what MSB/LSB does it actually turn into? And do those MSB/LSB refer to anything else? I dunno, and I'm too lazy to compute and see. If someone wants to do so -- or just packet-sniff the TCP traffic -- I'm idly curious to know.)

I think if, in this narrow case, mix for LR were encoded as -1, this would start working again. But that would be a grotesque hack, in code that cries out for the refactoring I'm neck-deep in, so there's no chance I'm fixing it before that refactoring is finished enough to land.

So there's a light at the end of this tunnel -- but I don't have anything to say about exactly when we'll emerge from the tunnel. :slightly_smiling_face:

[jswalden]

This is fixed in 02aad4fa3e608a3da9e679791fae1c6ddfcc7757.

The code on tip for setting pan/balance and fader levels is very snarled (and doesn't work), so it's not possible to simply make a release that contains this fix. I don't know when things will be cleaned up enough to actually do that.