[ANSWERED] Building a Decider Actor

liminal_andy

I am in a situation where I have 49 Zoom ISO feeds (crops of the gallery) that need to get uniquely routed to one of 49 possible outputs, where each output represents a performer, let's say. I've been calling this a Decider actor, and those who have used the example user actor from Liminal's git repo have seen that it is basically built to do this for 12 video feeds, where the user actor has 24 inputs, 12 for the video crops from the gallery view and then 12 numeric arguments to be filled out by ZoomOSC:

Internally, the user actor has a 12 output router bolted to every user input and the selection pin is set by the affiliated numeric user input. Then, every potential output from every available input is routed to every possible output, creating this mess:

The purpose of the above is to allow any Zoom gallery box to be routed to any possible performer video output, and the unique output is determined automatically by ZoomOSC's gallery order output.

I now have to build a new decider, but this time for up to 49 Zoom participants. Does that mean I have to build a new user actor with 49 video inputs and 49 numeric inputs, then have each video input tied to a 49 pin router, and then have all 2,401 output pins mapped to all 49 user outputs, resulting in a total of 117,649 manually drawn connections from routers to outputs?

Is there a better way to achieve this with a matrix? Or should a Decider be a new actor request? I'm hoping that I don't need to bruteforce this. If we figure it out I can get Isadora to power remote contribution to a professional sports stadium video matrix.

Woland

@liminal_andy

If you give me your current User Actors I can try to come up with a solution by modifying them.
Could you do one module of your connections using Broadcaster and Listener actors as the destinations/sources then copy-paste the module and change the channel numbers rather than having to make physical connections everywhere?
Could you chain together a number of your existing User Actors just modifying the starting channel of each User Actor?

Woland

@liminal_andy

Almost done with a solution for you. Please standby.

Woland

@liminal_andy

Try this file: Liminal Zoom Template 49.zip

Obviously I couldn't test it with 49 feeds, but I tested it with 3 live feeds and was able to route them properly

The patch is based on your original one, but expanded to handle 49 feeds:

The Global Controler guts:

The Auto-Cropper guts:

The Decider Guts for the routing:

The Decider guts for the video outputs:

bonemap

@liminal_andy

A thought for you:

" Seventy thousand, five hundred and thirty two. I have been wanting to count the stitches in a completed sweater ever since Tiennie did it. And decided, with charts and rows, this was the sweater to count. Seventy thousand, five hundred and thirty two stitches. That is a lot of stitches, and a lot of "throwing". (I knit using the English method.) Amazing to think my hand brought yarn around the needle seventy thousand, five hundred and thirty two times. I think we should all give our hands a massage. Or at least a kiss." from the google search 'how many stitches in a hand made cardigan'.

Best Wishes

Russell

liminal_andy

@woland Astounding! This delivers the functionality I needed, and my tests today went quite well. You're spectacular!

Woland

[EDIT: see a more efficient method of continuously outputting frames from the Picture Player, read my post below -- Mark]

@liminal_andy said:

This delivers the functionality I needed

Andy already discovered this, and thankfully just needs it to function for video, but I wanted to note that for anyone who wants to use my method, it currently does not work with still images unless you use a workaround (since they only send one frame instead of a continuous stream of frames).

If you want to mess around with Broadcasters and Pictures or static actors like a Shapes actor where nothing is changing, you'll run into this:

You'll still get a frame, but if you try to broadcast still images between multiple Scenes you run into this issue of the single frame being sent = no updates = no image in the new Scene.

You can get around this by [Edit: Read Mark's solution below, it's more efficient] ~~forcing the video stream to update itself in pointless ways like changing the hue of a color on a shapes actor that has no opacity and is therefore invisible:~~

~~This causes the Shapes actor to continuously send new frames of the Picture Player into the Broadcaster, which solves the problem.~~

mark

@woland said:

You can get around this by forcing the video stream to update itself in pointless ways like changing the hue of a color on a shapes actor that has no opacity and is therefore invisible:

The Shapes Actor is not the most efficient choice for this use case. Instead, add a GLSL Shader actor with the following code:

uniform sampler2D tex0;
void main(void) {
    gl_FragColor = texture2D(tex0, gl_TexCoord[0].xy);
}

This will simply pass the input to the output, but because GLSL Shader needs to update every frame even if the source image doesn't change, you get a continuous stream of images.

Best Wishes,
Mark

peuclid

This is amazing.

I'm really curious how much cpu/gpu do you need to do anything with 49 video streams. On my 4-core i7 Intel Mac, the fan starts to get louder at around 10-12 users in the gallery. What numbers have you gotten up to and how much hardware did it take?

Woland

@liminal_andy

If you're comfortable sharing this, it'd be great to have a version of this on the TroikaTronix Add-Ons page (link in my signature) if it's not there already :)

Best wishes,

Woland