Routing Matrix existential questioning and suggestions...

[ustk]

So it's been a while since I played with the Routing Matrix...

I need 6 parallel channels fed from the same stereo input
But in the RM itself, you can only route the first stereo pair as direct connections, and the second two as send. Hise doesn't let you connect everything else as send.

1. Is there a real reason for this constrain/limitation?

In the xml, the connections are made this way:

<RoutingMatrix NumSourceChannels="6" Channel0="0" Send0="2" Channel1="1" Send1="3"
               Channel2="-1" Send2="-1" Channel3="-1" Send3="-1" Channel4="-1" Send4="-1"
               Channel5="-1" Send5="-1"/>

2. Does it mean the only possibility is to stack one more matrix for each additional channel pairs in order to cover all connections?

3. Couldn't the routing system be modified to use a bit word, removing the need for sends?

<RoutingMatrix NumSourceChannels="6" Channel0="010101" Channel1="101010"
               Channel2="-1" Channel3="-1" Channel4="-1" Channel5="-1"/>

This would be way more flexible, but my guess is that such a modification of the actual paradigm might not be easy, not mentioning the compatibility with old projects (but as @clevername27 once said, improvement > compatibility)

That been said, I could probably put together a SNEX or C++ file that does exactly this and let the Routing Matrix behind with the ancient world

[d.healey]

The routing matrix effect does seem strangely limited - I mean it only has one job and it's not very useful for it :) You need to stack them as you suggest.

Depending on what you're doing you might also be able to use send effects.

Or possibly you could use a container's matrix:

[ustk]

@d-healey said in Routing Matrix existential questioning and suggestions...:

container's matrix

watizzat & hoyoudozzat ???

Are you able to make all these connections by changing the number of outputs of Hise?
Because I can't, it's only stereo direct + stereo send, not multi connections as you did...

[d.healey]

@ustk You change the number of connections between the matrix and whatever it's connected to. In my case it's just a container and the main project container. But it could be a sampler and a container, or a container and another container. The final container (HISE output) can still go down to stereo.

[ustk]

@d-healey Oh I see now, I was hundred miles away... Nice, but in my case (FX plugin) I am not sure it applies since the connections have to be made in between the FX modules...

[d.healey]

@ustk Could you use a send container/send effects?

[ustk]

@d-healey Yeah I just tried and it might work, but since this is more convoluted than stacking routing matrices I'll stick with the first solution, or write my own router maybe...

[DanH]

@ustk I'm currently designing a routing system using Script FX and Global Sends / Receives to make the connections

[ustk]

@DanH Oh nice!
I just tested very quickly and noticed a latency when using the container + send thing, which is normal since sending back to a point always happens a cycle later.
In my case I am refactoring the routing of my plugin exactly because of a latency issue (so comb filtering) between the different FXs, so this would make it just worse.

Ideally I need to make my own latency finder per channel throughout the entire project, that would leverage the need for exporting and codesigning after each modification because my preferred DAW for this is ProTools
But I don't know if I can write such a thing since I need script an emitter first in the chain and a recorder at the end, both synced to the sample...

[DanH]

@ustk what's the 'container plus send thing' exactly? Worried about latency now!

Currently I have an fx module with a script fx after which takes that signal and sends it to the next chosen fx destination

[ustk]

@DanH The fact they are both called send is confusing...

[DanH]

@ustk Thanks. I'm not using either of those. I'll make a snippet tomorrow

[ustk]

@DanH Two things are to be considered with latency:

1. when a signal is sent back in the chain (modules or within networks), it needs to be "memorised" by the system so it usually happens 1 buffer later. That's because you cannot send a signal anywhere before reading its buffer. So up the chain, where it is sent to, it arrives at best when the next buffer is read. This is the case in the module tree and in any DSP (even when considering a frame processing but it would be a 1 sample delay). But you can compensate for that by, I imagine, branching the main signal and delay it by a buffer length. I'm not in that case but that'll probably where I start.

2. when treating signals in parallel, like for instance a direct signal and a DSPed one, the second might introduce latency (delay) as well that depends on the processing type/complexity. So when they are recombined, they are not in phase anymore. Here delaying the direct branch by the same amount would resync the two signals, but introduce an overall latency that needs to be reported.

There are other cases like non-linear filters but since this is more frequency dependent, it's more complicated...

[DanH]

@ustk Thanks, that's well explained. In my case I am not re-combining any signals. But there could be some delay generated based on your explanation. Would this kind of delay be auto compensated for by a DAW?

[ustk]

@DanH Once you get the overall latency created by your plugin, you need to report it to the DAW. It is the DAW job to compensate, but it is your job to report with Engine.setLatencySamples()