Magic

Music Visuals
https://magicmusicvisuals.com/forums/

Distributer/router (opposite 'input selector')

https://magicmusicvisuals.com/forums/viewtopic.php?f=4&t=2516

Page 1 of 1

Distributer/router (opposite 'input selector')

Posted: Mon Apr 12, 2021 4:16 am
by jhinden
I'd like to have the ability to 'route' signal out to one of several outputs. Basically the opposite of input selector. Seems like an obvious candidate for a module, so I'm guessing there is a technical reason this doesn't exist, but would be quite useful.

Example:
1 input
8 outputs
Index selects which output to use for the input signal

Re: Distributer/router (opposite 'input selector')

Posted: Mon Apr 12, 2021 2:38 pm
by Eric
Why would this be useful?

Re: Distributer/router (opposite 'input selector')

Posted: Tue Apr 13, 2021 8:48 am
by jhinden
Sure. Let's say the user wishes to do the following:

Dynamically route video signal to either FX 1, FX2 or FX3. and modulate the index.

As I understand it:
Current solution with Input Selector:
Requires that all fx are active as I'd have to route the video through 3 fx connected to an input selector.

Output selector
The fx would only be working on the selected output, which should reduce processing demand.

There are also cases when building where it just makes more sense and is easier to wire up as you're building forward in the chain.

Re: Distributer/router (opposite 'input selector')

Posted: Tue Apr 13, 2021 1:50 pm
by Eric
No, I don’t think you’re understanding how it works. When you have multiple inputs to an InputSelector, only the selected input is active.

Re: Distributer/router (opposite 'input selector')

Posted: Wed Apr 14, 2021 5:28 am
by jhinden
I understand how the input selector works, but had believed that processing resources were used for all chains connected to it regardless of which was selected and that there would be a processing benefit to having a selector before routing to fx. Did some test the other day and could swear there was, but likely it was a faulty test. :D

In any case, as a matter of style/signal flow I personally prefer a router (more intuitive left>right signal flow) and leaves more room at the end of the chain to add things without having to move the input selector around.

Example magic patch with input vs output selector:
https://snipboard.io/RTYDLi.jpg

Six and one-half dozen mostly, but I'm sure there was a specific case the other day where it would have been much easier to edit my patch with an output selector, but unfortunately don't recall what it was. If I run into it again I'll let you know.

Re: Distributer/router (opposite 'input selector')

Posted: Thu Apr 15, 2021 4:09 pm
by jhinden
I believe I can provide a more clear example of a practical need for both an input and output selector.

If you're using any sort of time based process) that relies only on a momentary input, (such as Micro Buffer RGB) and use an input selector (many > 1), you will instantly cut the output off when selecting a different input signal.

If you are using an output selector (1 > many) the effect should have a natural decay after it stops receiving input, despite having selected a different output. In this particular case, you can hack together a solution by using a multi mix instead of the input selector and crossfading, though it's not quite the same.

Video > Micro Buffer (max. lag time) > Input Selector
vs
Video > Input Selector > Micro Buffer (max. lag time)

Thanks

Re: Distributer/router (opposite 'input selector')

Posted: Thu Apr 15, 2021 4:44 pm
by Eric
I understand what you're saying, but the purpose of the InputSelector is to render only the active input. With an "OutputSelector" you would be rendering *all* the outputs, even if only one of them is active. This would be horribly inefficient.

It may seem that a scene gets rendered from left to right, but it's actually right to left. The Magic module is the root of the tree, rendered first, and its input modules are the children, rendered next. And so on, recursively, until a path ends (such as with a VideoFile module, which has no inputs). Therefore in the example image you posted, both MultiMix modules in the bottom paths would be rendered, whereas in the top path, only one of them would be rendered. That is to say, when the renderer encounters an InputSelector (or a MultiMix), it then renders only one of the children; but otherwise (for all other modules) it renders all of the children. Make sense? So in your case, the OutputSelector wouldn't even be reached by the renderer until at least one of the MultiMix modules had already been rendered, but maybe not the desired one, thus losing the performance advantage.

To do it any other way would be to forfeit the hardware acceleration provided by your graphics card, because hardware accelerated graphics are commonly based on the functionality of a state machine API (such as OpenGL), which is inherently optimized for a tree data structure. Basic operations like translating or rotating things would be lost (or at least VERY slow) without this methodology. A common example is that when you want to draw an object on the left side of the screen, you actually do the translation first (offset the world by where you currently are) and then draw the object at the exact center of the world, and then translate the world back to its original location; rather than what seems intuitive in the real world like building an object first, then moving it to its destination. But this works out in Magic, because when the renderer traverses a scene that looks like (for example) Polygon > Translate > Magic, it would actually see the Translate module first, and then the Polygon afterwards. So in essence, what the renderer sees is Magic > Translate > Polygon.

So, to put it all together: Magic > InputSelector > Polygon should make sense to you now. Whereas Magic > Polygon > OutputSelector shouldn't.

Some further reading:
https://en.wikipedia.org/wiki/Tree_(data_structure)
https://en.wikipedia.org/wiki/Scene_graph

Re: Distributer/router (opposite 'input selector')

Posted: Fri Apr 16, 2021 3:35 am
by jhinden
I appreciate the detailed explanation and links Eric. That makes sense now. I'm coming at this from node based audio environments and it's often difficult to grasp why certain things behave differently (or are named similarly, but act differently) or why some things I'm used to having around aren't there.

I understand that it's a tricky balance when making decisions about what to implement for users and what would cause them more harm than good, so I appreciate the efforts made.

Thanks for your time.

All times are UTC
Page 1 of 1