Drive Source Multiplexer Component

[lxw404]

Is your feature request related to a problem? Please describe.

Currently it's quite tedious to manage a target value which can have multiple driving sources based on a condition.

Describe the solution you'd like

A new singular component which acts like a drive source multiplexer, routing multiple sources of a particular type to a single target given an index of which source to select.

Describe alternatives you've considered

The current solution is to use multiple components: ValueMultiplexer or ReferenceMultiplexer and then value/reference copy every single value in the list from the original source, making it very tedious to manage.

Additional Context

No response

[Nytra]

You could use a ReferenceMultiplexer<IField<T>> which drives the Source of a ValueCopy<T> which is a bit simpler.

[lxw404]

That is closer, but still multiple components.

[shiftyscales]

Can you please describe your use-case and what you're trying to build @lxw404?

Why is using multiple components a problem?

[lxw404]

A very simple use case for this is for blendshapes.

Let's say that you want multiple systems to control 1 blendshape and you select between these with some logic. It's fine to use multiple components if that's the only one you want to control. The more components that you have however for just a single target, the more it is multiplied by the total number of blendshapes you want to control, so it can get unwieldly very quickly.

Another possible use case for this is having control rigs for bones which can be swapped based on animations, which has the same issue, the more bones, the more the components multiply.

[shiftyscales]

value/reference copy every single value in the list from the original source, making it very tedious to manage.

Are you aware of the ValueMultiDriver, and ReferenceMultiDriver components? These will allow you to hook the same system up to as many fields/blendshapes, etc. as you could want.

Value/ReferenceMultiplexer would be used as a list of data sources for your system, controlled by an index.

Value/ReferenceMultiDriver would be used as a single source to drive all desired fields/blendshapes with it.

If you needed to add arbitrary levels of complexity to the system, you could also drive the values on the ValueMultiplexer as Nytra indicated above, @lxw404.

[lxw404]

The goal is to target 1 field with multiple potential inputs (drive sources), not the inverse of having 1 value target multiple outputs (which is solved by single components already). The subtle difference is a mapping problem:

%%{init: {'theme':'dark'}}%%
flowchart LR
    A[System A]
    B[System B]
    C[System C]
    D[System D]
    E[System E]
    Out[Target Field]
    A -- 0 --> Out
    B -- 1 --> Out
    C -- 2 --> Out
    D -- 3 --> Out
    E -- 4 --> Out

In this, the Output would be able to be controlled by any of the source systems by selecting an index.

At the moment there is no single component solution to this problem, but its inverse has MultiDrivers as the single component solution. The way Nytra had mentioned is a workaround, but will still multiply in complexity with large systems. @shiftyscales

[shiftyscales]

Then why not use the Multiplex node found in "Utility", @lxw404? That's a single component solution to your problem.

https://github.com/Yellow-Dog-Man/Resonite-Issues/assets/54213390/56586527-66fa-4412-93b6-9f4061269254

[lxw404]

This is fine for a ProtoFlux implementation, however the component analogue to having IField Source inputs rather than Value inputs does not exist, whereas it does exist for the multi driver analogue. This asymmetry is what I'm most interested in having filled in since sometimes a component version is easier to organize, especially if there are hundreds, or if you want them to dynamically generate.